Nintendo 3DS (family)

This page contains issues related to all members of the Nintendo 3DS family.

Because the board layout and the overall construction of each 3DS on the inside is almost completely different, you will need to have both this page, and the page of the problematic 3DS open in a new tab.


 * Nintendo 3DS (CTR)
 * Nintendo 3DS XL/LL (SPR)
 * Nintendo 2DS (FTR)
 * New Nintendo 3DS (KTR)
 * New Nintendo 3DS XL/LL (RED)
 * New Nintendo 2DS XL/LL (JAN)

Common software problems
TODO: write something minimal about softmod problems.

Most times (especially if you have the blue Power LED fading in and fading out problem) it's just a missing boot.firm or missing arm9loaderhax.bin file from the SDCard.

Also check the partition table and filesystem. It should be MBR, and the first filesystem should be FAT32. While the card reader is card-agnostic, the software is not programmed to support higher than SDXC cards (<=32Gigs is recommended, with cluster size of 32768, aka. 32k).

There should be plenty of software guides scattered around the internet on how to mitigate these problems [TODO: link reputable sources?]

Warning: do not unsoftmod the device, unless absolutely necessary. If you don't know what you're doing, then that means that you should not unsoftmod, and you should repair the softmod instead!

MCU reflashing via I2C
If the MCU is communicating via I2C, but otherwise not powering on the blue Power LED even for SELECT+Power, then it might be possible as a last resort to try reflashing the firmware to see if that fixes it.

You will need:
 * wires soldered to I2C1 [verification needed]
 * Make sure that the programmer or microcontroller can detect 1.8V as a high level signal, and that it's strictly open-drain pin drive (that is, low=pull to GND, high=release pull to GND (High-Z the pin, or set it as input). If the programmer or microcontroller attempts to pull the I2C signals high actively (especially worse if higher than 1.8V) then it can damage more components on the system!
 * MCU firmware for the correct system, that is usually 0x4003 bytes in size
 * It is recommended to use the latest MCU firmware for the given system. MCU firmware is backwards compatible in retail units via the I2C interface with older OS versions, so it's recommended to flash a newer version that the MCU reports (detailed in a later paragraph).
 * Do not mix up old3DS, new3DS, and new2DS MCU firmwares! While the chips themselves should be pin-compatible [stronger verification needed], the code (especially the power management code area) is different between them.
 * Verify if you have a correct firmware file!
 * If the file size is 0x4000, then check that the file doesn't start with  (ASCII for "jhl")
 * If it does, then it's a bad dump, copypaste it again
 * If the file size is 0x4003, then check that the file does start with  (ASCII for "jhl")
 * If it doesn't, then it's a bad dump
 * Verify common validity using a hex editor. If the dump to verify is 0x4003 in size and starts with "jhl" then ignore those three bytes during verification.
 * The first 0xC0 or so bytes is a vector area (consists of 16bit addresses, Little Endian (so 5E 0D means 0x0D5E))
 * On retail firmwares unused entries are filled with FFFF
 * The entrypoint (first two bytes) should be somewhere between 0x0530 and 0x0F50. Small deviations from this range are okay, but it shouldn't be less than 0x0100, and shouldn't be more than 0x0FF0.
 * The entrypoint should point to data which looks something like 61 CF 51 00 71 8C 71 09 FE CB F8 [00 FE] (last two bytes might be slightly different)
 * There should be a small FF-filled area around 0x0FF0, along with an ASCII-readable timestamp in the format of hh:mm:ss, which does not overflow to 0x1000.
 * There should be an ASCII-readable timestamp in the format hh:mm:ss at 0x1000
 * There should be an ASCII-readable timestamp in the format hh:mm:ss at the end of the firmware at 0x3FF0 in an FF-filled area. There may be some other garbage next to the timestamp, but as long as the timestamp is recognizable then it's okay.
 * If the hex editor supports it, view byte distribution. It should have a few peaks for commonly used instructions (in the case of old3DS MCU firmware, it's bytes 0x71, 0xFF, 0xFD, 0x00, 0x61, 0x31, and 0x50)
 * some skills to be able to read and write arbitrary data to an I2C device
 * read register: write a single byte addressed to the MCU device, then reopen it, and read as many bytes as you need
 * write register: in one continuous write (that is, do not close or reopen during a write) write the byte of the register, then stream the data continuously

MCU device address is 0x4A >> 1 (that is, bits 0100 101x, where x is the I2C read/write bit).


 * 1) Detect MCU firmware version by reading two bytes from register 0x00. First byte should be 0x10 or 0x20 for old3DS, and can also be 0x30 for new3DS and new2DS (new2DS should have the 2nd byte at least 0x41)
 * 2) Write   to register 0x18. Optionally you can sanity check this before writing , by reading 4bytes from this register. Normally it should be  , but if you convert the value from hexadecimal to binary, it is okay to have a few bits different.
 * 3) Read 5bytes from register 0x10. The values can be discarded, but it is important to do this read.
 * 4) Write 0x4003 bytes of firmware to register 0x05. For example, for old3DS what you write to register 0x05 might look like.
 * 5) Wait one second, just like how the official update code does. Although due to the bloated nature of the code doing the flashing, it is wise to wait two seconds instead.
 * 6) Detect MCU again by reading two bytes from register 0x00 If you get NAK, then the chip is bricked, and a battery pull might not fix it either.
 * 7) If you think that the MCU is revived, write   to register 0x18, and read 5bytes from register 0x10 afterwards.
 * 8) Try to turn on the 3DS, after you deactivate the programmer or microcontroller you used to reflash the MCU (so it doesn't interfere). It is important that you do this, so you take the MCU out of zombie state!