Making your own BSDL - Page 1
Forum section: electronics / general

author: oh2ftu
author_rank: Regular Contributor
timestamp: April 19, 2020, 08:47:45 am
content: 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?

author: abyrvalg
author_rank: Frequent Contributor
timestamp: May 01, 2020, 01:02:00 am
content: 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

author: oh2ftu
author_rank: Regular Contributor
timestamp: May 01, 2020, 05:36:14 am
content: 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

author: abyrvalg
author_rank: Frequent Contributor
timestamp: May 01, 2020, 11:06:37 am
content: 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 asksh - halt the coreregs - show core registersmem 0 100 - display memory at 0-0x100savebin dump.bin 0 100 - save memory 0-0x100 to dump.bin

author: oh2ftu
author_rank: Regular Contributor
timestamp: May 08, 2020, 12:00:59 pm
content: I tried this.the jlink commander does only give ARM7 as an option.Using that, it will not connect, here's the printout:Code:Connecting to target via JTAGTotalIRLen = 8, IRPrint = 0x0015JTAG chain detection found 2 devices:#0 Id: 0x10A62005, IRLen: ?, Unknown device#1 Id: 0x027A21CB, IRLen: ?, Unknown deviceTotalIRLen = 8, IRPrint = 0x0015JTAG chain detection found 2 devices:#0 Id: 0x10A62005, IRLen: ?, Unknown device#1 Id: 0x027A21CB, IRLen: ?, Unknown device****** Error: CPU-TAP not found in JTAG chainTotalIRLen = 8, IRPrint = 0x0015JTAG chain detection found 2 devices:#0 Id: 0x10A62005, IRLen: ?, Unknown device#1 Id: 0x027A21CB, IRLen: ?, Unknown deviceTotalIRLen = 8, IRPrint = 0x0015JTAG chain detection found 2 devices:#0 Id: 0x10A62005, IRLen: ?, Unknown device#1 Id: 0x027A21CB, IRLen: ?, Unknown device****** Error: CPU-TAP not found in JTAG chainCannot 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

author: abyrvalg
author_rank: Frequent Contributor
timestamp: May 10, 2020, 09:47:35 am
content: 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

author: oh2ftu
author_rank: Regular Contributor
timestamp: May 10, 2020, 11:02:58 am
content: 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.

author: abyrvalg
author_rank: Frequent Contributor
timestamp: May 10, 2020, 04:09:06 pm
content: 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. thishttp://evil-hackers.com/Sharp/Flasher/PLATIJET_flashers.rar) could work.

author: oh2ftu
author_rank: Regular Contributor
timestamp: May 10, 2020, 04:28:46 pm
content: Both GPIO_55 and GPIO_56 are connected directly to ground.USB seems very un-utilized on this device

author: abyrvalg
author_rank: Frequent Contributor
timestamp: May 10, 2020, 05:19:32 pm
content: 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 0iwjc 1i...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.

author: oh2ftu
author_rank: Regular Contributor
timestamp: February 05, 2025, 07:46:32 am
content: 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:

author: GromBeestje
author_rank: Frequent Contributor
timestamp: February 05, 2025, 09:13:38 pm
content: Looks like the output OpenOCD would give when only jlink.cfg is included and not target config file.You could try something likeCode:set _CHIPNAME ad6528set _CPUTAPID 0x1684a555set _ENDIAN littlejtag newtap $_CHIPNAME cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id $_CPUTAPIDset _TARGETNAME $_CHIPNAME.cputarget create $_TARGETNAME arm7tdmi -endian $_ENDIAN -chain-position $_TARGETNAMEThis 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.

