Nintendo 3DS (family)

This article is a stub. You can help Repair Wiki grow by expanding it.

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)

Terminology

Used name	PCB name	Description
SoC	CPU CTR CPU LGR	The big main chip with the yellow underfill. Contains all three CPUs, the GPU, peripherals, legacy fabric (for native DSi and GBA mode), and a lot of SRAM.
FCRAM		The slightly smaller chip with the underfill. This is the main DRAM.
NAND		The Samsung or Toshiba chip. Contains the OS, some user data and configs, legacy files and partitions, and two boot slots. All data is encrypted, and some data regions use different encryption. The data is console-unique, and bound to the SoC, and also to the NAND chip itself (via NAND CID). Not needed to get a fully dead system to power on. If dead, damaged, or nonexistent [verification needed], then on a repaired system both displays should display the same blue background yellow text with error codes on it.
MCU	UC CTR UC KTR	The backbone of a functional 3DS; without this working, the 3DS will appear completely dead, and might even refuse to charge. Functions: RTC (keeps track of the date and time while a battery is inserted, and also reports battery removal through the RTC being reset) Low-level power control (controls power generation (through PMIC) to the SoC, LCD panel, individual LCD backlight, and other misc. peripherals) Low-level reset control (controls RESET lines of some peripherals (mainly to the SoC, which has two)) Charging control (manually overriding PMIC charging enable and disable [stronger verification needed], charging plugged in and voltage present detection, charge monitoring, battery percentage and voltage reporting, charging LED control) Extended special buttons with interrupts (handles special keys, like Power, HOME, WiFi, lid magnet reed, but SELECT is also hooked up) Indicator LEDs and animations (RGB notification LED, red and blue Power LED, 3D LED, camera LED, WiFi LED) Various metadata reporting (type of 3DS, kiosk unit, detected battery type, etc.) There are some other uses, but those are not critical to a functional system, and they always work if the above are all also working.
PMIC	TI 93045A4	One of the two TI (Texas Instruments) chips. Can be identified from the CODEC, as the PMIC has more dense and more bigger capacitors and big inductors, and doesn't contain "PAIC" or "AIC" on the chip label. The MCU communicates with the PMIC via I2C [which?].
CODEC	TI PAIC TI AIC	Custom chip. Handles touch input, microphone, headphone, speaker amp, and also acts as an I2S DAC. Not critical for getting a dead system alive, but the OS will error out without it. [verification needed]
WiFi		Referring to the overall WiFi subsystem (daughterboard or soldered can, depending on the model), unless explicitly specified (eg. "Atheros WiFi" or "Mitsumi WiFi"). Not critical for getting a dead system alive, but Home Menu will hang, and/or behave really weirdly if it's disconnected or damaged.

Problems

Common hardware problems

Appears dead

