Homebrew Disabling 3DS LED Lights with Homebrew?

  • Thread starter Thread starter Kokonoe
  • Start date Start date
  • Views Views 39,412
  • Replies Replies 113
  • Likes Likes 1
You can try messing with LED patterns with ctrulib (in your own code), but doing it you risk a full MCU brick.
MCU bricks aren't recoverable even with NAND mod.
Depending on the type of brick it could be recoverable with a MCU mod, but LED bricks are full MCU bricks so no recovery there.
 
Yellows8 attepmted. But he bricked his 3DS (MCU brick) messing with LED pattern values, for RE purposes.
 
Yellows8 attepmted. But he bricked his 3DS (MCU brick) messing with LED pattern values, for RE purposes.
yeah it was said in this thread already, then you said it again a few posts ago, and now you repeat it again, lol

anyway the op just wants to disable right, not do custom actions really
 
if you are on a n3ds, you can click the top corner and click a slider to turn it off. if on an o3ds, there is a switch on the left or right side you can slide to turn it off..
He's not talking about just the wireless though, he also wants to disable the power button light
 
  • Like
Reactions: Yami_Industries
You can disable the yellow light turning off wireless, but as for power charging and the bright blue light that notifies you the system is powered on, you cannot disable those normally.

Is there a way via homebrew to disable these lights to where they are never on? The blue light in particular is bad for my eyes when I play in the dark. Thanks.
Why don't you just put electrical or duck tape where the lights are?
 
  • Like
Reactions: TimX24968B
Okay, this is going to sound incredibly idiotic but is is true...
I had to buy a new 2DS for this reason xD I didn't like the light coming from the top right (Friend notification), so I though opening up the 2DS and cutting the circuit to the light would be a great idea!

Long story short, don't do what I did because you'll end up buying a new DS
 
-snip-
EDIT: you might just be able to cover it (like with a piece of tape or something).

Thats the most reliable thing i can think of right now.
 
Last edited by TimX24968B,
You can brick the MCU firmware by sending a bad LED pattern to it. The MCU handles the i2c communication with the LED, and for some reason if you send a bad format it bricks it. I'm not too sure on the details of why exactly the MCU firmware can't handle it though,
Oh, it makes sense though. Thanks for explaining.
 
see messing with the LED's, or doing pretty much anything involving the LED's will shut them off. In fact it shuts off every light on the console.
 
I was more interested in the MCU brick, not the lights lol.
I heard this from Dazzozo in a private conversation, but he was referring to something yls8 did and discussed in #3dsdev. You can ask there, but I have no idea how helpful he'll be.

Alternatively, @MarcusD is reversing the MCU, or so I hear. He might have some insight.
 
  • Like
Reactions: vb_encryption_vb
@MarcusD is reversing the MCU, or so I hear. He might have some insight.

Who said that I'm REing the MCU_FIRM? :sad:

I'm only REing CTRAging! I have seen the datasheet for the MCU... I don't hate my brain that much to start REing it :(

Also, I have tested on my old3DS, I didn't manage to brick by repeatedly sending commands, so yellows8 must have had an extremely bad luck or poorly written test program. But please note, I was using ptm:sysm if that makes a difference!

Edit: it's possible to turn the power LED off until the battery state changes. The wifi led flashes on data transfer, so I doubt you can turn it off. 3D LED, same kind of deal, if 3D mode changes, your temporary settings will be overwritten.
 
Last edited by Sono,
Can someone explain it in detail?

Why bricks the MCU?
Does the MCU handle the LED controlling and sending random data to it overwrites the MCU firmware?

This is really awkward.
It's like turning the car lamp inside off and the engine breaks...
 
Last edited by GothicIII,
Can someone explain it in detail?

Why bricks the MCU?
Does the MCU handle the LED controlling and sending random data to it overwrites the MCU firmware?

This is really awkward.
It's like turning the car lamp inside off and the engine breaks...

Well, the MCU needs a bit of time to process the LED signal, so if you repeatedly start spamming the LED control commands, you might end up sending data while the MCU is still processing, thus turning the command into garbage data, making the MCU freak out, and you know what happens if you execute garbage data... ye
 
Who said that I'm REing the MCU_FIRM? :sad:

I'm only REing CTRAging! I have seen the datasheet for the MCU... I don't hate my brain that much to start REing it :(

Also, I have tested on my old3DS, I didn't manage to brick by repeatedly sending commands, so yellows8 must have had an extremely bad luck or poorly written test program. But please note, I was using ptm:sysm if that makes a difference!

Edit: it's possible to turn the power LED off until the battery state changes. The wifi led flashes on data transfer, so I doubt you can turn it off. 3D LED, same kind of deal, if 3D mode changes, your temporary settings will be overwritten.
Ah, that makes much more sense, when I heard you were reversing the MCU I was impressed :p

Yeah, yls8 was probably just straight up fuzzing against the LED - which is a recipe for disaster.
 
  • Like
Reactions: KoalaBoy and Sono

Site & Scene News

Popular threads in this forum