Suggestion: Better instructions for flashing/debugging with JTAG

[HarryMakes]

Update: the error is produced because of a wrong sequence of supplying power to the board - see this reply. However, the need to use the OpenOCD command gdb_memory_map disable might still be needed in the latest unstable of OpenOCD.

---

When testing the JTAG programming option with the latest commit of OpenOCD (openocd-org/openocd@1457a1a), running openocd -f stabilizer.cfg would always produce the following error:

$ openocd -f stabilizer.cfg 
Open On-Chip Debugger 0.10.0+dev-snapshot (2020-09-08-07:03)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
WARNING: interface/stlink-v2-1.cfg is deprecated, please switch to interface/stlink.cfg
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : clock speed 1800 kHz
Info : STLINK V2J29S7 (API v2) VID:PID 0483:3748
Info : Target voltage: 3.380611
Info : stm32h7x.cpu0: hardware has 8 breakpoints, 4 watchpoints
Error: mem2array: Read @ 0x5c001004, w=4, cnt=1, failed
Error executing event examine-end on target stm32h7x.cpu0:
/nix/store/ihj6fj3rw65j6kaxxnnhpm4l3qh1nsqj-openocd-0.10.0-dev/bin/../share/openocd/scripts/target/stm32h7x.cfg:199: Error: 
in procedure 'stm32h7x_dbgmcu_mmw' called at file "/nix/store/ihj6fj3rw65j6kaxxnnhpm4l3qh1nsqj-openocd-0.10.0-dev/bin/../share/openocd/scripts/target/stm32h7x.cfg", line 149
in procedure 'stm32h7x_mmw' called at file "/nix/store/ihj6fj3rw65j6kaxxnnhpm4l3qh1nsqj-openocd-0.10.0-dev/bin/../share/openocd/scripts/target/stm32h7x.cfg", line 224
in procedure 'stm32h7x_mrw' called at file "/nix/store/ihj6fj3rw65j6kaxxnnhpm4l3qh1nsqj-openocd-0.10.0-dev/bin/../share/openocd/scripts/target/stm32h7x.cfg", line 205
at file "/nix/store/ihj6fj3rw65j6kaxxnnhpm4l3qh1nsqj-openocd-0.10.0-dev/bin/../share/openocd/scripts/target/stm32h7x.cfg", line 199
Info : starting gdb server for stm32h7x.cpu0 on 3333
Info : Listening on port 3333 for gdb connections

Then, running cargo run would produce another error:

$ cargo run --release
    Finished release [optimized + debuginfo] target(s) in 0.02s
     Running `gdb -q -x openocd.gdb target/thumbv7em-none-eabihf/release/stabilizer`
Reading symbols from target/thumbv7em-none-eabihf/release/stabilizer...
Info : accepting 'gdb' connection on tcp/3333
Info : Halt timed out, wake up GDB.
Error: timed out while waiting for target halted
Error executing event gdb-attach on target stm32h7x.cpu0:

Warn : negative reply, retrying
Warn : negative reply, retrying
...

After Google search, the error lines mem2array: Read @ 0x5c001004, w=4, cnt=1, failed and timed out while waiting for target halted might be related to a missing gdb_memory_map disable OpenOCD command. Thus, there is a solution online that would solve this issue: https://codelv.com/blog/2020/1/attaching-to-stm32-with-openocd-during-sleep . Simply put, the steps to properly use OpenOCD/GDB on the board are:

1. Kill all related instances of OpenOCD and GDB.
2. Run openocd -f stabilizer.cfg -c "gdb_memory_map disable" & to run it in background in the same shell.
   3. Run gdb and use target remote :3333 to verify the connection.
   4. Kill the OpenOCD and GDB again.
   5. Run openocd -f stabilizer.cfg &.
3. Run cargo run --release.

I am not sure how to simplify these steps yet, but above is what I would suggest to be added to the README for the time being.

[jordens]

That doesn't happen here for me. And it doesn't look like this has anything to do with stabilizer. It seems to be related to your openocd version. I suspect the fix should be in openocd and not in the README here.

[ryan-summers]

