I2C Registers
Registers
| Old3DS | Name | Address | Width | Used by |
|---|---|---|---|---|
| Yes | I2C1_DATA | 0x10161000 | 1 | I2C bus 1 devices |
| Yes | I2C1_CNT | 0x10161001 | 1 | I2C bus 1 devices |
| Yes | I2C1_CNTEX | 0x10161002 | 2 | I2C bus 1 devices |
| Yes | I2C1_SCL | 0x10161004 | 2 | I2C bus 1 devices |
| Yes | I2C2_DATA | 0x10144000 | 1 | I2C bus 2 devices |
| Yes | I2C2_CNT | 0x10144001 | 1 | I2C bus 2 devices |
| Yes | I2C2_CNTEX | 0x10144002 | 2 | I2C bus 2 devices |
| Yes | I2C2_SCL | 0x10144004 | 2 | I2C bus 2 devices |
| Yes | I2C3_DATA | 0x10148000 | 1 | I2C bus 3 devices |
| Yes | I2C3_CNT | 0x10148001 | 1 | I2C bus 3 devices |
| Yes | I2C3_CNTEX | 0x10148002 | 2 | I2C bus 3 devices |
| Yes | I2C3_SCL | 0x10148004 | 2 | I2C bus 3 devices |
I2C_CNT
| BIT | DESCRIPTION |
|---|---|
| 0 | Stop (0=No, 1=Stop/last byte) |
| 1 | Start (0=No, 1=Start/first byte) |
| 2 | Pause (0=Transfer Data, 1=Pause after Error, used with/after Stop) |
| 4 | Ack Flag (0=Error, 1=Okay) (For DataRead: W, for DataWrite: R) |
| 5 | Data Direction (0=Write, 1=Read) |
| 6 | Interrupt Enable (0=Disable, 1=Enable) |
| 7 | Start/busy (0=Ready, 1=Start/busy) |
I2C Devices
| Device id | Device bus id | Device Write Address | Accessible via I2C service | Device description |
|---|---|---|---|---|
| 0 | 1 | 0x4a | "i2c::MCU" | Power management?(same device addr as the DSi power-management) |
| 1 | 1 | 0x7a | "i2c::CAM" | Camera0?(same dev-addr as DSi cam0) |
| 2 | 1 | 0x78 | "i2c::CAM" | Camera1?(same dev-addr as DSi cam1) |
| 3 | 2 | 0x4a | "i2c::MCU" | MCU |
| 4 | 2 | 0x78 | "i2c::CAM" | ? |
| 5 | 2 | 0x2c | "i2c::LCD" | ? |
| 6 | 2 | 0x2e | "i2c::LCD" | ? |
| 7 | 2 | 0x40 | "i2c::DEB" | ? |
| 8 | 2 | 0x44 | "i2c::DEB" | ? |
| 9 | 3 | 0xa6 | "i2c::HID" | Unknown. The device table in I2C-module had the device address changed from 0xA6 to 0xD6 with 8.0.0-18. |
| 10 | 3 | 0xd0 | "i2c::HID" | Gyroscope |
| 11 | 3 | 0xd2 | "i2c::HID" | ? |
| 12 | 3 | 0xa4 | "i2c::HID" | DebugPad |
| 13 | 3 | 0x9a | "i2c::IR" | IR |
| 14 | 3 | 0xa0 | "i2c::EEP" | eeprom? |
| 15 | 2 | 0xee | "i2c::NFC" | New3DS-only NFC |
| 16 | 1 | 0x40 | "i2c::QTM" | New3DS-only QTM |
| 17 | 3 | 0x54 | "i2c::IR" | Used by IR-module starting with 8.0.0-18, for New3DS-only HID via "ir:rst". This deviceid doesn't seem to be supported by i2c module on 8.0.0-18(actual support was later added in New3DS i2c module). |
Notice: These device addresses are used for writing to the respective device, for reading bit0 must be set (see I2C protocol). Thus, the actual device address is >> 1.
Device 3
| REGISTER | WIDTH | INFO | DESCRIPTION |
|---|---|---|---|
| 0x00 | s | ro | Version high |
| 0x01 | s | ro | Version low |
| 0x04 | s | rw | Top screen flicker |
| 0x05 | s / 0x4003? | rw / ? | Bottom screen flicker or Danger zone - MCU firmware is uploaded here (???) |
| 0x08 | s | ro | Raw 3D slider position |
| 0x09 | s | ro | Volume slider state (0x00 - 0x3F)
This is the same value returned by MCUHWC:GetSoundVolume |
| 0x0B | s | ro | Battery percentage |
| 0x0D | s | ro | System voltage |
| 0x0F | s | ro | Flags: bit7-5 are read via mcu::GPU. The rest of these are read via mcu::RTC: bit4 = BatteryChargeState. bit3 = AdapterState. bit1 = ShellState. |
| 0x10 | s | ro | Special HID status flags: bit0 = power button pressed, bit1 = power button pressed long, bit2 = home button pressed, bit3 = home button released, bit4 = wifi slider enabled, bit5 = shell got closed, bit6 = shell got opened. If nothing has changed this register is 0. |
| 0x12 | s | ro | 0x40 if volume slider position changed |
| 0x20 | s | wo(?) | System power control - bit0 = power off, bit1 = reboot (unused?). bit2 = reboot (used by mcu-module and LgyBg). bit3 = used by LgyBg to power off, causes hangs in 3DS-mode. bit4 = doesn't seem to do anything, but an mcu::RTC command uses this. Other bits are unused, and seem to do nothing. |
| 0x22 | s | rw(?) | Used to set LCD states. bit0 = don't push to LCDs, bit1 = push to LCDs, bit2 = bottom screen backlight off, bit3 = bottom screen backlight on, bit4 = top screen backlight off, bit5 = top screen backlight on |
| 0x24 | s | ?? | Watchdog timer. This must be set *before* the timer is triggered, otherwise the old value is used. Value zero disables the watchdog. |
| 0x27 | s | ro | Raw volume slider state |
| 0x28 | s | rw | Brightness of the WiFi/Power LED |
| 0x29 | dynamic(?) | rw | Repeat register, any byte written here gets repeated indefinitely(?) |
| 0x2A | s | rw | WiFi LED state, non-0 value turns on the WiFi LED, capped at 0x0F |
| 0x2B | s | rw | Camera LED state, 0, 3, 6-0xF = off, 1 = slowly blinking, 2 = constantly on, 4 = flash once, 5 = delay before changing to 2 |
| 0x2C | s | rw | 3D LED state, capped at 0x0F |
| 0x2D | 0x64 | wo | This is used for controlling the notification LED (see MCURTC:SetInfoLEDPatternHeader as well), when this register is written. It's possible to write data here with size less than 0x64, and only that portion of the pattern data will get overwritten. Reading from this register only returns zeroes, so it's considered write-only. |
| 0x2E | s | ro | This returns the notification LED status when read. |
| 0x30
- 0x37 |
s | rw | RTC time (system clock). 7 bytes are read from this. The upper nibble of each byte encodes 10s (BCD), so each byte is post-processed with (byte & 0xF) + (10 * (byte >> 4)). Byte 0 encodes seconds, byte 1 minutes, byte 2 hours, byte *4* days, byte 5 months and byte 6 years (byte 3 is unused?) |
| 0x3D | s (2) | ro | RTC tick counter (resets to 0 when the seconds increase)
It seems to bug out register 0x3E due to having a size of 2 in the shared register pool |
| 0x3F | s | rw(?) | Peripheral power related? bit0 seems to depower everything, pressing the power key afterwards instantly turns the whole 3DS off |
| 0x46 | s | ro | Gyro Y(?) axis rotation (0x00 = flat, 0x40 = 3DS standing on right side, 0xBE = 3DS standing on left side) |
| 0x48 | s | ro | Gyro Z(?) axis rotation (0x00 = flat, 0x40 = 3DS standing horizontally, 0xBE = 3DS base is horizontally upside-down) |
| 0x4A | s | ro | Gyro X(?) axis rotation (0x00 = 3DS base facing upwards, 0x40 = face-down flat, 0xBE = standing(?) flat) |
| 0x4F | 6(?) | ro | Unkonwn. Reading past the 6th byte is FF-filled, so register size of 6 is assumed. |
| 0x60 | 0x100(?) | ro(?)
first byte is wo |
Looping queue register
Writing to first byte resets the queue position to the nth element Reading from this register causes the values to shift up by `readsize-1`(needs confirmation) bytes after returning `readsize-1` bytes from the top of the stack (first byte is read-only, so is always zero) |
| 0x61 | 0x100(?) | rw | Writing to this register pushes values on top of register 0x60's stack. Reading from this register doesn't advance the stack.
The first byte is used to store flags for managing FIRM/NS state - bit0 = "WirelessDisabled", bit1 = "SoftwareClosed", bit2 = "PowerOffInitiated", bit4 = "LegacyJumpProhibited". This register survives power-off, but does not seem to be saved to non-volatile storage (does not survive battery pulls). This register doesn't seem to actually control MCU behaviour by itself, it just seems to be used for storing arbitrary data. |
| 0x7F | 19(?) | ro | Unknown.
byte 06: battery related? (seems to decrease while charging and increase while discharging) byte 10: power LED related? 0 is off, 1 is red byte 13: RGB LED red factor byte 14: RGB LED green factor byte 15: RGB LED blue factor byte 17: WiFi LED brightness byte 18: raw button states? bit0: unset while power button is held, bit1: unset while home button is held, bit2: unset while Wifi slider is held, bit4: unset when charger is plugged in, bit6: unset when charging LED is active this byte is reset to 0 before an svcBreak takes effect |
| 0x80
- 0xFF |
s | invalid (ro) | These registers don't exist at all, thus reading them will yield 0xFF |
Note: the letter "s" in the size field means that the given register is in a "shared register pool", meaning if you read/write with size more than 1 you can read the next `readamount-1` of shared registers. It's possible to corrupt the shared value of a "non-shared" register by writing into a shared register with a size bigger than one. Writing more than 0x100 bytes into a shared register will corrupt all writable registers, including the shared portion of "non-shared" registers.
Non-shared register: it's a register separate from the shared register pool. Messing with these registers will not affect the shared register pool at all.
Device 5 & 6
LCD controllers for main/sub displays, most likely.
| Register | Width | Name | Description |
|---|---|---|---|
| 0x1 | 8 | ? | |
| 0x11 | 8 | ? | |
| 0x40 | 8 | CMD_IN/CMD_RESULT1 | Write to trigger a command? Seen commands: 0xFF=Reset?, 0x62=IsFinished?. Result is stored in CMD_RESULT1:CMD_RESULT0. |
| 0x41 | 8 | CMD_RESULT0 | Read result |
| 0x50 | 8 | ? | |
| 0x60 | 8 | ? | |
| 0xFE | 8 | ? |
Device 10
See the datasheet linked to on the Hardware page for reference.
Device 12
| REGISTER | WIDTH | DESCRIPTION |
|---|---|---|
| 0x0 | 21 | DebugPad state. |
This is the DebugPad device, see here.
Device 13
| Raw I2C register address | Internal register address | Width | Description |
|---|---|---|---|
| 0x0 | 0x0 | 0x40 | RHR / THR (data receive/send FIFO) |
| 0x8 | 0x1 | 0x1 | IER |
| 0x10 | 0x2 | 0x1 | FCR/IIR |
| 0x18 | 0x3 | 0x1 | LCR |
| 0x20 | 0x4 | 0x1 | MCR |
| 0x28 | 0x5 | 0x1 | LSR |
| 0x30 | 0x6 | 0x1 | MSR/TCR |
| 0x38 | 0x7 | 0x1 | SPR/TLR |
| 0x40 | 0x8 | 0x1 | TXLVL |
| 0x48 | 0x9 | 0x1 | RXLVL |
| 0x50 | 0xA | 0x1 | IODir |
| 0x58 | 0xB | 0x1 | IOState |
| 0x60 | 0xC | 0x1 | IoIntEna |
| 0x68 | 0xD | 0x1 | reserved |
| 0x70 | 0xE | 0x1 | IOControl |
| 0x78 | 0xF | 0x1 | EFCR |
See the datasheet linked to on the Hardware page for reference. From that datasheet, for the structure of the I2C register address u8: "Bit 0 is not used, bits 2:1 select the channel, bits 6:3 select one of the UART internal registers. Bit 7 is not used with the I2C-bus interface, but it is used by the SPI interface to indicate a read or a write operation."
Device 14
Used by Cfg-sysmodule via the i2c::EEP service. This is presumably EEPROM going by the service name.
The Cfg-module code which loads the CCAL(nandro:/sys/{HWCAL0.dat/HWCAL1.dat}) file from NAND will load it from I2C instead, if a certain state flag is non-zero. Likewise for the function which writes CCAL to NAND. HMAC/hash verification after loading is skipped when the CCAL was loaded from I2C.
Device 15
This the New3DS NFC controller "I2C" interface. This device is accessed via the WriteDeviceRaw/ReadDeviceRaw I2C service commands.
Since the *Raw commands are used with this, this device has no I2C registers. Instead, raw data is transfered after the I2C device is selected. Hence, WriteDeviceRaw is used for sending commands to the controller, while ReadDeviceRaw is for receiving responses from the controller. Certain commands may return multiple command responses.
Command request / response structure:
| Offset | Size | Description |
|---|---|---|
| 0x0 | 0x1 | Normally 0x10? |
| 0x1 | 0x1 | Command source / destination. |
| 0x2 | 0x1 | CmdID |
| 0x3 | 0x1 | Payload size. |
Following the above header is the payload data(when payload size is non-zero), with the size specified in the header. The command response payload is usually at least 1-byte, where that byte appears to be normally 0x0. For command requests the payload data is the command parameters.
For command requests sent to the NFC tag itself, Cmd[1]=0x0 and CmdID=0x0. The command request payload data here is the actual command request data for the NFC tag, starting with the CmdID u8 at payload+0.
During NFC module startup, a certain command is sent to the controller which eventually(after various cmd-reply headers etc) returns the following the payload after the first byte in the payload:
000000: 44 65 63 20 32 32 20 32 30 31 32 31 34 3a 35 33 Dec 22 201214:53 000010: 3a 35 30 01 05 0d 46 05 1b 79 20 07 32 30 37 39 :50...F..y .2079 000020: 31 42 35 1B5
Or that is: "Dec 22 201214:53:50<binary>20791B5". Therefore, this appears to return the part-number of the NFC controller(other command request(s) / response(s) use this part-number value too).
NFC controller commands
| CmdRequest[1] | CmdID | Payload data for parameters | Description |
|---|---|---|---|
| 0x2E | 0x2F | Firmware image for this chunk, size varies. | This is used during NFC module startup to upload the firmware image to the NFC controller. This is used repeatedly to upload multiple chunks of the image. |