Debricking issue - Halted in Arm state due to De-Bug request

[ctlombardo]

Hello all and Bangcorrupt,

Thank you for putting this hack out there. I'm eager to De-Brick my beloved electribe and try to install the hack from scratch.

However, I am stuck in unfamiliar territory to me and looking for some guidance.

My brick allowed my device to power on with a white, blank screen but nothing further.
I've successfully connected OpenOcd to my electribe via Rpi and upon powering up the bricked Electribe -

OpenOCD reads the following aftering showing the device is connected and all details:

---

target halted in ARM state due to debug-request, current mode: Abort
cpsr: 0x800000d7 pc: 0x80000XXc
MMU: enabled, D-Cache: enabled I-Cache enabled

((((the PC info "XX" keeps changing as OpenOCD keeps repeating this message))))

and unfortunately I can't seem to get a response past this stage - Screenshot attached.

Any help or Guidance would be most apprciated.

[bangcorrupt]

Hi, I can probably help you fix this if you can answer some questions.

Was it bricked using the built in firmware update function?

Did you power up the electribe, let it crash and then run openocd?

Have you dumped the secondary bootloader?

The program counter (pc) starts 0xc (not 0x8), showing execution has moved to the app in external RAM. We need to halt the processor at 0xc0000000 and load the good firmware before handing off to the corrupt app. To do this, we halt in the ROM bootloader, load the secondary bootloader, set a breakpoint, then run the secondary bootloader. If you're following the Debrick Guide, it looks like you skipped a couple of steps. I think you need to continue from Get Secondary Bootloader.

Also, when you ran the load_image command, the address is missing a zero.

[ctlombardo]

Thank you for the insights.

To clarify the synth powers up to a blank white screen.
-yes it was bricked using the firmware update function.
-synth powered up, crashes to blank white screen, which gives me the "target halted in ARM state due to debug-request...." message
-I don't believe I've made it the step in order to dump the secondary bootloader.
-I've been following the Debrick guide but am admittedly a bit lost.
-Fantastic catch about the missing 0 ... my dyslexia screws with me sometimes.

Will report back after a second attempt.

[ctlombardo]

Hi again Bangcorrupt

It has been some time since I last attempted to debrick the device.
A few questions:

1-Do I need a jtag hat or debugger to communicate between the rpi and electribe? (My image attached)

2-When opening up OpenOCD, I'm greeted with the first entry in my original screenshot:
"DEPRECATED! use 'bcm2835gpio peripheral_base' not 'bcm2835gpio peripheral_base' ...etc ....upon changing the openocd config to the suggested alternatives this error goes away. Is there an error or misstep that I've made that would give me some outdated .cfg settings?

3-In the Get Firmware Binary step "$ dd if=SYSTEM.VSB of=SYSTEM.bin bs=256 skip=1", does this happen on SYSTEM.VSB that should be placed on the SD card? When I enter this step into the terminal I receive an error that SYSTEM.VSB cannot be found.
3b-Do the System.VSB and System.Bin need to be referenced with a file path (as stated the error states they cannot be found)

[bangcorrupt]

Hi,

You only need the rpi. As long as the dupont wires make a sound electrical connection, what you have in the photo looks fine.

The config file in the repo is outdated, I'll update it. Open a PR if you want to.

If files are not in the current working directory they will need to be referenced with their path.

For debricking, SYSTEM.VSB should be the factory firmware for the device, in your case synth. The dd command is used to remove the file header, leaving only the firmware binary. The full VSB file is put on the SD card, the trimmed firmware binary is loaded into CPU RAM via openocd. Once the device has booted using openocd, use the built in firmware update function to write the flash before shutting down.

I realise now there is an important step missing from the wiki, we need a toggle switch for power. When the device powers up, the power only stays on once the firmware app is running. This may happen when it crashes, but won't happen when it starts up with a debugger attached.

Connect a switch across J4, the unpopulated 2 pin header shown near the top right of this photo, to the right of C202 and C137. The motherboard will need removing to reach it, but if you put the switch on some long thin wires you can replace the motherboard after.

Each time the device is powered up while debricking, use the toggle switch instead of the power button. This will keep the power supply active. Once the firmware app starts booting, turn the toggle switch off or it will shutdown as soon as it has booted, thinking the power switch is held.

[ctlombardo]

Thank you for the insight. I'll be wiring up a switch at the next attempt.

I've updated the config file to include the adjustments to the deprecated details, filepath to the am1802.cfg.

It seems I am now making connection with the electribe. It is detecting a Hitachi component which I assume is Electribe.

Terminal gives me this and an error when attempting to run openocd.cfg - what error am I encountering and why?:

