Suggestion: Better instructions for flashing/debugging with JTAG about stabilizer HOT 9 CLOSED

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

from stabilizer.

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.

from stabilizer.

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.

from stabilizer.

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).

from stabilizer.

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.

from stabilizer.

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!

from stabilizer.

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.

from stabilizer.

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.

from stabilizer.

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. #401

Please open new issues if anything here is still pertinent.

from stabilizer.