author: oh2ftu
author_rank: Regular Contributor
timestamp: February 06, 2025, 07:43:14 pm
content: Quote from: GromBeestje on February 05, 2025, 09:13:38 pmThanks, reading is what I'm looking for first and foremost.This is where I'm at now;Code:# openocd -f interface/jlink.cfg -f cpu/arm/arm7tdmi.tcl -f target/ad6528.cfg -c "transport select jtag"Open On-Chip Debugger 0.12.0Licensed under GNU GPL v2For bug reports, readhttp://openocd.org/doc/doxygen/bugs.html32Info : auto-selecting first available session transport "jtag". To override use 'transport select <transport>'.ad6528.cpuWarn : Transport "jtag" was already selectedjtagInfo : Listening on port 6666 for tcl connectionsInfo : Listening on port 4444 for telnet connectionsWarn : 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:35Info : Hardware version: 11.00Info : VTarget = 0.000 VInfo : clock speed 100 kHzError: JTAG scan chain interrogation failed: all onesError: Check JTAG interface, timings, target power, etc.Error: Trying to use configured scan chain anyway...Error: ad6528.cpu: IR capture error; saw 0x0f not 0x01Warn : Bypassing JTAG setup events due to errorsInfo : Embedded ICE version 15Error: unknown EmbeddedICE version (comms ctrl: 0xffffffff)Info : ad6528.cpu: hardware has 2 breakpoint/watchpoint unitsInfo : starting gdb server for ad6528.cpu on 3333Info : Listening on port 3333 for gdb connectionsWarn : ThumbEE -- incomplete supporttarget halted in ThumbEE state due to watchpoint, current mode: Systemcpsr: 0xffffffff pc: 0xfffffff9

author: GromBeestje
author_rank: Frequent Contributor
timestamp: February 06, 2025, 08:04:12 pm
content: Looks like you've got a wiring issueCode:Info : VTarget = 0.000 VThe VTarget needs to be connected since the JLink has a built-in level shifter.

author: oh2ftu
author_rank: Regular Contributor
timestamp: February 07, 2025, 04:29:35 am
content: What a moronic mistake!Code:$ openocd -f interface/jlink.cfg -f cpu/arm/arm7tdmi.tcl -f target/ad6528.cfgOpen On-Chip Debugger 0.12.0Licensed under GNU GPL v2For bug reports, readhttp://openocd.org/doc/doxygen/bugs.html32Info : auto-selecting first available session transport "jtag". To override use 'transport select <transport>'.ad6528.cpuInfo : Listening on port 6666 for tcl connectionsInfo : Listening on port 4444 for telnet connectionsWarn : 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:35Info : Hardware version: 11.00Info : VTarget = 3.166 VInfo : clock speed 100 kHzInfo : 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 0x01Warn : Bypassing JTAG setup events due to errorsInfo : Embedded ICE version 0Error: unknown EmbeddedICE version (comms ctrl: 0x06228003)Info : ad6528.cpu: hardware has 2 breakpoint/watchpoint unitsInfo : starting gdb server for ad6528.cpu on 3333Info : Listening on port 3333 for gdb connectionsError: invalid mode value encountered 4Error: cpsr contains invalid mode value - communication failurePolling target ad6528.cpu failed, trying to reexamineInfo : Embedded ICE version 9Error: unknown EmbeddedICE version (comms ctrl: 0x96628003)Info : ad6528.cpu: hardware has 2 breakpoint/watchpoint unitstarget halted in ARM state due to watchpoint, current mode: Usercpsr: 0x800280d0 pc: 0x800280aeWarn : ThumbEE -- incomplete supporttarget halted in ThumbEE state due to watchpoint, current mode: Systemcpsr: 0xffffffff pc: 0xfffffff9Actually running this will shutdown device

author: abyrvalg
author_rank: Frequent Contributor
timestamp: February 07, 2025, 07:00:00 am
content: Looks like this TAP you are talking to is not an ARM core. Try the other TAP (change _CPUTAPID to the other one).

