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

[abyrvalg]

The shutdown could be due to some watchdog not being fed. You can try adding halt and mdb right to your .cfg script to run mdb ASAP after halt to see if it dumps anything at all. Or try reset halt instead of normal halt to stop the CPU right after reset. You’ll need the RESET line connected for that (and, perhaps, some additional configuration or the reset method).

[oh2ftu]

My guess is that halting the CPU shuts down some GPIO (might be from the AD6528 or the proprietary analog baseband cpu) that controls power circuitry.

Looking at the GX15 schematic the analog baseband cpu (AD6537B in the GX15) has input for powonkey AND it does the power conversion. Blimey.
This device has a proprietary thing so ... that's that.

The flash seems to have both 1.8V and 3V. so I guess I will have to inject both 1,8V and 3V, as 3V is done from battery.
It's quite hard to find the "power enable" spot without a schematic.

[abyrvalg]

No, halting freezes GPIO pins. Typical source of such problems is either an internal watchdog expecting periodic “feed”, an external watchdog expecting some pin toggling (and we freeze it) or other cores not expecting the halt.
Have you tried reset halt?

[oh2ftu]

No, halting freezes GPIO pins. Typical source of such problems is either an internal watchdog expecting periodic “feed”, an external watchdog expecting some pin toggling (and we freeze it) or other cores not expecting the halt.
Have you tried reset halt?

Hi,
I would venture a guess that the analog BB shuts down power when it loses connection to ad6528 (digital baseband cpu) - may it be a watchdog or what.

I decided to 3dprint a JIG that would allow easy access to the 1.8V line. Then I'd still need some hardware to get that 1.8V working.
Too bad there's no information whatsoever available on the analog BB cpu. It's proprietary.

Reset halt:

Code: [Select]

> reset halt
TAP UNKNOWN.unknown0 does not have valid IDCODE (idcode=0x4f44396)
JTAG tap: ad6528.cpu tap/device found: 0x027a21cb (mfg: 0x0e5 (Gadzoox Networks), part: 0x27a2, ver: 0x0)
ad6528.cpu: how to reset?


[abyrvalg]

You need to configure the reset method before issuing a reset command (either in the cfg file or manually). Use reset_config srst_only or if you have both the system reset signal and the jtag reset (nTRST) connected, use reset_config trst_and_srst to use both of them. With this command present OpenOCD should know how to reset the chip.

[oh2ftu]

Sorry, I've been busy with both work and life.
I managed to find where the cpu 1.8V testpoint is, so I designed a new adapter with provisions for a 1.8V regulator. Furthermore i ordered the parts needed. Still waiting for the boards though.
In the mean time I've been trying to get a grasp of the power delovery on the board.
I still don't know what turns on the smps's (5V and 3V).
I located the CGP-marked sot-23-5(?) That outputs 1.8V and the enable comes from ... drumroll... the 3V rail. Direct. And the debug-connection has a 3V input.
Haven't tested it, but will do shortly. Good to note is that the flash reset and write protect (RPf anf WPf) are both connected to the same output on a AND-gate, which in turn has both inputs connected to the debug conn AND analog baseband cpu.
Will be busy next week too so I decided to make an update.

[oh2ftu]

Finally.
I had some time to look at the board, and test.
Injecting 3V will keep the CPU going, no battery needed to be connected.

Code: [Select]

> halt
target halted in Thumb state due to debug-request, current mode: System
cpsr: 0x200000ff pc: 0x025321d6
> arm reg
System and User mode registers
      r0: 00000007       r1: 00040000       r2: 0000001e       r3: 0000000c
      r4: ffffb575       r5: 802000a0       r6: ffffffc0       r7: 082c4790
      r8: bbbbbbbb       r9: bbbbbbbb      r10: bbbbbbbb      r11: bbbbbbbb
     r12: 00000000   sp_usr: 0856c4e0   lr_usr: 025321cb       pc: 025321d6
    cpsr: 200000ff

FIQ mode shadow registers
  r8_fiq: fffffffe   r9_fiq: bfefffff  r10_fiq: ffbf6fdf  r11_fiq: dfff7f3b
 r12_fiq: ffbf3dbe   sp_fiq: 4005bd48   lr_fiq: 40046c7c spsr_fiq: 4000003f

Supervisor mode shadow registers
  sp_svc: 40046100   lr_svc: 024eab38 spsr_svc: 8000003f

Abort mode shadow registers
  sp_abt: bfdf7fff   lr_abt: ffffff7f spsr_abt: f00000ff

IRQ mode shadow registers
  sp_irq: ffdfffff   lr_irq: 3fff7fff spsr_irq: f00000ff

Undefined instruction mode shadow registers
  sp_und: ffbf3f7f   lr_und: ffbff77f spsr_und: f00000ff

