The RL78 short address disassembly was in fact wrong, my MCU disassembly is about 10000 lines, and it did have about 500 mistakes with wrong addresses : /
I got it repaired by spending 3-4 days on carefully using search/replace to fix the addresses (the RAM addresses were relative easy (but needed caution for replacing only 8bit addresses, not 16bit addresses), but replacing RAM by SFRs (and vice-versa) needed some more caution).
The funny thing is that I didn't notice the error earlier in past some months, but it didn't really matter for RAM, and for the SFRs it did just make them look like being RAM flags (now I know that those flags are actually direct reads/writes to the GPIO port bits).
Here's a summary of the GPIO Port bits (and ADC inputs, and I2C data registers):
Code: Select all
[MCU_SFR_P0].0 ;related to POW[xxh] ?
[MCU_SFR_P0].1 ;reset (/RES) ?
[MCU_SFR_P0].2-7 ;unused
;---
[MCU_SFR_P1].0-6 ;unused
[MCU_SFR_P1].6 ;power for ADC(9)? ;\somewhat power for ADC(8,9) pull-up?
[MCU_SFR_P1].7 ;power for ADC(8)? ;/
;---
[MCU_SFR_P2].0 ;home.button?
[MCU_SFR_P2].1-2 ;unused
[MCU_SFR_P2].3 ;? cleared
[MCU_SFR_P2].4 ;? charge
[MCU_SFR_P2].5 ;? cleared
[MCU_SFR_P2].6-7 ;unused
;---
[MCU_SFR_P3].0 ;?
[MCU_SFR_P3].1-3 ;fixed (all bits set)
[MCU_SFR_P3].4-7 ;unused
;---
[MCU_SFR_P4].0-1 ;? extra info alike system model?
[MCU_SFR_P4].2 ;power led color (0=blue, 1=red)
[MCU_SFR_P4].3 ;... maybe charger led? (or ENABLE charging?) (when charger connected, and temperature good)
[MCU_SFR_P4].4-7 ;unused
;---
[MCU_SFR_P5].0 ;? related to POW[xxh]
[MCU_SFR_P5].1 ;charger busy
[MCU_SFR_P5].2 ;unused
[MCU_SFR_P5].3 ;fixed (set)
[MCU_SFR_P5].4-7 ;unused
;---
[MCU_SFR_P6].0-1 ;cleared on init (maybe i2c_bus0 dta/clk?)
[MCU_SFR_P6].2-7 ;unused
;---
[MCU_SFR_P7].0 ;charger_plugged (R)
[MCU_SFR_P7].1 ;hinge/magnet (R)
[MCU_SFR_P7].2 ;request TSC[10h] (R)
[MCU_SFR_P7].3 ...pwr.button? (R)
[MCU_SFR_P7].4 ;..wifi.button? (R/W?)
[MCU_SFR_P7].5 ;camera led (0=off, 1=on)
[MCU_SFR_P7].6 ;... irq.signal.out (and irq.ack.in?)
[MCU_SFR_P7].7 ;... irq-like state-change short strobe?
;---
[MCU_SFR_P8].0-7 ;unused
[MCU_SFR_P9].0-7 ;unused
[MCU_SFR_P10].0-7 ;unused
[MCU_SFR_P11].0-7 ;unused
;---
[MCU_SFR_P12].0 ;? (R)
[MCU_SFR_P12].1-2 ;System Model (0,1,2,3 = Model 0,4,2,3)
[MCU_SFR_P12].3-7 ;unused
;---
[MCU_SFR_P13].0-7 ;unused
;---
[MCU_SFR_P14].0-1 ;? (both bits set, or both cleared)
[MCU_SFR_P14].2-7 ;unused
;---
[MCU_SFR_P15].0-7 ;unused
;---
;Port X...
[MCU_SFR_?F0510].0-1 ;maybe i2c_bus1 dta/clk? ;alike "Port data 6" for other I2C bus
[MCU_SFR_?F0510].2 ;video "push" on (except, unused on original old 3ds)
[MCU_SFR_?F0510].3 ;fixed (cleared)
[MCU_SFR_?F0510].4 ;alternate home button ???
[MCU_SFR_?F0510].5 ;pedometer related ?
[MCU_SFR_?F0510].6-7 ;unused
;---
ADC(6) ;3d_slider (raw NNh)
ADC(7) ;volume_slider (raw NNh, or reverse 0FFh-NNh)
ADC(8) ;battery pcb temperature [mcu_info_06h], and xlated to [mcu_reg_0Ah_battery_temp_celsius]
ADC(9) ;xlated to 0..7 then stored in [mcu_info_02h]
;---
[MCU_SFR_IICA0] ;I2C bus data for DSi/BPTWL
[MCU_SFR_IICA1] ;I2C bus data for 3DS/MCU
[MCU_SFR_SDR02] ;I2C bus data for slave devices (accel, fuel, tsc, powerman)
I have meanwhile got the New3DS-XL console power
without battery (and without charger), by injecting the supply directly to BT+/- pins.
For BT+, I've passed 5VDC through two 1N4004 diodes to lower the voltage a bit... though that is getting a bit too low: The power/notify LEDs are blinking red, and the console occassionally goes off
after some seconds; until it has warmed up when touching the backlight cable, and the two diodes are getting quite hot (maybe the console tries to draw more current to compensate too low voltage?). Not tested yet, but it does probably work better with only 1 diode (or perhaps without any diodes).
Battery middle pin... the battery does have it GNDed, but the console does also work fine if it is left floating, I've also tried to wire via 10Kohm and 2Mohm potentiometers to GND with different settings, but that didn't seem to have any effect either.
The middle pin signal is forwarded from battery board to a test point on mainboard (near the battery pcb connector), but I don't know where it goes from there (my best guess would be to MCU chip).
The MCU does read something related to battery/fuel/charger from the ADC(9) input (upon initial power-up and wake-up), that ADC value is translated to a "battery type" number in range 0..6 (or 7=invalid), and can be then read via MCU[7Fh:02h]... which seems to be always 00h (even with floating middle pin or with potentiometers). Hmmmm, I am still thinking that the middle pin "should" go to that ADC(9) input, but maybe it doesn't work because they didn't install a pull-up resistor... or maybe I am just wrong there.
Whatever ADC(9) is good for... the two known things are that it affects MCU[7Fh:02h]=0..7, and the fuel gauge calibration is changed if MCU[7Fh:02h]>=4. The fuel gauge MAX17048 datasheet recommends to change the calibration based on battery chemistry and temperature.
Battery temperature is measured via ADC(8) input, the raw ADC value can be read via MCU[7Fh:06h], and the value converted to degrees Celsius can be read from MCU[0Ah] (the value is about 5-6'C degrees too high, ie. even the "cold" state is higher than room temperature). The MCU firmware uses the temperature to calibrate the fuel gauge's RCOMP value, and apparently to disable battery-charging when the temperature is too cold, or to hot.
The temperature sensor is somewhere in the console (not in the battery; it's working even with battery removed), presumably somewhere above the battery... there are a bunch of "resistors/capacitors" on the battery PCB, one of them is probably actually a thermistor.
Battery discharging while powered off... that does still happen to me. When removing the battery it does drop to 93% after some days (that might be more or less okay?). When keeping the battery inserted it drops to 0% after about 10 hours (although it shouldn't do much more than powering the real-clock when switched off).
I am still unsure if that is a hardware issue, or if I am missing something in my power-down function... that is, I am setting MCU[20h]=01h, followed by entering an endless loop.
Fastboot seems to execute a WFI opcode (wait for interrupt) instead of the endless loop, but I don't know if that is really needed (and with which/any IRQs enabled, on which/all CPU cores)?
Well, and I didn't disable backlights before writing MCU[20h]=01h, but they seem to go off anyways.
Apart from the RTC, some of my test code might have the accelerometer kept powered on, but even if so, that shouldn't drain the battery too much.
And lastly, as I am booting via wifi, maybe the wifi hardware is kept powered-on after MCU[20h]=01h?