Making your own BSDL

[oh2ftu]

So,
I've been trying to dump a M36L0T8060B3 flash lately with varying success.
I desoldered it, and slapped it onto a proto advantage breakout-board. Then connected to an Arduino Due.
Dumping it at 57600kbps takes a while, and I must take 2-3 passes to make sure I've got at least to identical.
This is very inconvenient. I would like to dump it in-place, without the need to solder/desolder after small changes to it. Also, I cannot write anything to it.

The CPU is AD6528DABCZ. The only thing I've found related to AD6528, are a one-sheet datasheet with no actual info, a pinout from a Sharp GX15 service manual and.. that's about it.
The datasheet is nowhere to be found (I would like to have a memory map and gpio registers, please), or even a BSDL.
With a BSDL, I could use JTAG to access the flash.

Now then, as the flash is removed, could I create my own bsdl?
I do know where it's connected, I've traced the board.

But JTAG is completely new to me, I don't have a programmer even yet! (I'm getting a segger Jlink).

Is it even possible to blindly set registers on the CPU and measure the BGA-pads? and thus creating a BSDL containing the bare minimum definitions for accessing a flash?

[abyrvalg]

You don’t need BSDL and direct pin manipulations to access memory on this CPU. Use CPU debug features instead (halt the core and read memory via CPU bus). A more common chip from this family was AD6522 - should be more info available (although it was more than 15 years ago). These chips also had a service mode in BootROM allowing memory reading/programming. You send some "magic" bytes to AD652x UART at power on and ROM enters service loader instead of normal start.
Edit: one of the most popular devices based on AD6522 was Panasonic GD55. Search for "panasonic gd55 flasher" still finds some tool archives, i.e. this: https://service-gsm.net/Panasonic/GD55

[oh2ftu]

I'm suspecting that the bootloader has been replaced, as I didn't have any luck with a Volcano box.
About the JTAG, I'm very new to it. JtagPROBE identified the cpu and the other, non-documented proprietary cpu.
Trying JtagFlasher, it requested a BSDL file.

What software should be used to access cpu debug features?

At the moment I'm trying out a GX15 flasher that I also found at the same site

[abyrvalg]

Yes, this CPU has two cores - ARM7TDMI and ADSP21xx. Use some JTAG tool with ARM support (i.e. OpenOCD), connect to ARM7TDMI, halt it, then read memory space. You'll need to know memory address range, look at PC/LR registers after core halt to get an idea where is the code memory.

Boundary scan-based JTAG tools (like that tool asking for BSDL file) will NOT work in this (core debug) mode at all. There can be some CPU pin (something like "nBSCAN") to switch JTAG to boundary scan mode, but working in core debug mode is much easier (no need device-specific BSDL etc).

The bootloader of this chip can't be "replaced". It's in mask ROM, so it works even with an empty flash (and is used for empty board programming for example). Perhaps the protocol has changed a bit between AD6522 and AD6528. With JTAG you can even dump the mask ROM and study it to known the protocol.

Edit: noticed you are getting a J-Link. It will work for sure. I'm not familiar with it's newer GUI tools, but for the command line tool (jlink.exe) the command sequence will be something like this:
connect - connect to the core, select ARM7TDMI with default settings when it asks
h - halt the core
regs - show core registers
mem 0 100 - display memory at 0-0x100
savebin dump.bin 0 100 - save memory 0-0x100 to dump.bin

[oh2ftu]

I tried this.
the jlink commander does only give ARM7 as an option.
Using that, it will not connect, here's the printout:

Code: [Select]

Connecting to target via JTAG
TotalIRLen = 8, IRPrint = 0x0015
JTAG chain detection found 2 devices:
 #0 Id: 0x10A62005, IRLen: ?, Unknown device
 #1 Id: 0x027A21CB, IRLen: ?, Unknown device
TotalIRLen = 8, IRPrint = 0x0015
JTAG chain detection found 2 devices:
 #0 Id: 0x10A62005, IRLen: ?, Unknown device
 #1 Id: 0x027A21CB, IRLen: ?, Unknown device

****** Error: CPU-TAP not found in JTAG chain

TotalIRLen = 8, IRPrint = 0x0015
JTAG chain detection found 2 devices:
 #0 Id: 0x10A62005, IRLen: ?, Unknown device
 #1 Id: 0x027A21CB, IRLen: ?, Unknown device