It's very likely that this is related to a recent update from OpenOCD (your log indicates an OpenOCD built today). The OpenOCD used during development was built from openocd a few months ago, and it's likely the version on both @jordens and my machine are older.

It is possible that they recently added changes that require the usage of gdb_memory_map disable. We should update our references here to specify a specific openocd tag that we support to avoid these issues in the future.

[HarryMakes]

Thank you for the replies. The OpenOCD version I was using is indeed very recent (2020-09-06, openocd-org/openocd@1457a1a). However, when I switched to the oldest OpenOCD commit that target/stm32h7x_dual_bank.cfg exists (2017-10-07, openocd-org/openocd@6090a5b), I get a different error - "open failed":

$ openocd -f stabilizer.cfg &
Open On-Chip Debugger 0.10.0+dev-snapshot (2020-09-09-04:59)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 1800 kHz
adapter_nsrst_delay: 100
srst_only separate srst_nogate srst_open_drain connect_deassert_srst
none separate
Info : clock speed 1800 kHz
Error: open failed
in procedure 'init' 
in procedure 'ocd_bouncer'

Please note that I am using an ST-Link v2 debugger, so I have to change the 1st line of stabilizer.cfg to source [find interface/stlink-v2-1.cfg]. (Edit: the latest versions of OpenOCD don't need such change, as it can detect v2 through interface/stlink.cfg directly.)

On the other hand, the earliest OpenOCD commit I found that would require the gdb_memory_map disable command is openocd-org/openocd@678fb4f, which is also the 2nd (and latest) commit applied to target/stm32h7x_dual_bank.cfg (see file history here).

[ryan-summers]

For reference, my openocd -v command returns the following output:

Open On-Chip Debugger 0.10.0+dev-01267-g4c364b45-dirty (2020-06-04-21:57)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html

The -dirty appears to be due to build artifacts in the directory, although I am unsure. I have not modified the OpenOCD configuration and the repository I built from is still on my machine.

This corresponds to openocd-org/openocd@4c364b4

However, this is done using the ST-link v3 debugger - it is possible that the command is related to the debug probe used, although I'm not familiar enough with OpenOCD to say either way.

Ideally, we will be able to avoid using openocd in the future as probe-rs develops further. We currently only use openocd to support gdb-based debugging, but this isn't necessary for simple flashing operations. I would recommend we update the flashing instructions to instead use probe-rs and cargo flash.

[HarryMakes]

Sorry, even with your OpenOCD version I still get the mem2array: Read @ 0x5c001004, w=4, cnt=1, failed error. (See this reply)

Yes, it sounds nice to use other tools like probe-rs and/or cargo flash. I can take a look at how to use them when I have time, and hopefully I can help draft the new instructions using those tools!

[HarryMakes]

I have finally figured out the problem. I got errors and couldn't load the binary to the flash because I powered the board BEFORE connecting the ST-Link debugger to it. I was unaware that the sequence of supplying power to the board would make such a huge difference.

Because of this, perhaps we could (1) tag the OpenOCD commit needed without using gdb_memory_map disable, and (2) remind the user to connect 12V before the JTAG adaptor/ debugger.

[jordens]

Connecting the debugger to a live board is also somewhat dangerous if you don't ensure level grounds before connecting.

[HarryMakes]

I've been following the correct power sequence to flash the board successfully with OpenOCD/GDB. However, the mem2array: Read @ 0x5c001004, w=4, cnt=1, failed error has reappeared lately, and it seems to never happen without power-cycling the board after re-flashing some firmware to it. When that happen, there's a workaround I found - use DFU to erase the board first. The dfu-util command I use is:

dfu-util -D dummy.file -a 0 -s 0x08000000:mass-erase:force

The mass-erase parameter is to erase the flash, and the file passed to -D will be ignored so any file can be used for that purpose. After erasing with DFU, you can either download a new binary to the board via DFU, or use OpenOCD/GDB again.

[jordens]

Closing as this seems to:

• refer to some spurious flashing issue that we haven't been able to reproduce
• refer to old flashing instructions that are outdated w.r.t. Adding Stabilizer User Manual #401

Please open new issues if anything here is still pertinent.