everyway to mcu brick.

Close the lid on new 3ds 2.1.0 (maybe <8.1.0)

 

I am not finding any reports saying that causes a brick, just cause the game to crash. If it did cause an mcu brick, I highly doubt Nintendo would have let that continue to happen.
The only mcu I can find is anyone stupid enough to close their new3DS on 2.1

 

Wut.

 

In the European and North American releases of Metroid for the NES, inputting "ENGAGE RIDLEY MOTHER F****R" as the password would cause the game to count 2,755,656 hours of gameplay and overload the system, causing hardware damage to some NES units*. This bug wasn't patched in the Virtual Console version, and would cause a similar error to the 3DS, resulting in bricking crashing**. However Nintendo has since added a patch in the 3DS firmware that would cause Virtual Console itself to crash instead of the entire system.

* I think this was because the NES couldn't handle variables containing a value that high, but not sure. Can someone please check?
** This has now been called into question. While entering the code right now will crash VC and require a power cycle, there are unverified claims that consoles on earlier firmwares can brick.

 

What, you could brick your 3DS by doing this?! Lol, this is hilarious!

 

An interesting not, you can say fuck on the Temp. And it only crashed the system, it didn't cause an MCU brick.

 

Tbh if that's The cause I don't think someone would be so stupid to do so

 

The video is from 5 years ago but this has been fixed in newer firmwares

 

And it wasn't an MCU brick either
It was basically a temp soft lock. Once you reset your system, it was fixed.

 

I heard that invalid LED commands on older firmwares (like 4.x) could brick, but newer firmwares have better error handling. That may be why yellows8 bricked, when using the exact same code, someone else (don't remember the name) had it work perfectly.

 

Holy shit this is hilarious. How did I never find this out before. Do you have any more technical documentation on this effect on the original nes? I have searched quite a bit here and didnt find much more, this is so funny.

 

In the original Famicom version of Metroid, the cartridge had an on-board battery that allowed progress to be saved and continued later. The European and North American versions didn't have the battery due to cost saving reasons and instead users would receive a password to record their progress, which they had to enter at the title screen in order to continue.

Each character of the password actually defined what value certain variables should be (e.g. Location on the map, items or power-ups obtained), so when the player entered their password they weren't exactly loading a written save, but instead the game was effectively reconstructing what the conditions were at the moment the player "saved" their progress. This system was widely open to abuse, as players pretty much had control of any aspect of the game. By sheer coincidence, the code above would cause the game to record the total play time as being a value far higher than the maximum possible number a NES could count to, resulting in unpredictable behaviour.

 

All the reports of the Metroid brick as far back as 2011 say that it was NOT a brick, it just caused the system to crash and be power cycled before it would come back on. Where is the confirmation that is causes an MCU brick? Every report floating around online all confirm a power cycle reversed it. The LED light thing does cause an MCU brick.

I though updating a N3DS on 2.1 caused an MCU brick as well since a hardmod can't fix it.

 

This is NOT a MCU brick!
As explained here by @MarcusD

 

What isn't an MCU brick? No quotes, no context.... And isn't that basically explaining WHY an MCU brick can't be recovered, not saying it doesn't exist? If you need access to the MCU sysmodule to fix it, but can't be turned off without killing the system entirely. Isn't that what we're talking about the fact it can't be fixed? I'm so confused by your post.

 

Updated my earlier post to highlight that claims of 3DS bricking from the Metroid code are unverified and that on current firmwares it will only crash VC.

So, probably nothing dramatic like this:
​