I ran into an interesting problem when flashing an embedded STM32H750 on one of my project boards. The flash process works, but an error is reported:

 Open On-Chip Debugger 0.10.0+dev-00021-g524e8c8 (2019-04-12-08:42)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
srst_only separate srst_nogate srst_open_drain connect_assert_srst
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 8000 kHz
adapter_nsrst_delay: 100
Info : clock speed 8000 kHz
Info : STLINK v2.1 JTAG v33 API v2 M25 VID 0x0483 PID 0x374B
Info : using stlink api v2
Info : Target voltage: 0.022004
Error: target voltage may be too low for reliable debugging
Info : Unable to match requested speed 8000 kHz, using 4000 kHz
Info : Stlink adapter speed set to 4000 kHz
Info : STM32H750VBTx.cpu0: hardware has 8 breakpoints, 4 watchpoints
Info : Listening on port 3333 for gdb connections
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x080031ac msp: 0x20020000
Info : Unable to match requested speed 8000 kHz, using 4000 kHz
Info : Stlink adapter speed set to 4000 kHz
Info : Unable to match requested speed 8000 kHz, using 4000 kHz
adapter speed: 4000 kHz
** Programming Started **
auto erase enabled
Info : Device: STM32H7xx 2M
Info : flash size probed value 128
Info : STM32H flash size is 128kb, base address is 0x8000000
wrote 131072 bytes from file Debug/EmboardV1.elf in 1.930074s (66.319 KiB/s)
** Programming Finished **
** Verify Started **
target halted due to breakpoint, current mode: Thread 
xPSR: 0x61000000 pc: 0x2000002e msp: 0x20020000
verified 12984 bytes in 0.094487s (134.195 KiB/s)
** Verified OK **
** Resetting Target **
Error: mem2array: Read @ 0x5c001004, w=4, cnt=1, failed
mem_helper.tcl:6: Error: 
in procedure 'program' 
in procedure 'reset' called at file "embedded:startup.tcl", line 532
in procedure 'ocd_bouncer' 
in procedure 'ocd_process_reset' 
in procedure 'ocd_process_reset_inner' called at file "embedded:startup.tcl", line 248
in procedure 'STM32H750VBTx.cpu0' called at file "embedded:startup.tcl", line 388
in procedure 'ocd_bouncer' 
in procedure 'mmw' 
in procedure 'mrw' called at file "/Applications/Ac6/SystemWorkbench.app/Contents/Eclipse/plugins/fr.ac6.mcu.debug_2.5.0.201904120827/resources/openocd/st_scripts/mem_helper.tcl", line 25
at file "/Applications/Ac6/SystemWorkbench.app/Contents/Eclipse/plugins/fr.ac6.mcu.debug_2.5.0.201904120827/resources/openocd/st_scripts/mem_helper.tcl", line 6

shutdown command invoked

The error:

 Error: "mem2array: Read @ 0x5c001004, w=4, cnt=1, failed"

is of interest. If I switch from my project board to a Nucleo STM32H743 based board the same code flashed without this error. One difference between the boards is that my board only supports SWD, while the Nucleo board supports both SWD and JTAG.

After a bit of digging I was able to find the references that were driving the mem2array calls in stm32h7x.cfg (located at /Applications/Ac6/SystemWorkbench.app/Contents/Eclipse/plugins/fr.ac6.mcu.debug_2.5.0.201904120827/resources/openocd/st_scripts/target) which has a number of references to memory locations in the 0x5C00xxxx range. In looking that the data sheet for the STM32H7xx that memory area is the hardware debug and trace registers. The critical thing of note in the data sheet is the mention that the 0x5C00xxxx addresses are only addressable from the system data bus. If access is performed from the ‘debug interface’ you need to use 0xE00Fxxxx instead.

I tried changing all of the memory references in that config file to 0xE00F from the 0cx5C00 addresses, and the error goes away when flashing my board.

I am suspecting that the error does not occur with the nucleo board because the JTAG interface allows access via the system bus, while the SWD interface only allows access via the debug interface.

It would seem a change would need to be made to that config interface to use the correct addresses based on the particulars of the interface.

Does anyone know if I am understanding this correctly? Should I submit a bug to the OpenOCD people?

Cheers,

Jeff