> mdb 0 0x100
0x00000000: dc f0 9f e5 1e 00 00 ea 09 00 00 ea 1f 00 00 ea 21 00 00 ea 00 00 a0 e1 22 00 00 ea 35 00 00 ea
0x00000020: c0 f0 9f e5 00 00 a0 e1 00 00 9f e5 0e f0 b0 e1 1f 00 00 00 d3 f0 21 e3 10 00 0f e5 00 00 4f e1
0x00000040: 20 00 10 e3 b2 00 5e 11 b4 00 5e 01 ff 00 00 e2 ab 00 50 e3 56 00 50 13 f2 ff ff 0a 04 00 50 e3
0x00000060: 00 f1 9f 97 04 00 00 ea 3c bf 4e 02 b4 bf 4e 02 9c bf 4e 02 7c 00 00 00 4c bf 4e 02 08 c0 a0 e3
0x00000080: 0c 00 00 ea db f0 21 e3 04 c0 a0 e3 09 00 00 ea d7 f0 21 e3 0c c0 a0 e3 06 00 00 ea d7 f0 21 e3
0x000000a0: 10 c0 a0 e3 03 00 00 ea d2 f0 21 e3 14 c0 a0 e3 00 00 00 ea 18 c0 a0 e3 2c d0 9f e5 ff 7f 4d e9
0x000000c0: 00 00 a0 e1 0c 00 a0 e1 08 10 1d e5 3c d0 4d e2 0e 20 a0 e1 14 30 9f e5 24 30 93 e5 10 40 9f e5
0x000000e0: 14 ff 2f e1 00 00 18 02 84 c1 4e 02 00 04 00 00 e4 2d 05 40 c1 af 21 02 e4 00 5e e3 57 00 00 9a

And the other region

Code: [Select]

> mdb 0x02000000 0x100
0x02000000: 1c f0 9f e5 05 00 00 ea 04 00 00 ea 03 00 00 ea 02 00 00 ea 00 00 a0 e1 00 00 00 ea ff ff ff ea
0x02000020: fe ff ff ea 00 00 02 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x02000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x02000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x02000080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x020000a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x020000c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x020000e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Finally, some data!
The flash is 256Mbit, so 32MB. Size in hex 0x02000000?
Where would this area be?

[oh2ftu]

so.
Five years ago I dumped a bare flash with an arduino. I had varying results - ie not consistent. Bits were flipped etc.

Yesterday I dumped dump_image filename.bin 0x02000000 0x02000000 and got similar results. Granted from a different device, but a few looks here and there confirmed that the flash seem to start at 0x02000000.

Now, could I use openocd flash-tools with CFI?

Code: [Select]

flash bank name driver base size chip_width bus_width target

The example from the docs:

Code: [Select]

To configure two adjacent banks of 16 MBytes each, both sixteen bits (two bytes) wide on a sixteen bit bus:

flash bank $_FLASHNAME cfi 0x00000000 0x01000000 2 2 $_TARGETNAME
flash bank $_FLASHNAME cfi 0x01000000 0x01000000 2 2 $_TARGETNAME
To configure one bank of 32 MBytes built from two sixteen bit (two byte) wide parts wired in parallel to create a thirty-two bit (four byte) bus with doubled throughput:

flash bank $_FLASHNAME cfi 0x00000000 0x02000000 2 4 $_TARGETNAME

Now I don't know about the banks? the flash is a 16Mx16 piece (multiple bank, bultilevel burst).

Should this be configured as 16 banks?

[oh2ftu]

Long story short; I got CFI working. But it is VERY slow.
Dump_image was getting about 4KiB/s, while flash read_bank gives a tenth of that.
The flash is recognized;

Code: [Select]

> flash info 1
#1 : cfi at 0x02000000, size 0x02000000, buswidth 2, chipwidth 2
..... addresses ....
CFI flash: mfr: 0xf01c, id:0xe59f
qry: 'QRY', pri_id: 0x0001, pri_addr: 0x010a, alt_id: 0x0000, alt_addr: 0x0000
Vcc min: 1.7, Vcc max: 2.0, Vpp min: 8.5, Vpp max: 9.5
typ. word write timeout: 256 us, typ. buf write timeout: 512 us, typ. block erase timeout: 1024 ms, typ. chip erase timeout: 1 ms
max. word write timeout: 512 us, max. buf write timeout: 1024 us, max. block erase timeout: 4096 ms, max. chip erase timeout: 1 ms
size: 0x2000000, interface desc: 1, max buffer write size: 0x40

intel primary algorithm extend information:
pri: 'PRI', version: 1.3
feature_support: 0x3e6, suspend_cmd_support: 0x1, blk_status_reg_mask: 0x1
Vcc opt: 1.8, Vpp opt: 9.0
protection_fields: 2, prot_reg_addr: 0x80, factory pre-programmed: 8, user programmable: 8

Any idea how to speed things up a bit?

[abyrvalg]

Congratulations! That dump looks like valid ARM code.

Speeding the things up - you don’t need to use flash commands for reading, they read the same data dump_image does, just in some less efficient manner. The only thing requiring flash is writing. Try raising TCK frequency instead, i.e. adapter speed 10000 should set it to 10MHz.

Another totally different possible approach is to dump the BootROM (looks like it is right at 0, the size needs to be guessed by trying), reverse engineer the serial boot protocol (I can help with that) and use it instead of JTAG.

[oh2ftu]

Hi,
dump_image went to about 22KiB/s with 1MHz speed, going over that didn't speed things up.
I will take a few dumps and have a look-see.
The boot-rom is bottom type if that's of any concern - and isn't dumping the whole shebang enough? lot's of FF though.
About  8MB of real code, rest is empty.

[abyrvalg]

The memory at 0x0 is not a BootROM indeed. Looks like it is some RAM holding vector table and exception handlers and it’s content originates from flash (init code inside flash have copied this code from flash to RAM to catch exceptions/interrupts), so nothing valuable there. All those vectors lead to 0x02xxxxxxxx flash.