Error target voltage may be too low for reliable debugging

I'm not sure if this problem is something that should be reported to the
OpenOCD team, or the OpenSTM32 team.

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

Looking at the above trace you can see:
"Error: mem2array: Read @ 0x5c001004, w=4, cnt=1, failed" is the item 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?


Jeff

Hi Jeff,


>> ** Resetting Target **
>> Error: mem2array: Read @ 0x5c001004, w=4, cnt=1, failed


In fact you got the issue, because the DBGMCU CR register cannot be read from AP0 while SRST is asserted.

So maybe you could retry by setting reset_config to none.



>> 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’m afraid that this does not solve the issue, in fact the DBGMCU registers should be accessed at offset 0x5c001000 if you are using AP0, and if you are willing to use the AP2, the offset 0xe00e1000 should be used.

So just changing the address does not solve the issue, you should select the AP2 also.

Please take a look at this patch : http://openocd.zylin.com/#/c/4742/ that tries to solve this issue.

But this won’t work with the current implementation of ST-Link as HLA adapter (no muti-AP support).



Tarek


From: Jeff Sponaugle <je...@sp...>
Sent: Monday, May 6, 2019 7:21 PM
To: openo...@li...
Subject: [OpenOCD-user] Flashing problem with STM32H750

I'm not sure if this problem is something that should be reported to the OpenOCD team, or the OpenSTM32 team.
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

Looking at the above trace you can see:
"Error: mem2array: Read @ 0x5c001004, w=4, cnt=1, failed" is the item 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?



Jeff

Thanks for the explanation Tarek.  I didn't catch the multiple access ports
issue, but now it makes sense.  I should have paid more attention to that
part of the data sheet.     Just curious, but the reason I didn't get the
same errors when flashing the same chip on the ST produced Nucleo STM32H743
board is because the config for that board perhaps has the reset_config set
to none?

Thanks for the explanation and suggestions.. much appreciated!

Jeff



On Mon, May 20, 2019 at 4:57 AM Tarek BOUCHKATI <tarek...@st...>
wrote:

> Hi Jeff,
>
>
>
> >> ** Resetting Target **
>
> >> Error: mem2array: Read @ 0x5c001004, w=4, cnt=1, failed
>
>
>
> In fact you got the issue, because the DBGMCU CR register cannot be read
> from AP0 while SRST is asserted.
>
> So maybe you could retry by setting reset_config to none.
>
>
>
> >> 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’m afraid that this does not solve the issue, in fact the DBGMCU
> registers should be accessed at offset 0x5c001000 if you are using AP0, and
> if you are willing to use the AP2, the offset 0xe00e1000 should be used.
>
> So just changing the address does not solve the issue, you should select
> the AP2 also.
>
> Please take a look at this patch : http://openocd.zylin.com/#/c/4742/ that
> tries to solve this issue.
>
> But this won’t work with the current implementation of ST-Link as HLA
> adapter (no muti-AP support).
>
>
>
> Tarek
>
>
>
> *From:* Jeff Sponaugle <je...@sp...>
> *Sent:* Monday, May 6, 2019 7:21 PM
> *To:* openo...@li...
> *Subject:* [OpenOCD-user] Flashing problem with STM32H750
>
>
>
> I'm not sure if this problem is something that should be reported to the
> OpenOCD team, or the OpenSTM32 team.
>
> 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
>
>
>
> Looking at the above trace you can see:
>
> "Error: mem2array: Read @ 0x5c001004, w=4, cnt=1, failed" is the item 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?
>
>
>
> Jeff
>
>
>
>
>
>
>
>
>
>
>

I agree setting reset_config to none hides this behavior.
But it does not reset the target before establishing the connection.

If you are curious : I suggest to use this patch #4742 with a NON-HLA adapter (like cmsis-dap)
or apply the adapter-driver patches to be able to use it with stlink (recommended head : #4904)

Tarek


From: Jeff Sponaugle <je...@sp...>
Sent: Saturday, July 6, 2019 3:30 AM
To: Tarek BOUCHKATI <tarek...@st...>
Cc: openo...@li...
Subject: Re: [OpenOCD-user] Flashing problem with STM32H750

Thanks for the explanation Tarek.  I didn't catch the multiple access ports issue, but now it makes sense.  I should have paid more attention to that part of the data sheet.     Just curious, but the reason I didn't get the same errors when flashing the same chip on the ST produced Nucleo STM32H743 board is because the config for that board perhaps has the reset_config set to none?

Thanks for the explanation and suggestions.. much appreciated!

Jeff



On Mon, May 20, 2019 at 4:57 AM Tarek BOUCHKATI <tarek...@st...<mailto:tarek...@st...>> wrote:

Hi Jeff,


>> ** Resetting Target **
>> Error: mem2array: Read @ 0x5c001004, w=4, cnt=1, failed


In fact you got the issue, because the DBGMCU CR register cannot be read from AP0 while SRST is asserted.

So maybe you could retry by setting reset_config to none.



>> 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’m afraid that this does not solve the issue, in fact the DBGMCU registers should be accessed at offset 0x5c001000 if you are using AP0, and if you are willing to use the AP2, the offset 0xe00e1000 should be used.

So just changing the address does not solve the issue, you should select the AP2 also.

Please take a look at this patch : http://openocd.zylin.com/#/c/4742/ that tries to solve this issue.

But this won’t work with the current implementation of ST-Link as HLA adapter (no muti-AP support).



Tarek


From: Jeff Sponaugle <je...@sp...<mailto:je...@sp...>>
Sent: Monday, May 6, 2019 7:21 PM
To: openo...@li...<mailto:openo...@li...>
Subject: [OpenOCD-user] Flashing problem with STM32H750

I'm not sure if this problem is something that should be reported to the OpenOCD team, or the OpenSTM32 team.
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

Looking at the above trace you can see:
"Error: mem2array: Read @ 0x5c001004, w=4, cnt=1, failed" is the item 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?



Jeff