Changes

Jump to navigation Jump to search
17,468 bytes added ,  18:14, 6 September 2021
Added info on DebugPad
Line 11: Line 11:  
| 0x10161000
 
| 0x10161000
 
| 1
 
| 1
|
+
| I2C bus 1 devices
 
|-
 
|-
 
| style="background: green" | Yes
 
| style="background: green" | Yes
Line 17: Line 17:  
| 0x10161001
 
| 0x10161001
 
| 1
 
| 1
|
+
| I2C bus 1 devices
 
|-
 
|-
 
| style="background: green" | Yes
 
| style="background: green" | Yes
Line 23: Line 23:  
| 0x10161002
 
| 0x10161002
 
| 2
 
| 2
|
+
| I2C bus 1 devices
 
|-
 
|-
 
| style="background: green" | Yes
 
| style="background: green" | Yes
Line 29: Line 29:  
| 0x10161004
 
| 0x10161004
 
| 2
 
| 2
|
+
| I2C bus 1 devices
 
|-
 
|-
 
| style="background: green" | Yes
 
| style="background: green" | Yes
Line 35: Line 35:  
| 0x10144000
 
| 0x10144000
 
| 1
 
| 1
|
+
| I2C bus 2 devices
 
|-
 
|-
 
| style="background: green" | Yes
 
| style="background: green" | Yes
Line 41: Line 41:  
| 0x10144001
 
| 0x10144001
 
| 1
 
| 1
|
+
| I2C bus 2 devices
 
|-
 
|-
 
| style="background: green" | Yes
 
| style="background: green" | Yes
Line 47: Line 47:  
| 0x10144002
 
| 0x10144002
 
| 2
 
| 2
|
+
| I2C bus 2 devices
 
|-
 
|-
 
| style="background: green" | Yes
 
| style="background: green" | Yes
Line 53: Line 53:  
| 0x10144004
 
| 0x10144004
 
| 2
 
| 2
|
+
| I2C bus 2 devices
 
|-
 
|-
 
| style="background: green" | Yes
 
| style="background: green" | Yes
Line 59: Line 59:  
| 0x10148000
 
| 0x10148000
 
| 1
 
| 1
|
+
| I2C bus 3 devices
 
|-
 
|-
 
| style="background: green" | Yes
 
| style="background: green" | Yes
Line 65: Line 65:  
| 0x10148001
 
| 0x10148001
 
| 1
 
| 1
|
+
| I2C bus 3 devices
 
|-
 
|-
 
| style="background: green" | Yes
 
| style="background: green" | Yes
Line 71: Line 71:  
| 0x10148002
 
| 0x10148002
 
| 2
 
| 2
|
+
| I2C bus 3 devices
 
|-
 
|-
 
| style="background: green" | Yes
 
| style="background: green" | Yes
Line 77: Line 77:  
| 0x10148004
 
| 0x10148004
 
| 2
 
| 2
|
+
| I2C bus 3 devices
 
|}
 
|}
   Line 105: Line 105:  
| 7
 
| 7
 
| Start/busy      (0=Ready, 1=Start/busy)
 
| Start/busy      (0=Ready, 1=Start/busy)
 +
|}
 +
 +
== I2C_CNTEX ==
 +
{| class="wikitable" border="1"
 +
!  BIT
 +
!  DESCRIPTION
 +
|-
 +
| 0-1
 +
| ? Set to 2 normally.
 +
|}
 +
 +
== I2C_SCL ==
 +
{| class="wikitable" border="1"
 +
!  BIT
 +
!  DESCRIPTION
 +
|-
 +
| 0-5
 +
| ?
 +
|-
 +
| 8-12
 +
| ? Set to 5 normally.
 
|}
 
|}
    
= I2C Devices =
 
= I2C Devices =
 
