Debrick Synth

[sonictruth]

Hi I got stuck trying to revive a bricked Synth flashed with the wrong patched firmware.

I got to the point that there is not error but the the device is not booting up in the last steps.

Using:
Using RPI 4 / Raspbian bullseye / 6.1.21-v8+
Open On-Chip Debugger 0.12.0

openocd.cfg changes:

bcm2835gpio_peripheral_base 0xFE000000
bcm2835gpio_speed_coeffs 236181 60 
adapter speed 200 # adapter speed 0 crashes without any error

First boot dumping SBL. LCD backlight on:

Info : clock speed 1504 kHz
Info : JTAG tap: omapl138.jrc tap/device found: 0x1b7d102f (mfg: 0x017 (Texas Instruments), part: 0xb7d1, ver: 0x1)
adapter speed: 100 kHz (tried 100 and 500 and 1000)

target halted in ARM state due to debug-request, current mode: Abort
cpsr: 0x800000d7 pc: 0xc000007c (same value on every boot)

✅ SBL dump worked.

Second boot OpenOCD on. LCD backlight off:

target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0x600000d3 pc: 0xfffd8abc (different last two digits pc on every boot  0xfffd8aXX)

✅ Loading of SBL worked

> load_image SBLk1.bin 0x80000000
24128 bytes written at address 0x80000000
downloaded 24128 bytes in 2.589507s (9.099 KiB/s)

> reg pc 0x80000000
pc (/32): 0x80000000

> bp 0xc0000000 4 hw 
breakpoint set at 0xc0000000

(without hw it fails: Unable to set 32 bit software breakpoint at address c0000000 - check that memory is read/writable)

> resume

target halted in ARM state due to breakpoint, current mode: Supervisor
cpsr: 0x600000d3 pc: 0xc0000000

> load_image SYSTEM.bin 0xc0000000
2097152 bytes written at address 0xc0000000
downloaded 2097152 bytes in 220.772400s (9.277 KiB/s)


> resume

Screen still off no backlight

> halt
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0x600000d3 pc: 0xf70b7184

Any tips ?

Thank you 🙏

[sonictruth]

Fixed by loading and starting SYSTEM.bin after first crash (backlight on).

Open On-Chip Debugger
> halt
> load_image SYSTEM.bin  0xc0000000
2097152 bytes written at address 0xc0000000
downloaded 2097152 bytes in 110.801941s (18.483 KiB/s)

> reg pc 0xc0000000
pc (/32): 0xc0000000

> resume

[bangcorrupt]

Fixed by loading and starting SYSTEM.bin after first crash (backlight on).

This is interesting, it wasn't possible for me. It probably depends on how far the app got with initialising the hardware before it crashed. I have no idea why it wouldn't work when you executed the SBL first, I was going to suggest reading back the memory using dump_image to check it was correctly written.

I've added some notes to the relevant sections in the wiki, with a link to this discussion at the start.

Some further notes:

adapter speed 200 # adapter speed 0 crashes without any error

adapter speed 0 should enable adaptive clocking. It helped for me but I was using RPi 1b and OpenOCD has been updated a lot since I wrote this config. This value is already set to 1500 in the target config, so it may be possible to omit it here. We can run openocd with the flag -d to enable a lot of useful debug information.

cpsr: 0x800000d7 pc: 0xc000007c # (same value on every boot)

0xc000007c is the address of an infinite loop in the abort handler. This is where we should end up if the processor encounters an illegal instruction.

cpsr: 0x600000d3 pc: 0xfffd8abc # (different last two digits pc on every boot 0xfffd8aXX)

When the processor is reset with a debugger attached it waits in the ROM bootloader, in ARM RAM. If you step it will loop through a few instructions forever.

bp 0xc0000000 4 hw
(without hw it fails: Unable to set 32 bit software breakpoint at address c0000000 - check that memory is read/writable)

I've updated this in the wiki. I think I managed to use software breakpoints somehow, but we only need one breakpoint and there are 2 hardware breakpoints available.