We will be continuing maintenance on the wiki starting this Saturday at 9 am (UTC) to Sunday at 7PM (UTC).
There is a possibility of long maintenance-breaks and downtime during this time.
For more information contact us in the wiki Discord or by email at: unto@fighttorepair.org
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[edit | edit source]
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).
| |
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:
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.
|
WiFi | Referring to the overall WiFi subsystem (daughterboard or soldered can, depending on the model), unless explicitly specified (eg. "Atheros WiFi" or "Mitsumi WiFi").
|
Problems[edit | edit source]
Common hardware problems[edit | edit source]
Appears dead[edit | edit source]
Problem | Solution |
---|---|
There is absolutely no life out of the 3DS |
|
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.
|
The blue LED fades in, but then softly fades out almost instantly after fading in. |
|
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. Remove SDCard.
[TODO: there is more to this problem, especially depending on if there is backlight enabled or not] |
Failure after powering on[edit | edit source]
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[edit | edit source]
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[edit | edit source]
![]() |
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[edit | edit source]
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.
|
Repair tactics[edit | edit source]
MCU reflashing via I2C[edit | edit source]
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)
- The first 0xC0 or so bytes is a vector area (consists of 16bit addresses, Little Endian (so 5E 0D means 0x0D5E))
- If the file size is 0x4000, then check that the file doesn't start with
- 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).
- 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) - Write
FF FF FF FF
to register 0x18.
Optionally you can sanity check this before writingFF FF FF FF
, by reading 4bytes from this register. Normally it should be00 10 FF C0
, but if you convert the value from hexadecimal to binary, it is okay to have a few bits different. - Read 5bytes from register 0x10. The values can be discarded, but it is important to do this read.
- Write 0x4003 bytes of firmware to register 0x05.
For example, for old3DS what you write to register 0x05 might look like6A 68 6C 5E 0D FF FF FF FF [...] 31 33 3A 31 33 3A 34 32 00 00
. - 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.
- 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. - If you think that the MCU is revived, write
00 10 FF C0
to register 0x18, and read 5bytes from register 0x10 afterwards. - 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!