TotalIRLen = 8, IRPrint = 0x0015
JTAG chain detection found 2 devices:
 #0 Id: 0x10A62005, IRLen: ?, Unknown device
 #1 Id: 0x027A21CB, IRLen: ?, Unknown device

****** Error: CPU-TAP not found in JTAG chain

Cannot connect to target.
this does not have the AD analog baseband, but a proprietary chip in place of it.
#0 is the proprietary
#1 is the AD6528DABCZ

[abyrvalg]

I’m sure I had JTAG ARM7 debug working on GD55. Try targeting JLink to the second device by specifying IRPre=4/DRPre=1 values (either with cmd “config 4,1” or a param to jlink.exe “-jtagconf 4,1”.
Unfortunately I’m away from my old archives due to COVID lockdown

[oh2ftu]

That didn't work either. Seems like I'm missing something very easy.
JTAGEN is high, and unless it's high nothing is found on the bus.
This is not a gsm-phone, so that might affect it. Also, a Volcano Box (nor any phone software) was not able to identify this on the serial line.

Interesting indeed.

[abyrvalg]

Regarding the serial boot: there are two boot mode control pins (look for "Boot Control 0/1" in GX15 schematic), maybe you need to set them to the correct state (GX15 PDF says BC0=1, BC1=0 is UART boot). An older AD6522 I'm talking about had no USB at all, so there were just two boot modes, but your AD6528 has 4.
Trying to activate the USB boot mode could be interesting too if you manage to find an appropriate software for it. I see an original SPST here: http://evil-hackers.com/Sharp/, but it is protected with WIBU dongle (but at least there is an USB driver for device with PID=6528 - nice). Looking at that SPST suggests that all models from GX15 to GX30 were based on the same CPU, so some other tool (i.e. this http://evil-hackers.com/Sharp/Flasher/PLATIJET_flashers.rar) could work.

[oh2ftu]

Both GPIO_55 and GPIO_56 are connected directly to ground.
USB seems very un-utilized on this device

[abyrvalg]

So that can be the reason why UART tools don't work. Is it possible to disconnect GPIO56 from GND?

JTAG: I've seen some SoCs showing up in "system top level" mode by default, then switching to core debug mode with some dedicated command written to IR. You could try brute forcing IR commands with jlink's "wjc" cmd (followed by "i" identify cmd to observe possible changes in IDCODEs). Like this:
wjc 0
i
wjc 1
i
...
These things can be more complicated (like specific IR cmd selects some "mode control" register, then writing a correct value into DR selects debug mode), would be much harder to try all combinations in that case.

Another possible direction is to study your existing dump (you've dumped some part of flash with Arduino, right?) to find some bootloader there and try talking it's protocol.

[oh2ftu]

Time to necropost on this as I looked into it once again.

The GPIO56 cannot be disconnected from gnd, they're directly connected to a grounded pad.

I'm still having trouble accessing the JTAG at all. I've tried urjtag, openocd and jlink with varying success:

[GromBeestje]

Looks like the output OpenOCD would give when only jlink.cfg is included and not target config file.
You could try something like

Code: [Select]

set _CHIPNAME ad6528
set _CPUTAPID 0x1684a555
set _ENDIAN little
jtag newtap $_CHIPNAME cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id $_CPUTAPID
set _TARGETNAME $_CHIPNAME.cpu
target create $_TARGETNAME arm7tdmi -endian $_ENDIAN -chain-position $_TARGETNAME

This is just something I've copy-pasted together from some existing config files for arm7tdmi based chips.

It looks like there is no config file for this chip you have. This means, with OpenOCD you won't be able to write to flash, but reading should work fine.

[oh2ftu]

Looks like the output OpenOCD would give when only jlink.cfg is included and not target config file.
You could try something like

Code: [Select]

set _CHIPNAME ad6528
set _CPUTAPID 0x1684a555
set _ENDIAN little
jtag newtap $_CHIPNAME cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id $_CPUTAPID
set _TARGETNAME $_CHIPNAME.cpu
target create $_TARGETNAME arm7tdmi -endian $_ENDIAN -chain-position $_TARGETNAME

This is just something I've copy-pasted together from some existing config files for arm7tdmi based chips.

It looks like there is no config file for this chip you have. This means, with OpenOCD you won't be able to write to flash, but reading should work fine.

Thanks, reading is what I'm looking for first and foremost.

This is where I'm at now;

Code: [Select]

# openocd -f interface/jlink.cfg -f cpu/arm/arm7tdmi.tcl -f target/ad6528.cfg -c "transport select jtag"
Open On-Chip Debugger 0.12.0
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
32
Info : auto-selecting first available session transport "jtag". To override use 'transport select <transport>'.
ad6528.cpu
Warn : Transport "jtag" was already selected
jtag
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Warn : An adapter speed is not selected in the init scripts. OpenOCD will try to run the adapter at the low speed (100 kHz)
Warn : To remove this warnings and achieve reasonable communication speed with the target, set "adapter speed" or "jtag_rclk" in the init scripts.
Info : J-Link V11 compiled Dec  4 2024 17:53:35
Info : Hardware version: 11.00
Info : VTarget = 0.000 V
Info : clock speed 100 kHz
Error: JTAG scan chain interrogation failed: all ones
Error: Check JTAG interface, timings, target power, etc.
Error: Trying to use configured scan chain anyway...
Error: ad6528.cpu: IR capture error; saw 0x0f not 0x01
Warn : Bypassing JTAG setup events due to errors
Info : Embedded ICE version 15
Error: unknown EmbeddedICE version (comms ctrl: 0xffffffff)
Info : ad6528.cpu: hardware has 2 breakpoint/watchpoint units
Info : starting gdb server for ad6528.cpu on 3333
Info : Listening on port 3333 for gdb connections
Warn : ThumbEE -- incomplete support
target halted in ThumbEE state due to watchpoint, current mode: System
cpsr: 0xffffffff pc: 0xfffffff9


[GromBeestje]

Looks like you've got a wiring issue

Code: [Select]

Info : VTarget = 0.000 V
The VTarget needs to be connected since the JLink has a built-in level shifter.

[oh2ftu]

What a moronic mistake!

Code: [Select]

$ openocd -f interface/jlink.cfg -f cpu/arm/arm7tdmi.tcl -f target/ad6528.cfg
Open On-Chip Debugger 0.12.0
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
32
Info : auto-selecting first available session transport "jtag". To override use 'transport select <transport>'.
ad6528.cpu
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Warn : An adapter speed is not selected in the init scripts. OpenOCD will try to run the adapter at the low speed (100 kHz)
Warn : To remove this warnings and achieve reasonable communication speed with the target, set "adapter speed" or "jtag_rclk" in the init scripts.
Info : J-Link V11 compiled Dec  4 2024 17:53:35
Info : Hardware version: 11.00
Info : VTarget = 3.166 V
Info : clock speed 100 kHz
Info : JTAG tap: ad6528.cpu tap/device found: 0x1684a555 (mfg: 0x2aa (Atrua Technologies Inc), part: 0x684a, ver: 0x1)
Info : JTAG tap: auto0.tap tap/device found: 0x027a21cb (mfg: 0x0e5 (Gadzoox Networks), part: 0x27a2, ver: 0x0)
Error: ad6528.cpu: IR capture error; saw 0x05 not 0x01
Warn : Bypassing JTAG setup events due to errors
Info : Embedded ICE version 0
Error: unknown EmbeddedICE version (comms ctrl: 0x06228003)
Info : ad6528.cpu: hardware has 2 breakpoint/watchpoint units
Info : starting gdb server for ad6528.cpu on 3333
Info : Listening on port 3333 for gdb connections
Error: invalid mode value encountered 4
Error: cpsr contains invalid mode value - communication failure
Polling target ad6528.cpu failed, trying to reexamine
Info : Embedded ICE version 9
Error: unknown EmbeddedICE version (comms ctrl: 0x96628003)
Info : ad6528.cpu: hardware has 2 breakpoint/watchpoint units
target halted in ARM state due to watchpoint, current mode: User
cpsr: 0x800280d0 pc: 0x800280ae
Warn : ThumbEE -- incomplete support
target halted in ThumbEE state due to watchpoint, current mode: System
cpsr: 0xffffffff pc: 0xfffffff9

Actually running this will shutdown device

[abyrvalg]

Looks like this TAP you are talking to is not an ARM core. Try the other TAP (change _CPUTAPID to the other one).

[oh2ftu]

Changing the _tapid results in the following;

Code: [Select]

# openocd -f interface/jlink.cfg -f cpu/arm/arm7tdmi.tcl -f target/ad6528.cfg
Open On-Chip Debugger 0.12.0
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
32
Info : auto-selecting first available session transport "jtag". To override use 'transport select <transport>'.
ad6528.cpu
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Warn : An adapter speed is not selected in the init scripts. OpenOCD will try to run the adapter at the low speed (100 kHz)
Warn : To remove this warnings and achieve reasonable communication speed with the target, set "adapter speed" or "jtag_rclk" in the init scripts.
Info : J-Link V11 compiled Dec  4 2024 17:53:35
Info : Hardware version: 11.00
Info : VTarget = 3.166 V
Info : clock speed 100 kHz
Info : JTAG tap: ad6528.cpu tap/device found: 0x1684a555 (mfg: 0x2aa (Atrua Technologies Inc), part: 0x684a, ver: 0x1)
Warn : JTAG tap: ad6528.cpu       UNEXPECTED: 0x1684a555 (mfg: 0x2aa (Atrua Technologies Inc), part: 0x684a, ver: 0x1)
Error: JTAG tap: ad6528.cpu  expected 1 of 1: 0x027a21cb (mfg: 0x0e5 (Gadzoox Networks), part: 0x27a2, ver: 0x0)
Info : JTAG tap: auto0.tap tap/device found: 0x027a21cb (mfg: 0x0e5 (Gadzoox Networks), part: 0x27a2, ver: 0x0)
Error: Trying to use configured scan chain anyway...
Error: ad6528.cpu: IR capture error; saw 0x05 not 0x01
Warn : Bypassing JTAG setup events due to errors
Info : Embedded ICE version 1
Info : ad6528.cpu: hardware has 2 breakpoint/watchpoint units
Info : starting gdb server for ad6528.cpu on 3333
Info : Listening on port 3333 for gdb connections
target halted in ARM state due to watchpoint, current mode: IRQ
cpsr: 0x800281d2 pc: 0x800281ae



[abyrvalg]

Ahh, my bad, you need to declare the other TAP anyway. Must be something like this:

Code: [Select]

set _CHIPNAME ad6528
set _UNKTAPID 0x1684a555
set _CPUTAPID 0x027a21cb
set _ENDIAN little
jtag newtap UNKNOWN unknown0 -irlen 4 -expected-id $_UNKTAPID
jtag newtap $_CHIPNAME cpu -irlen 4 -expected-id $_CPUTAPID
set _TARGETNAME $_CHIPNAME.cpu
target create $_TARGETNAME arm7tdmi -endian $_ENDIAN -chain-position $_TARGETNAME


[oh2ftu]

ok, so I'm this far:

Code: [Select]

# openocd -f interface/jlink.cfg -f cpu/arm/arm7tdmi.tcl -f target/ad6528.cfg
Open On-Chip Debugger 0.12.0
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
32
Info : auto-selecting first available session transport "jtag". To override use 'transport select <transport>'.
ad6528.cpu
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Warn : An adapter speed is not selected in the init scripts. OpenOCD will try to run the adapter at the low speed (100 kHz)
Warn : To remove this warnings and achieve reasonable communication speed with the target, set "adapter speed" or "jtag_rclk" in the init scripts.
Info : J-Link V11 compiled Dec  4 2024 17:53:35
Info : Hardware version: 11.00
Info : VTarget = 3.172 V
Info : clock speed 100 kHz
Info : JTAG tap: UNKNOWN.unknown0 tap/device found: 0x1684a555 (mfg: 0x2aa (Atrua Technologies Inc), part: 0x684a, ver: 0x1)
Info : JTAG tap: ad6528.cpu tap/device found: 0x027a21cb (mfg: 0x0e5 (Gadzoox Networks), part: 0x27a2, ver: 0x0)
Info : Embedded ICE version 1
Info : ad6528.cpu: hardware has 2 breakpoint/watchpoint units
Info : starting gdb server for ad6528.cpu on 3333
Info : Listening on port 3333 for gdb connections

And I'm able to open a telnet session. Now the interesting part, defining the flash?
It should be CFI-compatible - whatever that means?

[abyrvalg]

You don’t need to define the flash for reading, just need to know start address/size. Try halting the CPU and dumping registers to get an idea of where is the code being executed. Commands:
halt
reg

And to do the actual dumping use mdb address size and dump_image filename address size.

[oh2ftu]

Hmm, these are the registers shown;

Code: [Select]

> halt
target halted in Thumb state due to debug-request, current mode: System
cpsr: 0x8000003f pc: 0x0225c334
ThumbEE -- incomplete support
target halted in ThumbEE state due to debug-request, current mode: System
cpsr: 0xffffffff pc: 0xfffffff9

> reg
===== ARM registers
(0) r0 (/32): 0xffffffff (dirty)
(1) r1 (/32): 0xffffffff
(2) r2 (/32): 0xffffffff
(3) r3 (/32): 0xffffffff
(4) r4 (/32): 0xffffffff
(5) r5 (/32): 0xffffffff
(6) r6 (/32): 0xffffffff
(7) r7 (/32): 0xffffffff
(8) r8 (/32): 0xffffffff
(9) r9 (/32): 0xffffffff
(10) r10 (/32): 0xffffffff
(11) r11 (/32): 0xffffffff
(12) r12 (/32): 0xffffffff
(13) sp_usr (/32): 0xffffffff
(14) lr_usr (/32): 0xffffffff
(15) pc (/32): 0xfffffff9 (dirty)
(16) r8_fiq (/32)
(17) r9_fiq (/32)
(18) r10_fiq (/32)
(19) r11_fiq (/32)
(20) r12_fiq (/32)
(21) sp_fiq (/32)
(22) lr_fiq (/32)
(23) sp_irq (/32)
(24) lr_irq (/32)
(25) sp_svc (/32)
(26) lr_svc (/32)
(27) sp_abt (/32)
(28) lr_abt (/32)
(29) sp_und (/32)
(30) lr_und (/32)
(31) cpsr (/32): 0xffffffff
(32) spsr_fiq (/32)
(33) spsr_irq (/32)
(34) spsr_svc (/32)
(35) spsr_abt (/32)
(36) spsr_und (/32)
(37) sp (/32)
(38) lr (/32)
===== EmbeddedICE registers

>

not much to help id the address where the external flash is connected?

[abyrvalg]

Looks like something crashes during halt. First CPSR/PC values looks legit, then the output gets stuck at 1. Try restarting the device and connecting+halting+reg several times to see if those CPSR/PC values are consistent or if you’ll be lucky to get valid regs. This is a heterogenous multicore system and we are halting one core (ARM) without informing the other one (DSP), there can be “good” and “bad” moments to do that. BTW, do you have the RESET signal connected? Could be worth connecting it and trying reset halt command to halt the core as early as possible (perhaps you’ll catch ARM BootROM execution with DSP not started at all).

Getting a proper halt (even 1 in 10 by luck) is essential for reading. On ARM7 you can’t read via JTAG with the core running.

[oh2ftu]

So I tested with another device of older generation.
Also soldered a wire for reset if needed.
On the face of it, the parts should be the same, but either way:

Code: [Select]

ad6528.cpu
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Warn : An adapter speed is not selected in the init scripts. OpenOCD will try to run the adapter at the low speed (100 kHz)
Warn : To remove this warnings and achieve reasonable communication speed with the target, set "adapter speed" or "jtag_rclk" in the init scripts.
Info : J-Link V11 compiled Dec  4 2024 17:53:35
Info : Hardware version: 11.00
Info : VTarget = 3.141 V
Info : clock speed 100 kHz
Info : JTAG tap: UNKNOWN.unknown0 tap/device found: 0x10a62005 (mfg: 0x002 (AMI), part: 0x0a62, ver: 0x1)
Warn : JTAG tap: UNKNOWN.unknown0       UNEXPECTED: 0x10a62005 (mfg: 0x002 (AMI), part: 0x0a62, ver: 0x1)
Error: JTAG tap: UNKNOWN.unknown0  expected 1 of 1: 0x1684a555 (mfg: 0x2aa (Atrua Technologies Inc), part: 0x684a, ver: 0x1)
Info : JTAG tap: ad6528.cpu tap/device found: 0x027a21cb (mfg: 0x0e5 (Gadzoox Networks), part: 0x27a2, ver: 0x0)
Error: Trying to use configured scan chain anyway...
Warn : Bypassing JTAG setup events due to errors
Info : Embedded ICE version 1
Info : ad6528.cpu: hardware has 2 breakpoint/watchpoint units
Info : starting gdb server for ad6528.cpu on 3333
Info : Listening on port 3333 for gdb connections
Info : accepting 'telnet' connection on tcp/4444

It finds some new devices.
but! when running halt, I get this:

Code: [Select]

> halt
target halted in ARM state due to debug-request, current mode: FIQ
cpsr: 0x000000d1 pc: 0x0000001c
> reg
===== ARM registers
(0) r0 (/32): 0x0000f9d5 (dirty)
(1) r1 (/32): 0x00000040
(2) r2 (/32): 0xc0000000
(3) r3 (/32): 0x02306ff9
(4) r4 (/32): 0x080ce1ca
(5) r5 (/32): 0x80040600
(6) r6 (/32): 0x080028e4
(7) r7 (/32): 0x00000004
(8) r8 (/32)
(9) r9 (/32)
(10) r10 (/32)
(11) r11 (/32)
(12) r12 (/32)
(13) sp_usr (/32)
(14) lr_usr (/32)
(15) pc (/32): 0x0000001c (dirty)
(16) r8_fiq (/32): 0x800000d3
(17) r9_fiq (/32): 0x00000000
(18) r10_fiq (/32): 0x00000000
(19) r11_fiq (/32): 0x00000000
(20) r12_fiq (/32): 0x00000000
(21) sp_fiq (/32): 0x4005b1f8
(22) lr_fiq (/32): 0x02306ff4
(23) sp_irq (/32)
(24) lr_irq (/32)
(25) sp_svc (/32)
(26) lr_svc (/32)
(27) sp_abt (/32)
(28) lr_abt (/32)
(29) sp_und (/32)
(30) lr_und (/32)
(31) cpsr (/32): 0x000000d1
(32) spsr_fiq (/32): 0x0000003f
(33) spsr_irq (/32)
(34) spsr_svc (/32)
(35) spsr_abt (/32)
(36) spsr_und (/32)
(37) sp (/32)
(38) lr (/32)


[abyrvalg]

This looks legit indeed! Halting have caused a FIQ interrupt for some reason (nothing fatal) and you’ve caught the core right at the FIQ vector (0x0000001C) with LR_FIQ pointing back to the interrupted code at 0x02306ff4 and SPSR_FIQ telling that it was a Thumb code running in System mode - these things are not some random trash. So it looks like the “main” code starts at 0x02000000 and is at least 4MB and also there is some code memory right at 0 holding the vector table. This can be either the same memory as at 0x02000000 aliased to 0 to provide vectors at the correct location or it can be a RAM holding just vectors pointing to some other region or a BootROM with trampolines via RAM pointers.
Try mdb 0 0x100 and mdb 0x02000000 0x100 to try reading a small part of both regions to see what’s there.
Also it looks like there is a RAM starting at 0x40000000 (from SP_FIQ value).

[oh2ftu]

I did some more testing;

Code: [Select]

> halt
target halted in Thumb state due to debug-request, current mode: System
cpsr: 0x8000003f pc: 0x0225be7c
> arm reg
System and User mode registers
      r0: 00007f20       r1: 000186a0       r2: 4004649c       r3: 0225be1d
      r4: 08112c30       r5: 80040600       r6: 00000004       r7: 80040604
      r8: bbbbbbbb       r9: bbbbbbbb      r10: bbbbbbbb      r11: bbbbbbbb
     r12: 4001f8b1   sp_usr: 083ab8e8   lr_usr: 0225be61       pc: 0225be7c
    cpsr: 8000003f

FIQ mode shadow registers
  r8_fiq: ffffffff   r9_fiq: ffffffff  r10_fiq: ffffffff  r11_fiq: ffffffff
 r12_fiq: ffffffff   sp_fiq: ffffffff   lr_fiq: ffffffff spsr_fiq: ffffffff

Supervisor mode shadow registers
  sp_svc: ffffffff   lr_svc: ffffffff spsr_svc: ffffffff

Abort mode shadow registers
  sp_abt: ffffffff   lr_abt: ffffffff spsr_abt: ffffffff

IRQ mode shadow registers
  sp_irq: ffffffff   lr_irq: ffffffff spsr_irq: ffffffff

Undefined instruction mode shadow registers
  sp_und: ffffffff   lr_und: ffffffff spsr_und: ffffffff


mdb at those regions give nothing but ff back.
I would venture a guess that it shuts the device


##############
Ok.
So the device has a distinct test-point pattern under the speaker.
I've id'd JTAG, rx/tx etc from it (and 3V from the power rail).
As soon as I halt the CPU, the power-portion of the device shuts down.
I do not have a schematic of this.
That's why I'm having trouble finding anything useful, as halting it shuts down power.
1,8V is not present on the test points, neither do I know from what the 1,8V is done;
Said 3V on the test points, direct from battery or from the 5V line.
Battery is 7,8V lipo.
The background is, five years ago I destroyed one of these by grinding and scanning each layer of the 10-layer pcb. After that I made a rudimentary kicad-board file and some sort of schematic of the relevant parts.
I seem to have found a testpoint (although located on a very peculiar place) for 1,8V.
This needs to be sorted first I'd say