Problem	Solution
There is absolutely no life out of the 3DS	Check if you're using an original (or at least a compatible knockoff) battery. The MCU is programmed to reject some types of batteries. On a Kiosk unit a charger being plugged in is mandatory! The MCU is programmed to emergency shutdown if the charger voltage detect fails. This also means that it won't power on without a charger supplying power. Make sure your test battery is charged, and not worn or fake. Charge it to at least 4V in a known working 3DS of the same type. Check for a blown fuse [where?] Check if the PMIC is getting any power. [where, and how much?] Check if the MCU is getting 1.8V [board-specific] Check if both I2C0 and I2C1 (that is, two SDA and two SCL traces) are at 1.8V around the MCU Check if pressing Power for a few seconds causes the blue Power LED to fade in If there is a liquid damage, check if one of the neatly arranged transistors near the MCU (responsible for driving the indicator LEDs) are faulty Check if holding SELECT+Power for a few seconds causes the blue Power LED to fade in If it does, then check between the magnetic reed switch below ABXY buttons (non-2DS) or the Hold switch (2DS) for continuity or damage If it doesn't then the MCU might have a problem (continue to the MCU problems section)
The blue LED fades in, but immediately goes out (no fade) with a loud pop (or very rarely without a pop)	Something is open or shorted. Most common suspect is the backlight being open, or LCD power lines being shorted due to a damaged flex cable. Check bottom screen backlight cable and LCD cable first. Even though it should basically never go bad, it's much easier to check than top screen, so check it first just in case. On 2DS, there is only one backlight cable, as the bottom screen is the backlight source. On non-2DS, the top screen ribbons don't have a separate backlight flex cable, so diagnosing it is more difficult. Sometimes the flex cable can go bad from all the opening and closing, even if there aren't any obvious signs of damage. In any case, LCD panel power and backlight power lines should not be open or shorted. Parallel LCD data lines may be shorted, then just the LCD will not display an image correctly, or at all, they should not influence the open/short detection. If it's not possible to diagnose this at the connector, then it might be possible to diagnose this further by opening top screen assembly, but it's a rather nightmarish process, and has a high chance of damaging the ribbons even more. Need really steady hands, and a lot of patience! Sometimes it's a bad softmod (it's a software fault tripping the short detection)
The blue LED fades in, but then softly fades out almost instantly after fading in.	If the SDCard contains the correct files, then check the SDCard reader. Gently clean it, and also check the ejection mechanism. Sometimes the pins on the SDCard itself are dirty, also clean that. If hardware maintenance doesn't solve the problem, then it's a bad softmod. See the common software problems section.
The blue LED fades in, but stays on with no activity, even after a whole minute of waiting	Force power off the 3DS, either via long hold of the Power button (for around 10seconds, recommended), or via battery pull (not recommended). If there is anything in the cartridge port, remove it by pushing it in and letting it pop out, and try again, just in case. Some Nintendo DS cartridges tend to hang the system at boot time. If this did fix the issue, then clean both the cartridge pins and the cartridge slot pins (gently!). If this did not fix the issue, then continue reading. Remove SDCard. If turning the 3DS back on makes the blue LED fade out after it fades in, after turning the 3DS back on, then try following the problem solving guide for that first, where powering the 3DS on causes the blue Power LED to immediately slowly fade away. If turning the 3DS back on loads Home Menu after a minute or so, then the Home Menu management data (most likely the theme data) is corrupted. Check the SDCard for corruption, might need a replacement due to being worn out. There is no way to repair this, but it's possible to fix this by deleting Home Menu management data from the SDCard. This will remove the current theme, and also the icons should also be at different positions. If turning the 3DS back on still makes the blue LED stay even after a whole minute of waiting, it's usually the following: Bad softmod, or some other software-related problem. Nowdays it's a more common cause. See the common software problems section. Bad FCRAM (especially on new3DSXL and new2DSXL, where the board size is bigger). Retail OS hangs instead of displaying an error message, so it's a bit difficult to diagnose. Bad PMIC, or other power delivery issue. Very unlikely, especially if the blue Power LED comes on, but possible! It's quite difficult to differentiate between software intentionally hanging, versus the SoC not even getting power. Most likely cause on water-damaged boards. Bad WiFi. Very rare, but Home Menu can hang before it displays anything if WiFi is bad, instead of hanging a few seconds after it has booted, with no status bar on the top. If this is the case, then the backlight for both displays should be on already. Level 1 brightness level with adaptive display brightness should be very faint, so cover the screen well, or go into a dark room if you wish to see the faint glow of the backlight. [TODO: there is more to this problem, especially depending on if there is backlight enabled or not]

Failure after powering on

Problem	Solution
Both displays display "BOOTROM 8046" on a blue background with yellow text (yes, it is actually yellow, not white)	This is most likely a software problem. More accurately, the bootrom can't find a valid signed FIRM file to boot, and this is the fallback screen if none of the entrypoints are usable. [TODO: what error codes mean, and their format] If it's a signature error, then it's most likely a bad softmod, and you might get away just by reinstalling a valid FIRM0/FIRM1. If it's a hardware error, then most likely you'll need data recovery. [TODO: there are still hope, can be tested by shorting some pins to GND and seeing the error codes change]
Home Menu hangs a few seconds after it shows. The status bar on the top is not visible.	Usually bad WiFi. If you do replace the WiFi, try to salvage the 8-pin SPI flash!
On new3DS models, Home Menu freezes after being booted. On softmodded systems it shows errdisp instead for qtm.	Something bad between the motherboard and the camera. The qtm system module uses the camera in Home Menu even if 3D mode is off, so if the camera goes bad for some reason (most likely the flex cable going to the top screen got damaged), then it will fail with an assertion error. The reason this does not happen in the old3DS family of systems is because they lack the QTM hardware (Quad Tracking Module/face tracking/"Super-stable 3D") entirely.

Malfunction during use

Problem	Solution
Trying to use camera will either show black screen, or just hang everything entirely	Something bad between the motherboard and the camera, usually the flex cable.

Common software problems

This article is a stub. You can help Repair Wiki grow by expanding it.

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 problems

Problem

Solution

I have an original, known working, well-charged battery, MCU is getting power, both I2C lines have both their traces at 1.8V, yet holding SELECT+Power for a few seconds still doesn't cause the blue Power LED to light up

If this is the case, then the board has a high chance of not being salvageable, although the MCU does go bad very rarely (especially if water damaged). Before replacing the MCU, consider trying to reflash it first, if it still shows some signs of life (especially since it's a customized NEC 78K0R design (both in internal hardware and in external pinout), so the only way to source them is to salvage from a donor board). An advanced last-resort technique may be to solder some wires to I2C1 [verification needed], and try communicating with the MCU that way. Write 0x00 to device 0x4A >> 1 (that is, 0100 101x, where x is the I2C read/write bit), then reopen it in read mode, and read two bytes If the first byte is 0x10, 0x20, or 0x30 (new3DS-only), then the MCU is probably alive enough to be reprogrammed, see MCU reflashing via I2C section. If you get a NAK, then the MCU is probably dead, and a replacement might be needed (which is moderately difficult due to the small pitch 64-pin BGA package)

Repair tactics

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 6A 68 6C (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 6A 68 6C (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 FF FF FF FF to register 0x18.
   Optionally you can sanity check this before writing FF FF FF FF, by reading 4bytes from this register. Normally it should be 00 10 FF C0, 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 6A 68 6C 5E 0D FF FF FF FF [...] 31 33 3A 31 33 3A 34 32 00 00.
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 00 10 FF C0 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!