author: oh2ftu
author_rank: Regular Contributor
timestamp: February 07, 2025, 03:28:51 pm
content: Changing the _tapid results in the following;Code:# openocd -f interface/jlink.cfg -f cpu/arm/arm7tdmi.tcl -f target/ad6528.cfgOpen On-Chip Debugger 0.12.0Licensed under GNU GPL v2For bug reports, readhttp://openocd.org/doc/doxygen/bugs.html32Info : auto-selecting first available session transport "jtag". To override use 'transport select <transport>'.ad6528.cpuInfo : Listening on port 6666 for tcl connectionsInfo : Listening on port 4444 for telnet connectionsWarn : 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:35Info : Hardware version: 11.00Info : VTarget = 3.166 VInfo : clock speed 100 kHzInfo : 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 0x01Warn : Bypassing JTAG setup events due to errorsInfo : Embedded ICE version 1Info : ad6528.cpu: hardware has 2 breakpoint/watchpoint unitsInfo : starting gdb server for ad6528.cpu on 3333Info : Listening on port 3333 for gdb connectionstarget halted in ARM state due to watchpoint, current mode: IRQcpsr: 0x800281d2 pc: 0x800281ae

author: abyrvalg
author_rank: Frequent Contributor
timestamp: February 07, 2025, 05:00:12 pm
content: Ahh, my bad, you need to declare the other TAP anyway. Must be something like this:Code:set _CHIPNAME ad6528set _UNKTAPID 0x1684a555set _CPUTAPID 0x027a21cbset _ENDIAN littlejtag newtap UNKNOWN unknown0 -irlen 4 -expected-id $_UNKTAPIDjtag newtap $_CHIPNAME cpu -irlen 4 -expected-id $_CPUTAPIDset _TARGETNAME $_CHIPNAME.cputarget create $_TARGETNAME arm7tdmi -endian $_ENDIAN -chain-position $_TARGETNAME

author: oh2ftu
author_rank: Regular Contributor
timestamp: February 07, 2025, 05:46:11 pm
content: ok, so I'm this far:Code:# openocd -f interface/jlink.cfg -f cpu/arm/arm7tdmi.tcl -f target/ad6528.cfgOpen On-Chip Debugger 0.12.0Licensed under GNU GPL v2For bug reports, readhttp://openocd.org/doc/doxygen/bugs.html32Info : auto-selecting first available session transport "jtag". To override use 'transport select <transport>'.ad6528.cpuInfo : Listening on port 6666 for tcl connectionsInfo : Listening on port 4444 for telnet connectionsWarn : 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:35Info : Hardware version: 11.00Info : VTarget = 3.172 VInfo : clock speed 100 kHzInfo : 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 1Info : ad6528.cpu: hardware has 2 breakpoint/watchpoint unitsInfo : starting gdb server for ad6528.cpu on 3333Info : Listening on port 3333 for gdb connectionsAnd I'm able to open a telnet session. Now the interesting part, defining the flash?It should be CFI-compatible - whatever that means?

author: abyrvalg
author_rank: Frequent Contributor
timestamp: February 07, 2025, 06:44:22 pm
content: 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:haltregAnd to do the actual dumping usemdb address sizeanddump_image filename address size.

author: oh2ftu
author_rank: Regular Contributor
timestamp: February 08, 2025, 05:33:17 am
content: Hmm, these are the registers shown;Code:> halttarget halted in Thumb state due to debug-request, current mode: Systemcpsr: 0x8000003f pc: 0x0225c334ThumbEE -- incomplete supporttarget halted in ThumbEE state due to debug-request, current mode: Systemcpsr: 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?

author: abyrvalg
author_rank: Frequent Contributor
timestamp: February 08, 2025, 09:45:02 am
content: 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 tryingreset haltcommand 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.

author: oh2ftu
author_rank: Regular Contributor
timestamp: February 08, 2025, 03:04:36 pm
content: 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:ad6528.cpuInfo : Listening on port 6666 for tcl connectionsInfo : Listening on port 4444 for telnet connectionsWarn : 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:35Info : Hardware version: 11.00Info : VTarget = 3.141 VInfo : clock speed 100 kHzInfo : 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 errorsInfo : Embedded ICE version 1Info : ad6528.cpu: hardware has 2 breakpoint/watchpoint unitsInfo : starting gdb server for ad6528.cpu on 3333Info : Listening on port 3333 for gdb connectionsInfo : accepting 'telnet' connection on tcp/4444It finds some new devices.but! when running halt, I get this:Code:> halttarget halted in ARM state due to debug-request, current mode: FIQcpsr: 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)