"openocd -f /home/admin/Downloads/hacktribe-main/openocd/openocd.cfg
Open On-Chip Debugger 0.12.0-rc2+dev-00019-g9d925776b (2022-11-19-19:28)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
force hard breakpoints
Info : BCM2835 GPIO JTAG/SWD bitbang driver
Info : clock speed 1516 kHz
Info : JTAG tap: omapl138.jrc tap/device found: 0x1278000f (mfg: 0x007 (Hitachi), part: 0x2780, ver: 0x1)
Warn : JTAG tap: omapl138.jrc UNEXPECTED: 0x1278000f (mfg: 0x007 (Hitachi), part: 0x2780, ver: 0x1)
Error: JTAG tap: omapl138.jrc expected 1 of 1: 0x0b7d102f (mfg: 0x017 (Texas Instruments), part: 0xb7d1, ver: 0x0)
Info : TAP auto0.tap does not have valid IDCODE (idcode=0xfffffffe)
Error: Trying to use configured scan chain anyway...
Warn : AUTO auto0.tap - use "jtag newtap auto0 tap -irlen 2 -expected-id 0x00000000"
Error: auto0.tap: IR capture error; saw 0x0002 not 0x0001
Warn : Bypassing JTAG setup events due to errors
Info : starting gdb server for omapl138.arm on 3333
Info : Listening on port 3333 for gdb connections
Error: Target not examined yet
"

Forgive my ignorance with this project. I jumped the gun and improperly assumed a quick fix.

[bangcorrupt]

Warn : JTAG tap: omapl138.jrc UNEXPECTED: 0x1278000f (mfg: 0x007 (Hitachi), part: 0x2780, ver: 0x1)
Error: JTAG tap: omapl138.jrc expected 1 of 1: 0x0b7d102f (mfg: 0x017 (Texas Instruments), part: 0xb7d1, ver: 0x0)

The Hitachi part listed is an error, it should find the Texas Instruments part listed in the error message. This suggests a poor electrical connection causing bit errors due to noise. In your first screenshot it finds the CPU and connects correctly, you just ran the wrong commands after. Double check each connection and ensure each pin has a firm contact, any movement will cause errors. You may have to run it a few times before it connects correctly (soldering a header will be more reliable, but it's easy to damage the board if you haven't had much practice soldering small things).

Forgive my ignorance with this project. I jumped the gun and improperly assumed a quick fix.

Don't worry, this isn't easy. Keep asking questions, it makes it a lot easier to document the process.

[ctlombardo]

Totally fascinating. I'm able to get the Texas Instruments info to show up after reseating the cables (but the subtlest movement breaks the connection and I get the hitachi error after running the openocd command again). No Toggle switch wired up yet but will get that in today.

Thanks again!

[bangcorrupt]

The Texas Instruments part shown in this screenshot is also an error. The lines starting Warn and Error are the ones to look for. It's getting the same part number each time but with a slightly different manufacturer ID.

It may be an issue with clock speed and peripheral base address. I wrote the config for a rpi 1b, it looks like you're using a 2 or 3. OpenOCD supplies a config file for rpi2 at /usr/share/openocd/scripts/interface/raspberrypi2-native.cfg. Try replacing the lines starting bcm2835gpio_peripheral_base and bcm2835gpio_speed_coeffs in the hacktribe openocd.cfg with those from the raspberrypi2-native.cfg supplied by openocd (I think the same config should work with rpi 2 and 3).

[ctlombardo]

Im back! I finally opened up the front of the unit and found j4

A small question on the wiring: is it image a or b?

I'm a creating a circuit by soldering 1 wire to j4, the other end to the switch. Switch over to the unpopulated terminal on the power button.
Or
Must I wire up both holes of j4, one going to the switch, the other going to the unpopulated terminal.

Thanks!

[bangcorrupt]

Neither, connect the switch only to J4, ignore the power button. Closing the switch should connect the 2 terminals of J4.

[ctlombardo]

Understood thank you

[ctlombardo]

Wonderful. All wired up and the switch powers on the unit. I'll give the firmware another go tomorrow.

[ctlombardo]

Work has been hell....
I'm finally soldered up, rewired, and have the power modification in place.

When running the openocd command, I get a terminal read out I have yet to see.

Where have I gone wrong this time?

[bangcorrupt]

Looks like what you might get if there was a poor connection or a short, or one of the wires was connected to the wrong pin. Double check every joint with a multi-meter and make sure all the connections are between the correct pins. If you haven't already, try with the 2 values from the rpi2 config file as in my previous comment, but this looks like a dodgy connection issue.

[ctlombardo]

I'll give that all a shot.

Are the PIN numbers referring to the GPIO NUMBERS or the PHYSICAL PIN on the pi.

For instance pin #22 is also GPIO 6 in the graphic below - what would this be considered in the cfg file? Connection 6 or 22?

[bangcorrupt]

In openocd.cfg, the comment at line 20 # Header pin numbers: 23 22 19 21 shows the physical location of the pins on the header, the command at line 21 bcm2835gpio_jtag_nums 11 25 10 9 uses the pin numbers as the CPU sees them.

Pay attention to the note at the bottom of the diagram you posted. Physical pin 22 is CPU pin 25, which for some reason is called pin 6 in the WiringPi library.

Using pin numbers by physical location:

E2.J9 <-> RPI.GPIO

GND <---> 20 (or any other ground pin)
TMS <---> 22
TCK <---> 23
TRS <---> 26
TDI <---> 19
TDO <---> 21

[ctlombardo]

Great, that's how I've had connected. Just making sure all possible issues are accounted for