{| class="wikitable" border="1"
 
{| class="wikitable" border="1"
!  Device id
+
[[I2C_Registers|Device id]]
 
!  Device bus id
 
!  Device bus id
!  Device address
+
!  Device Write Address
 +
!  Accessible via I2C [[I2C_Services|service]]
 
!  Device description
 
!  Device description
 
|-
 
|-
Line 117: Line 139:  
| 1
 
| 1
 
| 0x4a
 
| 0x4a
 +
| "i2c::MCU"
 
| Power management?(same device addr as the DSi power-management)
 
| Power management?(same device addr as the DSi power-management)
 
|-
 
|-
Line 122: Line 145:  
| 1
 
| 1
 
| 0x7a
 
| 0x7a
 +
| "i2c::CAM"
 
| Camera0?(same dev-addr as DSi cam0)
 
| Camera0?(same dev-addr as DSi cam0)
 
|-
 
|-
Line 127: Line 151:  
| 1
 
| 1
 
| 0x78
 
| 0x78
 +
| "i2c::CAM"
 
| Camera1?(same dev-addr as DSi cam1)
 
| Camera1?(same dev-addr as DSi cam1)
 
|-
 
|-
Line 132: Line 157:  
| 2
 
| 2
 
| 0x4a
 
| 0x4a
 +
| "i2c::MCU"
 
| MCU
 
| MCU
 
|-
 
|-
Line 137: Line 163:  
| 2
 
| 2
 
| 0x78
 
| 0x78
 +
| "i2c::CAM"
 
| ?
 
| ?
 
|-
 
|-
Line 142: Line 169:  
| 2
 
| 2
 
| 0x2c
 
| 0x2c
 +
| "i2c::LCD"
 
| ?
 
| ?
 
|-
 
|-
Line 147: Line 175:  
| 2
 
| 2
 
| 0x2e
 
| 0x2e
 +
| "i2c::LCD"
 
| ?
 
| ?
 
|-
 
|-
Line 152: Line 181:  
| 2
 
| 2
 
| 0x40
 
| 0x40
 +
| "i2c::DEB"
 
| ?
 
| ?
 
|-
 
|-
Line 157: Line 187:  
| 2
 
| 2
 
| 0x44
 
| 0x44
 +
| "i2c::DEB"
 
| ?
 
| ?
 
|-
 
|-
Line 162: Line 193:  
| 3
 
| 3
 
| 0xa6
 
| 0xa6
| Unknown. The device table in I2C-module had the device address changed from 0xA6 to 0xD6 with [[8.0.0-18]].
+
| "i2c::HID"
 +
| Gyroscope. The device table in I2C-module had the device address changed from 0xA6 to 0xD6 with [[8.0.0-18]].
 
|-
 
|-
 
| 10
 
| 10
 
| 3
 
| 3
 
| 0xd0
 
| 0xd0
| Gyroscope
+
| "i2c::HID"
 +
| Gyroscope (old3DS)
 
|-
 
|-
 
| 11
 
| 11
 
| 3
 
| 3
 
| 0xd2
 
| 0xd2
| ?
+
| "i2c::HID"
 +
| Gyroscope (2DS, new3DSXL, new2DSXL)
 
|-
 
|-
 
| 12
 
| 12
 
| 3
 
| 3
 
| 0xa4
 
| 0xa4
| DebugPad
+
| "i2c::HID"
 +
| DebugPad (slightly modified [https://wiibrew.org/wiki/Wiimote/Extension_Controllers/Classic_Controller_Pro Wii Classic Controller Pro])
 
|-
 
|-
 
| 13
 
| 13
 
| 3
 
| 3
 
| 0x9a
 
| 0x9a
 +
| "i2c::IR"
 
| IR
 
| IR
 
|-
 
|-
Line 187: Line 223:  
| 3
 
| 3
 
| 0xa0
 
| 0xa0
| eeprom?
+
| "i2c::EEP"
 +
| HWCAL EEPROM ([[Hardware_calibration#Header|only present on dev units where SHA256 is used for HWCAL verification]])
 +
|-
 +
| 15
 +
| 2
 +
| 0xee
 +
| "i2c::NFC"
 +
| New3DS-only [[NFC_Services|NFC]]
 +
|-
 +
| 16
 +
| 1
 +
| 0x40
 +
| "i2c::QTM"
 +
| New3DS-only [[QTM_Services|QTM]]
 
|-
 
|-
 
| 17
 
| 17
| ?
+
| 3
| ?
+
| 0x54
| Used by IR-module starting with [[8.0.0-18]]. This deviceid doesn't seem to be supported by i2c module on [[8.0.0-18]].
+
| "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 ==
 
== Device 3 ==
 +
  ro = read-only (writing is no-op)
 +
  rw = read-write
 +
  wo = write-only (reading will yield 00, FF, or unpredictable data)
 +
 +
  d* = dynamic register (explaination below this table)
 +
  s* = shared register (explaination below this table)
 +
  ds = dynamic shared (explaination below this table)
 +
 +
Reading or writing multiple bytes from/to single-byte registers increments the register ID along with it. For example reading two bytes from reg 0x00 reads regs 0x00 and 0x01.
 +
 +
This is not the case for multibyte regs (0x29, 0x2D, 0x4F, 0x61 and 0x7F), plus reg 0x60.
 +
 
{| class="wikitable" border="1"
 
{| class="wikitable" border="1"
 
!  REGISTER
 
!  REGISTER
 
!  WIDTH
 
!  WIDTH
 +
!  INFO
 
!  DESCRIPTION  
 
!  DESCRIPTION  
 +
|-
 +
| 0x00
 +
| s
 +
| ro
 +
| Version high
 +
|-
 +
| 0x01
 +
| s
 +
| ro
 +
| Version low
 +
|-
 +
| 0x02
 +
| d
 +
| rw
 +
| For bit0 and 1 values, writing will mask away/"acknowledge" the event, set to 3 by mcuMainLoop on reset if reset source is Watchdog
 +
  bit0: RTC clock value got reset to defaults
 +
  bit1: Watchdog reset happened
 +
  bit5: TWL MCU reg: volume mode (0: 8-step, 1: 32-step)
 +
  bit6: TWL MCU reg: NTR (0) vs TWL mode (1)
 +
  bit7: TWL MCU reg: Uses NAND
 
|-
 
|-
 
| 0x03
 
| 0x03
| 8
+
| ds
| ?
+
| rw
 +
| Top screen Vcom
 
|-
 
|-
 
| 0x04
 
| 0x04
| 8
+
| ds
 +
| rw
 +
| Bottom screen Vcom
 +
|-
 +
| 0x05
 +
- 0x07
 +
| s
 +
| rw
 +
| Danger zone - [[MCU_Services#MCU_firmware_versions|MCU unlock sequence]] is written 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|MCUHWC:GetSoundVolume]]
 +
|-
 +
| 0x0A
 +
| s
 +
| ro
 +
| Battery temperature (in Celcius?)
 +
|-
 +
| 0x0B
 +
| s
 +
| ro
 +
| Battery percentage
 +
|-
 +
| 0x0C
 +
| s
 +
| ro
 +
| Battery percentage, fractional part (seems to have a resolution of around 0.1% according to tests)
 +
|-
 +
| 0x0D
 +
| s
 +
| ro
 +
| System voltage
 +
|-
 +
| 0x0E
 +
| s
 +
| ro
 
| ?
 
| ?
 
|-
 
|-
| 0x09
+
| 0x0F
| 1
+
| s
| Sound volume: 0x0..0x3F.
+
| ro
 +
| Flags: bit7-5 are read via [[MCU_Services|mcu::GPU]]. The rest of them are read via [[MCU_Services|mcu::RTC]].
 +
  bit01: ShellState
 +
  bit03: AdapterState
 +
  bit04: BatteryChargeState
 +
  bit05: Bottom screen backlight on
 +
  bit06: Top screen backlight on
 +
  bit07: GPU on(?)
 +
|-
 +
| 0x10
 +
- 0x13
 +
| s
 +
| ro
 +
| Received interrupt bitmask, see register 0x18 for possible values 
 +
If no interrupt was received this register is 0
 +
|-
 +
| 0x14
 +
| s
 +
| ro
 +
| Unused and unwritable byte :(
 +
|-
 +
| 0x15
 +
- 0x17
 +
| s
 +
| rw
 +
| Unused and unreferenced free RAM! Good for userdata.
 
|-
 
|-
 
| 0x18
 
| 0x18
| 8
+
- 0x1B
| ?
+
| s
 +
| rw
 +
| Interrupt mask for register 0x10 (0=enabled,1=disabled)
 +
  bit00: Power button press (for 27 "ticks")
 +
  bit01: Power button held (for 375 "ticks"; the 3DS turns off regardless after a fixed time)
 +
  bit02: HOME button press (for 5 "ticks")
 +
  bit03: HOME button release
 +
  bit04: WiFi switch button
 +
  bit05: Shell close
 +
  bit06: Shell open
 +
  bit07: Fatal hardware condition([[Services#Notifications|?]]) (sent when the MCU gets reset by the Watchdog timer)
 +
  bit08: Charger removed
 +
  bit09: Charger plugged in
 +
  bit10: RTC alarm (when some conditions are met it's sent when the current day and month and year matches the current RTC time)
 +
  bit11: ??? (accelerometer related)
 +
  bit12: HID update
 +
  bit13: Battery percentage status change (triggered at 10%, 5%, and 0% while discharging)
 +
  bit14: Battery stopped charging (independent of charger state)
 +
  bit15: Battery started charging
 +
Nonmaskable(?) interrupts
 +
  bit16: ???
 +
  bit17: ??? (opposite even for bit16)
 +
  bit22: Volume slider position change
 +
  bit23: ??? Register 0x0E update
 +
  bit24: ??? (the off event for below bit)
 +
  bit25: ??? (triggered when something related to the GPU is turned on, most likely backlight)
 +
  bit26: ??? (???)
 +
  bit27: ??? (???)
 +
  bit28: ??? (???)
 +
  bit29: ??? backlight on?
 +
  bit30: bit set by mcu sysmodule
 +
  bit31: bit set by mcu sysmodule
 +
|-
 +
| 0x1C
 +
- 0x1F
 +
| s
 +
| rw
 +
| Unused and unreferenced free RAM! Good for userdata.
 
|-
 
|-
 
| 0x20
 
| 0x20
| 8
+
| d
| Writing u8 value 4 here triggers a hardware system reboot. Writing u8 value 8 triggers a shutdown via power-off?
+
| wo
 +
| System power control:
 +
  bit0: power off
 +
  bit1: full reboot (unused). Discards things like [[CONFIG9_Registers#CFG9_BOOTENV|CFG9_BOOTENV]]
 +
    - Asserts RESET1 via PMIC command (?) (deasserts nRESET1). This could be the reset that controls some CFG9 registers
 +
    - Asserts RESET2 (P0.1 = 0, PM0.1 = 0 (output)) (deasserts nRESET2)
 +
    - Asserts FCRAM_RESET (P3.0 = 0) (deasserts nFCRAM_RESET)
 +
  bit2: normal reboot. Preserves [[CONFIG9_Registers#CFG9_BOOTENV|CFG9_BOOTENV]], etc.
 +
    - Asserts RESET2 (P0.1 = 0, PM0.1 = 0)
 +
    - If in NTR emulation mode (see reg 0x02), asserts FCRAM_RESET (P3.0 = 0)
 +
    - Resets TWL MCU i2c registers
 +
  bit3: FCRAM reset (present in by LgyBg. Unused because a system reboot does the same thing & a PDN reg also possibly implements this function)
 +
    - Asserts FCRAM_RESET (P3.0 = 0)
 +
  bit4: signal that sleep mode is about to be entered (used by PTM)
 +
Bit 4 sets a bit at a RAM address which seems to control the watcdog timer state, then this bit is immediately unmasked. This field has a bitmask of 0x0F.
 +
 
 +
If any of the reset bits is set, the MCU waits for 5ms, then deasserts RESET1 (via PMIC), RESET2 (PM0.1 = 1 (input)) and FCRAM_RESET (P3.0 = 1), and reinitializes some other various registers after a 100ms delay.
 +
|-
 +
| 0x21
 +
| d
 +
| wo
 +
| Used in legacy mode to signal events for TWL MCU "emulation" (written to REG[0x5D])? Software then asserts the TWL MCU IRQ pin via [[#LGY_GPIOEMU_MASK|Legacy I/O registers]].
 +
  bit0: Signal TWL POWER button click
 +
  bit1: Signal TWL reset
 +
  bit2: Signal TWL power off
 +
  bit3: Signal TWL battery low
 +
  bit4: Signal TWL battery empty
 +
  bit5: Signal TWL volume button click
 
|-
 
|-
 
| 0x22
 
| 0x22
| 8
+
| d
| ?
+
| wo
 +
| 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
 +
 
 +
Bits 4 and 5 have no effect on a 2DS because the backlight source is the bottom screen.
 +
The rest of the bits are masked away.
 
|-
 
|-
 
| 0x23
 
| 0x23
| 8
+
| d
 +
| wo
 +
| Writing 0x72 ('r') resets the MCU, but this is stubbed on retail?
 +
|-
 +
| 0x24
 +
| s
 +
| rw
 +
| Watchdog timer. This must be set *before* the timer is triggered, otherwise the old value is used. Value zero disables the watchdog.
 +
|-
 +
| 0x25
 +
| s
 +
| rw
 
| ?
 
| ?
 
|-
 
|-
| 0x24
+
| 0x26
| 8
+
| s
 +
| rw
 
| ?
 
| ?
 +
|-
 +
| 0x27
 +
| sd
 +
| rw
 +
| Raw volume slider state
 
|-
 
|-
 
| 0x28
 
| 0x28
| 8
+
| s
| ?
+
| rw
 +
| Brightness of the WiFi/Power LED
 
|-
 
|-
 
| 0x29
 
| 0x29
| 8
+
| sd(5)
| ?
+
| rw
 +
| Power mode indicator state (read-write)
 +
  1 = forced default blue
 +
  2 = sleep mode animation
 +
  3 = "power off" mode
 +
  4 = disable blue power LED and turn on red power LED
 +
  5 = disable red power LED and turn on blue power LED
 +
  6 = animate blue power LED off and flash red power LED
 +
  anything else = automatic mode
 +
The other 4 bytes (32bits) affect the pattern of the red power LED (write only)
 
|-
 
|-
 
| 0x2A
 
| 0x2A
| 8
+
| s
| ?
+
| rw
 +
| WiFi LED state, non-0 value turns on the WiFi LED, 4 bits wide
 
|-
 
|-
 
| 0x2B
 
| 0x2B
| 8
+
| s
| ?
+
| rw
 +
| Camera LED state, 4bits wide,
 +
  0, 3, 6-0xF = off
 +
  1 = slowly blinking
 +
  2 = constantly on
 +
  3 = "TWL" mode
 +
  4 = flash once
 +
  5 = delay before changing to 2
 
|-
 
|-
 
| 0x2C
 
| 0x2C
| 8
+
| s
| ?
+
| rw
 +
| 3D LED state, 4 bits wide
 
|-
 
|-
 
| 0x2D
 
| 0x2D
 
| 0x64
 
| 0x64
| This is used for [[MCURTC:SetInfoLEDPattern|controlling]] the notification LED(see [[MCURTC:SetInfoLEDPatternHeader]] as well), when this register is written.
+
| wo
 +
| This is used for [[MCURTC:SetInfoLEDPattern|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. Writing past the size of this register seems to do nothing.
 
|-
 
|-
 
| 0x2E
 
| 0x2E
| 1
+
| s
| This [[MCURTC:GetInfoLEDStatus|returns]] the notification LED status when read.
+
| ro
 +
| This [[MCURTC:GetInfoLEDStatus|returns]] the notification LED status when read (1 means new cycle started)
 +
|-
 +
| 0x2F
 +
| s
 +
| wo?
 +
| ??? The write function for this register is stubbed.
 
|-
 
|-
 
| 0x30
 
| 0x30
| 8
+
- 0x36
| ?
+
| ds
 +
| 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: seconds
 +
  byte 1: minutes
 +
  byte 2: hours
 +
  byte 3: current week (unused)
 +
  byte 4: days
 +
  byte 5: months
 +
  byte 6: years
 +
|-
 +
| 0x37
 +
| s
 +
| rw
 +
| RTC time byte 7: leap year counter / "watch error correction" register (unused in code)
 +
|-
 +
| 0x38
 +
- 0x3C
 +
| s
 +
| rw
 +
| RTC alarm registers
 +
  byte 0: minutes
 +
  byte 1: hours
 +
  byte 2: day
 +
  byte 3: month
 +
  byte 4: year
 +
|-
 +
| 0x3B
 +
| s
 +
| rw
 +
| Could be used on extremely old MCU_FIRM versions to upload [[MCU_Services#MCU_firmware_versions|MCU firmware]] if reg 0xF == 0 and reg 0x10 == 1 (presumably major and minor version fields for mcufw 0.1 which largely predates factory firm).
 +
|-
 +
| 0x3D
 +
0x3E
 +
| ds
 +
| ro
 +
| RTC tick counter / "ITMC" (when resets to 0 the seconds increase)
 +
Only reading 0x3D will update the in-RAM value
 +
|-
 +
| 0x3F
 +
| d
 +
| wo
 +
| 2 bits
 +
  bit0: Asserts RESET1 (P0.0 = 0, PM0.0 = 0 (output)) but does NOT deassert it (wtf?). This seems to kill the entire SoC: is it because it doesn't deassert it, or does it not deassert it because the SoC hangs anyway? This is the pin that controls some security-critical regs like CFG9_BOOTENV!
 +
  bit1: turns on a prohibited bit in an RTC Control register and turns P12 into an output
 +
|-
 +
| 0x40
 +
| s
 +
| rw
 +
| Tilt sensor sampling mode. Bits 0 and 1 control the mode. If bits 0 or 1 are set then the tilt sensor is enabled and sampled.
 +
|-
 +
| 0x41
 +
| s
 +
| rw
 +
| Index selector for register 0x44
 +
|-
 +
| 0x42
 +
| s
 +
| rw
 +
| Unused?
 +
|-
 +
| 0x43
 +
| s
 +
| rw
 +
| Unused???, accelometer related
 +
|-
 +
| 0x44
 +
| s
 +
| rw
 +
| ???, pedoometer related(?)
 +
|-
 +
| 0x45
 +
- 0x4A
 +
| s
 +
| ro
 +
| Tilt sensor 3D rotation from the 12bit ADC, left shifted 4 to fit in a 16bit signed short, relative to the 3DS bottom screen
 +
{| class="wikitable" border="1"
 +
!  AXIS
 +
!  V=0x00
 +
!  V=0x40
 +
!  V=0xC0
 +
|-
 +
| X (left/right)
 +
| held up vertically
 +
| rotated left 90° like a steering wheel
 +
| rotated right 90° like a steering wheel
 +
|-
 +
| Y (forwards/backwards)
 +
| laid flat on the desk with the screen facing up
 +
| held up vertically
 +
| held up vertically with screen facing upside-down
 +
|-
 +
| Z (???)
 +
| ???
 +
| ???
 +
| ???
 +
|}
 +
|-
 +
| 0x4B
 +
| s
 +
| rw
 +
| PedometerStepCount (for the current day)
 +
|-
 +
| 0x4C
 +
0x4D
 +
| ??
 +
| ??
 +
| ??
 +
|-
 +
| 0x4E
 +
| d
 +
| rw
 +
| ??? this = (0xFFE9E & 1) ? 0x10 : 0
 +
|-
 +
| 0x4F
 +
| d(6)
 +
| ro
 +
|
 +
|-
 +
| 0x50
 +
| s
 +
| rw
 +
| ???
 
|-
 
|-
| 0x31
+
| 0x51
| 8
+
| s
| ?
+
| rw
 +
| ???
 
|-
 
|-
| 0x32
+
| 0x52
| 8
+
- 0x57
 +
| s
 +
| rw
 
| ?
 
| ?
 
|-
 
|-
| 0x33
+
| 0x58
| 8
+
| s
| ?
+
| rw
 +
| Register-mapped ADC register
 +
DSP volume slider 0% volume offset (setting this to 0xFF will esentially mute the DSP as it's the volume slider's maximum raw value)
 
|-
 
|-
| 0x34
+
| 0x59
| 8
+
| s
| ?
+
| rw
 +
| Register-mapped ADC register
 +
DSP volume slider 100% volume offset (setting both this and the above to 0 will disable the volume slider with 100% volume, setting this to a lower value than the above will make the volume slider have only 2 states; on and off)
 
|-
 
|-
| 0x35
+
| 0x5A
| 8
+
| s
| ?
+
| ro/rw
 +
| Invalid, do not use! On newer MCU_FIRM versions this is unused, but on older MCU_FIRM versions this is a read-only counter.
 
|-
 
|-
| 0x36
+
| 0x5B
| 8
+
- 0x5F
| ?
+
| s
 +
| -
 +
| These registers are out of bounds (0xFFC00 and up), they don't exist, writing is no-op, reading will yield FFs.
 
|-
 
|-
| 0x37
+
| 0x60
| 8
+
| d
| ?
+
| rw
 +
| Free register bank address (index) select
 +
Selects the index to read from in the free register bank, up to 200. Used in conjunction with reg 0x61.
 +
 
 +
  byte 0: bit0 = "WirelessDisabled", bit1 = "SoftwareClosed", bit2 = "PowerOffInitiated", bit3 = "LgyNativeResolution", bit4 = "LegacyJumpProhibited"
 +
  byte 1: Legacy LCD data
 +
  bytes 2 and 3: Local Friend Code counter
 +
  bytes 4 and 5: UUID clock sequence
 +
  bytes 6 and 7: Unused
 +
  bytes 8 to 175: Playtime data for legacy titles
 +
  bytes 176 to 188: Playtime data
 +
  bytes 188 to 199: Unused
 
|-
 
|-
| 0x38
+
| 0x61
| 8
+
| d(200)
| ?
+
| rw
 +
| Free register bank, data is read from/written to here.
 +
 
 +
Accessing N bytes of this register increments the selected index by N.
 
|-
 
|-
| 0x39
+
| 0x62 - 0x7E
| 8
+
| s
| ?
+
| -
 +
| These registers don't exist, writing is no-op, reading will yield FFs.
 
|-
 
|-
| 0x3A
+
| 0x7F
| 8
+
| d(9-0x13)
| ?
+
| ro
 +
| Various system state information (debug pointer table)
 +
  byte 0x00: Console type, see [[Configuration_Memory#MCU_HW_INFO|here]]
 +
  byte 0x01: PMIC vendor code
 +
  byte 0x02: Battery vendor code
 +
  byte 0x03: MGIC version (major?)
 +
  byte 0x04: MGIC version (minor?)
 +
  byte 0x05: RCOMP(?)
 +
  byte 0x06: battery related? (seems to decrease while charging and increase while discharging)
 +
  byte 0x09: system model (see [[Cfg:GetSystemModel#System_Model_Values|Cfg:GetSystemModel]] for values)
 +
  byte 0x0A: Red Power LED mode (0 = off, 1 = on)
 +
  byte 0x0B: Blue Power LED intensity  (0x00 - 0xFF)
 +
  byte 0x0D: RGB LED red intensity
 +
  byte 0x0E: RGB LED green intensity
 +
  byte 0x0F: RGB LED blue intensity
 +
  byte 0x11: WiFi LED brightness
 +
  byte 0x12: raw button states?
 +
    bit0: unset while Power button is held
 +
    bit1: unset while HOME button is held
 +
    bit2: unset while WiFi slider is held
 +
    bit5: unset while the charging LED is active
 +
    bit6: unset while charger is plugged in
 +
 
 +
On MCU_FIRM major version 1 the size of this is 9, reading past the 9th byte will yield AA instead of FF.
 
|-
 
|-
| 0x3B
+
| 0x80
| 8
+
- 0xFF
| ?
+
| s
 +
| -
 +
| These registers don't exist, writing is no-op, reading will yield FFs.
 +
|}
 +
 
 +
Shared register: the letter "s"  means that the given register is in a "shared register pool", meaning the resgister is in the register pool in RAM at address <code>0xFFBA4 + registernumber</code>.
 +
 
 +
Dynamic register: these registers aren't in the shared pool, they just "pretend" to be there. These registers often don't retain their set value, change rapidly, or control various hardware.
 +
 
 +
Non-shared (dynamic) register: it's a register whose contents separate from the shared register pool. Messing with these registers will not affect the shared register pool at all.
 +
 
 +
On old versions of MCU_FIRM none of the invalid registers are masked away by the read handler function, but are still read-only. Newer MCU_FIRM versions return the hardcoded value FF instead.
 +
 
 +
== Device 5 & 6 ==
 +
LCD controllers for main/sub displays, most likely.
 +
 
 +
{| class="wikitable" border="1"
 +
!  Register
 +
!  Width
 +
!  Name
 +
!  Description
 
|-
 
|-
| 0x3C
+
| 0x1
 
| 8
 
| 8
 
| ?
 
| ?
 +
|
 
|-
 
|-
| 0x41
+
| 0x11
 
| 8
 
| 8
 
| ?
 
| ?
 +
|
 
|-
 
|-
| 0x43
+
| 0x40
 
| 8
 
| 8
| ?
+
| CMD_IN/CMD_RESULT1
 +
| Write to trigger a command? Seen commands: 0xFF=Reset?, 0x62=IsFinished?. Result is stored in CMD_RESULT1:CMD_RESULT0.
 
|-
 
|-
| 0x4E
+
| 0x41
 
| 8
 
| 8
| ?
+
| CMD_RESULT0
 +
| Read result
 
|-
 
|-
 
| 0x50
 
| 0x50
 
| 8
 
| 8
 
| ?
 
| ?
 +
|
 
|-
 
|-
| 0x51
+
| 0x60
| 8
  −
| ?
  −
|-
  −
| 0x58
   
| 8
 
| 8
 
| ?
 
| ?
 +
|
 
|-
 
|-
| 0x60
+
| 0xFE
 
| 8
 
| 8
 
| ?
 
| ?
 +
|
 
|}
 
|}
    
== Device 10 ==
 
== Device 10 ==
 +
See the datasheet linked to on the [[Hardware]] page for reference.
 +
 +
== Device 11 ==
 
See the datasheet linked to on the [[Hardware]] page for reference.
 
See the datasheet linked to on the [[Hardware]] page for reference.
   Line 356: Line 823:  
|}
 
|}
   −
This is the DebugPad device, see [[HID_Shared_Memory|here]].
+
This is a [https://wiibrew.org/wiki/Wiimote/Extension_Controllers/Classic_Controller_Pro Wii Classic Controller Pro] which was slightly modified to have an encrypted device type of 0xF0 [https://wiibrew.org/wiki/Wiimote/Extension_Controllers#The_New_Way instead of 0xFD].
 +
 
 +
See [[HID_Shared_Memory#Offset_0x238|here]] for the HID shared memory report format.
    
== Device 13 ==
 
== Device 13 ==
Line 446: Line 915:  
|}
 
|}
   −
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."
+
See the [http://www.alldatasheet.net/datasheet-pdf/pdf/347838/NXP/SC16IS750IBS.html 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 [[Config_Services|Cfg]]-sysmodule via the i2c::EEP service. This is presumably EEPROM going by the service name.
 +
 
 +
The Cfg-module code which loads the [[Flash_Filesystem|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_Services|NFC]] controller "I2C" interface. This device is accessed via the WriteDeviceRaw/ReadDeviceRaw I2C service [[I2C_Services|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:
 +
{| class="wikitable" border="1"
 +
!  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  ===
 +
{| class="wikitable" border="1"
 +
!  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.
 +
|}
215

edits

Navigation menu