author: abyrvalg
author_rank: Frequent Contributor
timestamp: February 08, 2025, 04:02:50 pm
content: 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.Trymdb 0 0x100andmdb 0x02000000 0x100to 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).

author: oh2ftu
author_rank: Regular Contributor
timestamp: February 08, 2025, 04:37:31 pm
content: I did some more testing;Code:> halttarget halted in Thumb state due to debug-request, current mode: Systemcpsr: 0x8000003f pc: 0x0225be7c> arm regSystem and User mode registersr0: 00007f20 r1: 000186a0 r2: 4004649c r3: 0225be1dr4: 08112c30 r5: 80040600 r6: 00000004 r7: 80040604r8: bbbbbbbb r9: bbbbbbbb r10: bbbbbbbb r11: bbbbbbbbr12: 4001f8b1 sp_usr: 083ab8e8 lr_usr: 0225be61 pc: 0225be7ccpsr: 8000003fFIQ mode shadow registersr8_fiq: ffffffff r9_fiq: ffffffff r10_fiq: ffffffff r11_fiq: ffffffffr12_fiq: ffffffff sp_fiq: ffffffff lr_fiq: ffffffff spsr_fiq: ffffffffSupervisor mode shadow registerssp_svc: ffffffff lr_svc: ffffffff spsr_svc: ffffffffAbort mode shadow registerssp_abt: ffffffff lr_abt: ffffffff spsr_abt: ffffffffIRQ mode shadow registerssp_irq: ffffffff lr_irq: ffffffff spsr_irq: ffffffffUndefined instruction mode shadow registerssp_und: ffffffff lr_und: ffffffff spsr_und: ffffffffmdb 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

author: abyrvalg
author_rank: Frequent Contributor
timestamp: February 08, 2025, 05:14:59 pm
content: 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 tryreset haltinstead 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).

author: oh2ftu
author_rank: Regular Contributor
timestamp: February 08, 2025, 05:45:21 pm
content: 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.

author: abyrvalg
author_rank: Frequent Contributor
timestamp: February 08, 2025, 07:16:05 pm
content: 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 triedreset halt?

author: oh2ftu
author_rank: Regular Contributor
timestamp: February 09, 2025, 08:38:10 am
content: Quote from: abyrvalg on February 08, 2025, 07:16:05 pmHi,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:> reset haltTAP 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?

author: abyrvalg
author_rank: Frequent Contributor
timestamp: February 09, 2025, 07:35:51 pm
content: You need to configure the reset method before issuing a reset command (either in the cfg file or manually). Usereset_config srst_onlyor if you have both the system reset signal and the jtag reset (nTRST) connected, usereset_config trst_and_srstto use both of them. With this command present OpenOCD should know how to reset the chip.

author: oh2ftu
author_rank: Regular Contributor
timestamp: February 16, 2025, 07:32:42 pm
content: 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.

author: oh2ftu
author_rank: Regular Contributor
timestamp: February 22, 2025, 09:03:27 am
content: 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:> halttarget halted in Thumb state due to debug-request, current mode: Systemcpsr: 0x200000ff pc: 0x025321d6> arm regSystem and User mode registersr0: 00000007 r1: 00040000 r2: 0000001e r3: 0000000cr4: ffffb575 r5: 802000a0 r6: ffffffc0 r7: 082c4790r8: bbbbbbbb r9: bbbbbbbb r10: bbbbbbbb r11: bbbbbbbbr12: 00000000 sp_usr: 0856c4e0 lr_usr: 025321cb pc: 025321d6cpsr: 200000ffFIQ mode shadow registersr8_fiq: fffffffe r9_fiq: bfefffff r10_fiq: ffbf6fdf r11_fiq: dfff7f3br12_fiq: ffbf3dbe sp_fiq: 4005bd48 lr_fiq: 40046c7c spsr_fiq: 4000003fSupervisor mode shadow registerssp_svc: 40046100 lr_svc: 024eab38 spsr_svc: 8000003fAbort mode shadow registerssp_abt: bfdf7fff lr_abt: ffffff7f spsr_abt: f00000ffIRQ mode shadow registerssp_irq: ffdfffff lr_irq: 3fff7fff spsr_irq: f00000ffUndefined instruction mode shadow registerssp_und: ffbf3f7f lr_und: ffbff77f spsr_und: f00000ff> mdb 0 0x1000x00000000: 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 ea0x00000020: 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 e10x00000040: 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 e30x00000060: 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 e30x00000080: 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 e30x000000a0: 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 e90x000000c0: 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 e50x000000e0: 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 9aAnd the other regionCode:> mdb 0x02000000 0x1000x02000000: 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 ea0x02000020: 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 000x02000040: 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 000x02000060: 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 000x02000080: 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 000x020000a0: 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 000x020000c0: 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 000x020000e0: 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 00Finally, some data!The flash is 256Mbit, so 32MB. Size in hex 0x02000000?Where would this area be?

author: oh2ftu
author_rank: Regular Contributor
timestamp: February 23, 2025, 06:29:50 am
content: 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 dumpeddump_image filename.bin 0x02000000 0x02000000and 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:flash bank name driver base size chip_width bus_width targetThe example from the docs:Code: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 $_TARGETNAMEflash bank $_FLASHNAME cfi 0x01000000 0x01000000 2 2 $_TARGETNAMETo 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 $_TARGETNAMENow I don't know about the banks? the flash is a 16Mx16 piece (multiple bank, bultilevel burst).Should this be configured as 16 banks?

author: oh2ftu
author_rank: Regular Contributor
timestamp: February 23, 2025, 02:36:31 pm
content: 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:> flash info 1#1 : cfi at 0x02000000, size 0x02000000, buswidth 2, chipwidth 2..... addresses ....CFI flash: mfr: 0xf01c, id:0xe59fqry: 'QRY', pri_id: 0x0001, pri_addr: 0x010a, alt_id: 0x0000, alt_addr: 0x0000Vcc min: 1.7, Vcc max: 2.0, Vpp min: 8.5, Vpp max: 9.5typ. word write timeout: 256 us, typ. buf write timeout: 512 us, typ. block erase timeout: 1024 ms, typ. chip erase timeout: 1 msmax. word write timeout: 512 us, max. buf write timeout: 1024 us, max. block erase timeout: 4096 ms, max. chip erase timeout: 1 mssize: 0x2000000, interface desc: 1, max buffer write size: 0x40intel primary algorithm extend information:pri: 'PRI', version: 1.3feature_support: 0x3e6, suspend_cmd_support: 0x1, blk_status_reg_mask: 0x1Vcc opt: 1.8, Vpp opt: 9.0protection_fields: 2, prot_reg_addr: 0x80, factory pre-programmed: 8, user programmable: 8Any idea how to speed things up a bit?

author: abyrvalg
author_rank: Frequent Contributor
timestamp: February 23, 2025, 03:03:11 pm
content: Congratulations! That dump looks like valid ARM code.Speeding the things up - you don’t need to useflashcommands for reading, they read the same datadump_imagedoes, just in some less efficient manner. The only thing requiringflashis writing. Try raising TCK frequency instead, i.e.adapter speed 10000should 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.

author: oh2ftu
author_rank: Regular Contributor
timestamp: February 23, 2025, 03:37:25 pm
content: 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.

author: abyrvalg
author_rank: Frequent Contributor
timestamp: February 23, 2025, 10:19:18 pm
content: 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.