I’ve seen this exact issue when BOOT0 pin is not connected (floating). Jumper it to GND and retry.
I’ve put a jumper between BT0 pin and GND. The debug console output that I’m getting is the following:
PlatformIO: debug_tool = stlink
PlatformIO: Initializing remote target…
xPack OpenOCD x86_64 Open On-Chip Debugger 0.11.0+dev (2021-10-16-21:19)
Licensed under GNU GPL v2
For bug reports, read
OpenOCD: Bug Reporting
srst_only separate srst_nogate srst_open_drain connect_deassert_srstInfo : tcl server disabled
Info : telnet server disabled
Info : STLINK V3J2M1 (API v3) VID:PID 0483:374E
Info : Target voltage: 3.283200
Info : Unable to match requested speed 1800 kHz, using 1000 kHz
Info : Unable to match requested speed 1800 kHz, using 1000 kHz
Info : clock speed 1000 kHz
Info : stlink_dap_op_connect(connect)
Info : SWD DPIDR 0x6ba02477
Warn : target stm32h7x.ap2 examination failed
Warn : target stm32h7x.cpu0 examination failed
Warn : target stm32h7x.cpu1 examination failed
Info : gdb port disabled
Info : starting gdb server for stm32h7x.cpu0 on pipe
Info : starting gdb server for stm32h7x.cpu1 on pipe
Info : accepting ‘gdb’ connection from pipe
Error: Target not examined yet
Error executing event gdb-attach on target stm32h7x.cpu0:Error: Target not examined yet
Error: auto_probe failed
Error: Connect failed. Consider setting up a gdb-attach event for the target to prepare target for GDB connect, or use ‘gdb_memory_map disable’.
Error: attempted ‘gdb’ connection rejected
Info : accepting ‘gdb’ connection from pipe
Error: Target not examined yet
Error executing event gdb-attach on target stm32h7x.cpu1:Error: Target not examined yet
Error: auto_probe failed
Error: Connect failed. Consider setting up a gdb-attach event for the target to prepare target for GDB connect, or use ‘gdb_memory_map disable’.
Error: attempted ‘gdb’ connection rejected
Error: error during select: Unknown error
.pioinit:13: Error in sourced command file:
Remote communication error. Target disconnected.: Success.
Does it make a difference when you press and hold the RESET button on the Nucleo board, start the debug session again, and when you see start seeing output of OpenOCD in the debug console, release the reset button?
Also - to rule out a previous upload putting the µC in a tricky state: did the board have a blinking LED when powered up for the first time? Did you upload other firmware to this board which may affect how the µC comes out of reset (i.e. a bad clock config, or disabling the SWD pins).
AFAIU, such tricky states can only be fixed by keeping the µC in reset during the next upload, hence @maxgerhardt 's suggestion to keep the RESET button pressed until the upload actually is taking place.
For me on this board debug not working too. During probes i got your error just because first run debug process not terminated and running in background. So just check processes and kill them all
Sometime after upload firmware I got strange thing: console worked ok, leds is blinking ok, but can’t connect to board like you. I check connection from STM32CubeProgrammer and got “Target not found”. So I need erase flash sector and reupload firmware.
- Turn board off
- Put 3V3 to BOOT0
- Turn on
- Erase sector with f/w from STM32CubeProgrammer
- Turn off, remove 3V3 (or put to GND)
- Turn on and upload.
Now I try to debug empty firmware on this board with
void main(void) {
int i = 0;
while(1) {
i++;
}
}
For this moment without success but with another error.
I tried keeping Reset pressed and then releasing it when the Console debug output stops. This actually starts the onboard debug that suddenly stops with a SIGINT. Here’s the full output.
Info : tcl server disabled
Info : telnet server disabled
Info : STLINK V3J2M1 (API v3) VID:PID 0483:374E
Info : Target voltage: 3.282612
Info : Unable to match requested speed 1800 kHz, using 1000 kHz
Info : Unable to match requested speed 1800 kHz, using 1000 kHz
Info : clock speed 1000 kHz
Info : stlink_dap_op_connect(connect)
Info : SWD DPIDR 0x6ba02477
Info : stm32h7x.cpu0: Cortex-M7 r1p1 processor detected
Info : stm32h7x.cpu0: target has 8 breakpoints, 4 watchpoints
Info : stm32h7x.cpu0: external reset detected
Info : stm32h7x.cpu1: Cortex-M4 r0p1 processor detected
Info : stm32h7x.cpu1: target has 6 breakpoints, 4 watchpoints
Info : stm32h7x.cpu1: external reset detected
Info : gdb port disabled
Info : starting gdb server for stm32h7x.cpu0 on pipe
Info : starting gdb server for stm32h7x.cpu1 on pipe
Info : accepting ‘gdb’ connection from pipe
Error: timed out while waiting for target halted
Error executing event gdb-attach on target stm32h7x.cpu0:
Error: Failed to read memory at 0x5c001000
Error: auto_probe failed
Error: Connect failed. Consider setting up a gdb-attach event for the target to prepare target for GDB connect, or use ‘gdb_memory_map disable’.
Error: attempted ‘gdb’ connection rejected
Info : accepting ‘gdb’ connection from pipe
Info : Halt timed out, wake up GDB.
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08001038 msp: 0x24000700
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0xfffffffe msp: 0xfffffffc
Info : Device: STM32H74x/75x
Error: Failed to read memory at 0x1ff1e882
Info : STM32H7 flash has dual banks
Info : Bank (2) size is 1024 kb, base address is 0x08000000
Info : Device: STM32H74x/75x
Error: Failed to read memory at 0x1ff1e882
Info : STM32H7 flash has dual banks
Info : Bank (3) size is 1024 kb, base address is 0x08100000
Info : New GDB Connection: 1, Target stm32h7x.cpu1, state: halted
Warn : negative acknowledgment, but no packet pending
Warn : negative acknowledgment, but no packet pending
Ignoring packet error, continuing…
warning: unrecognized item “timeout” in “qSupported” response
Warn : negative acknowledgment, but no packet pending
Warn : keep_alive() was not invoked in the 1000 ms timelimit. GDB alive packet not sent! (20023 ms). Workaround: increase “set remotetimeout” in GDB
Error: Failed to read memory at 0x00000002
Error: Failed to read memory at 0xfffff000
0xfffffffe in ?? ()
Loading section rom_start, size 0x298 lma 0x8000000
Loading section text, size 0x32d2 lma 0x8000298
Loading section .ARM.exidx, size 0x8 lma 0x800356c
Loading section initlevel, size 0x98 lma 0x8003574
Loading section devices, size 0x168 lma 0x800360c
Loading section sw_isr_table, size 0x4b0 lma 0x8003774
Loading section device_handles, size 0x78 lma 0x8003c24
Loading section rodata, size 0x318 lma 0x8003c9c
Loading section datas, size 0x30 lma 0x8003fb4
Loading section device_states, size 0x3c lma 0x8003fe4
Start address 0x8001038, load size 16414
Transfer rate: 10 KB/sec, 107 bytes/write.
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08001038 msp: 0x24000700
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08001038 msp: 0x24000700
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0xfffffffe msp: 0xfffffffc
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0xfffffffe msp: 0xfffffffc
Temporary breakpoint 1 at 0x80002cc: file src\main.c, line 31.
PlatformIO: Initialization completed
PlatformIO: Resume the execution to
debug_init_break = tbreak main
PlatformIO: More configuration options → Redirecting...
Error: stm32h7x.cpu1 – clearing lockup after double fault
stm32h7x.cpu1 – clearing lockup after double fault
Polling target stm32h7x.cpu1 failed, trying to reexamine
Info : stm32h7x.cpu1: Cortex-M4 r0p1 processor detected
Info : stm32h7x.cpu1: target has 6 breakpoints, 4 watchpoints
Program
received signal SIGINT, Interrupt.
Error: Failed to read memory at 0x00000002
Error: Failed to read memory at 0xfffff000
0xfffffffe in ?? ()
Error: Failed to read memory at 0xfffffff8
Error: Failed to read memory at 0xfffff000
With holding reset same thing for me. Exactly same output.
That doesn’t look good – does the blinky example on its work when you upload it in regards to blinking the LED? Is uploading to the board still possible after debugging fails?
Hmm … it looks like this board includes the ST-Link v3, not the v2.1 on most other Nucleos.
Perhaps because the H745 is a dual-core chip, with both an M7+ and an M4 CPU?
I do have such a board (that same Nucleo, I think), but don’t have any experience with it.
Yes, the upload is still working, even if I get this output
debug_level: 1
srst_only separate srst_nogate srst_open_drain connect_deassert_srst
Error: stm32h7x.cpu1 – clearing lockup after double fault
Polling target stm32h7x.cpu1 failed, trying to reexamine
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08001030 msp: 0x24000700
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0xfffffffe msp: 0xfffffffc
** Programming Started **
Warn : Adding extra erase range, 0x08004020 … 0x0801ffff
** Programming Finished **
** Verify Started **
** Verified OK **
** Resetting Target **
Error: stm32h7x.cpu1 – clearing lockup after double fault
target halted due to debug-request, current mode: Handler HardFault
xPSR: 0x01000003 pc: 0xfffffffe msp: 0xffffffd8
Polling target stm32h7x.cpu1 failed, trying to reexamine
target halted due to debug-request, current mode: Thread
xPSR: 0x41000000 pc: 0x08000bfe psp: 0x24000870
shutdown command invoked
Yes it has the ST-Link v3 on board.
But does LED blink in accordance to the code?
Yes, the led behavior is the expected one.
Weird how when it halts the MCU then it says that it’s in a double (hard)fault, hm…
You could sanity-check that debugging works when using other frameworks. E.g., use the platform-ststm32/examples/cmsis-blink at develop · platformio/platform-ststm32 · GitHub project with the platformio.ini
[env:nucleo_h745zi_q]
platform = ststm32
board = nucleo_h745zi_q
framework = cmsis
upload_protocol = stlink
debug_tool = stlink
build_flags = -DSTM32H7 -DCORE_CM7
; counteracts a possible linkerscript bug for cmsis framework
board_upload.maximum_ram_size = 131072
I’m not sure what else besides BOOT0 and RESET configuration could hold this back from working – please open an issue in Issues · platformio/platform-ststm32 · GitHub to get help from the developers (and link to this thread) if it still doesn’t work.
Almost same story with CMSIS blinking project. Debug crashes with a SIGINT but upload seems not working. Now LED doesn’t blink anymore. The error message seem very similar btw.
Debug Output
Info : tcl server disabled
Info : telnet server disabled
Info : STLINK V3J2M1 (API v3) VID:PID 0483:374E
Info : Target voltage: 3.284800
Info : Unable to match requested speed 1800 kHz, using 1000 kHz
Info : Unable to match requested speed 1800 kHz, using 1000 kHz
Info : clock speed 1000 kHz
Info : stlink_dap_op_connect(connect)
Info : SWD DPIDR 0x6ba02477
Info : stm32h7x.cpu0: Cortex-M7 r1p1 processor detected
Info : stm32h7x.cpu0: target has 8 breakpoints, 4 watchpoints
Info : stm32h7x.cpu0: external reset detected
Info : stm32h7x.cpu1: Cortex-M4 r0p1 processor detected
Info : stm32h7x.cpu1: target has 6 breakpoints, 4 watchpoints
Info : stm32h7x.cpu1: external reset detected
Info : gdb port disabled
Info : starting gdb server for stm32h7x.cpu0 on pipe
Info : starting gdb server for stm32h7x.cpu1 on pipe
Info : accepting ‘gdb’ connection from pipe
Error: timed out while waiting for target halted
Error executing event gdb-attach on target stm32h7x.cpu0:
Error: Failed to read memory at 0x5c001000
Error: auto_probe failed
Error: Connect failed. Consider setting up a gdb-attach event for the target to prepare target for GDB connect, or use ‘gdb_memory_map disable’.
Error: attempted ‘gdb’ connection rejected
Info : accepting ‘gdb’ connection from pipe
Info : Halt timed out, wake up GDB.
Error: stm32h7x.cpu1 – clearing lockup after double fault
target halted due to debug-request, current mode: Handler HardFault
xPSR: 0x01000003 pc: 0xfffffffe msp: 0xffffffd8
Polling target stm32h7x.cpu1 failed, trying to reexamine
Info : stm32h7x.cpu1: Cortex-M4 r0p1 processor detected
Info : stm32h7x.cpu1: target has 6 breakpoints, 4 watchpoints
Info : Device: STM32H74x/75x
Error: Failed to read memory at 0x1ff1e882
Info : STM32H7 flash has dual banks
Info : Bank (2) size is 1024 kb, base address is 0x08000000
Info : Device: STM32H74x/75x
Error: Failed to read memory at 0x1ff1e882
Info : STM32H7 flash has dual banks
Info : Bank (3) size is 1024 kb, base address is 0x08100000
Info : New GDB Connection: 1, Target stm32h7x.cpu1, state: halted
Warn : negative acknowledgment, but no packet pending
Warn : negative acknowledgment, but no packet pending
Ignoring packet error, continuing…
warning: unrecognized item “timeout” in “qSupported” response
Warn : negative acknowledgment, but no packet pending
Warn : keep_alive() was not invoked in the 1000 ms timelimit. GDB alive packet not sent! (19017 ms). Workaround: increase “set remotetimeout” in GDB
target halted due to debug-request, current mode: Handler HardFault
xPSR: 0x61000003 pc: 0x08000328 msp: 0x2007ffb8
Error: Failed to read memory at 0x00000002
Error: Failed to read memory at 0xfffff000
0xfffffffe in ?? ()
Loading section .isr_vector, size 0x298 lma 0x8000000
Loading section .text, size 0x1c4 lma 0x8000298
Loading section .init_array, size 0x4 lma 0x800045c
Loading section .fini_array, size 0x4 lma 0x8000460
Start address 0x80002d8, load size 1124
Transfer rate: 7 KB/sec, 86 bytes/write.
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x080002d8 msp: 0x20080000
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x080002d8 msp: 0x20080000
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0xfffffffe msp: 0xfffffffc
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0xfffffffe msp: 0xfffffffc
Temporary breakpoint 1 at 0x80003c4: file src\main.c, line 106.
PlatformIO: Initialization completed
PlatformIO: Resume the execution to
debug_init_break = tbreak main
PlatformIO: More configuration options → Redirecting...
Error: stm32h7x.cpu1 – clearing lockup after double fault
stm32h7x.cpu1 – clearing lockup after double fault
Polling target stm32h7x.cpu1 failed, trying to reexamine
Info : stm32h7x.cpu1: Cortex-M4 r0p1 processor detected
Info : stm32h7x.cpu1: target has 6 breakpoints, 4 watchpoints
Program
received signal SIGINT, Interrupt.
Error: Failed to read memory at 0x00000002
Error: Failed to read memory at 0xfffff000
0xfffffffe in ?? ()
Error: Failed to read memory at 0xfffffff8
Error: Failed to read memory at 0xfffff000
Upload
debug_level: 1
srst_only separate srst_nogate srst_open_drain connect_deassert_srst
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x080002d8 msp: 0x20080000
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0xfffffffe msp: 0xfffffffc
** Programming Started **
Warn : Adding extra erase range, 0x08000460 … 0x0801ffff
** Programming Finished **
** Verify Started **
** Verified OK **
** Resetting Target **
Error: stm32h7x.cpu1 – clearing lockup after double fault
target halted due to debug-request, current mode: Handler HardFault
xPSR: 0x01000003 pc: 0xfffffffe msp: 0xffffffd8
Polling target stm32h7x.cpu1 failed, trying to reexamine
target halted due to debug-request, current mode: Handler HardFault
xPSR: 0x61000003 pc: 0x08000328 msp: 0x2007ffb8
shutdown command invoked
Is there a way to factory reset it using STM32CubeProgrammer ? Maybe trying to debug it using platformio caused a memory corruption due to wrong settings.
I have manual check registers with BOOT0=1, and set nothing strange. All write protection is off, PCROP-protection also. Looks all is fine with MCU.
Sorry, may be it not related observation, but a few more ingridients in our soup:
- BOOT=1, erase sector at 0x08000000
- BOOT=0, cold start, upload firmware, see “clearing lockup after double fault” on both cores. Led is on, not blink.
- Push reset button, led is blinking fine.
- Try to upload again, see “clearing lockup after double faul” just for cpu1, cpu0 is fine now. Upload ok, led is on, not blinking, so push reset. Led is blinking now.
- Flash again, upload ok, same situation.
- Turn power off. Then on, so cold start. Led is blinking.
- Try to upload firmware again. Now “Target examination failed”. STM32CubeProgrammer: “No STM32 Target found!”
- BOOT=1, erase 0 sector. Then power off, Boot=0, upload is ok now.
Thoughts:
- Some problems with OpenOCD + ST-Link V3. (I have upload st-link firmware to latest)
- Zephyr’s problem, some initialization during boot.
- STM32H745 specific problem, like Secure Boot and so on.
About debuging. I erase sector 0, when start debugging session after cold start and with Reset is pressed. Gdb is connected and I see register rc=0xfffffffe (is it ok for hardware failure?), and stack
??@0xfffffffe
<signal handler called>@0xfffffff9
??@0x00000000
After reset led is not blinking. But after upload this firmware after cold start I can connect to board from SMT32CubeProgrammes without any problems. I read memory and what can I see? Just 0xff in 0 sector. So debug firmware not flashed. And for my opinion it is start point.
Sorry for my language and begginer’s thoughts, last my assembler code was on CISC architecture on Intel 8088
“Target not found problem” actual only if connection mode in STM32CubeProgrammer is “Hot-plug”. In other modes where is no problems.
After some playing I can start debug session with OpenOCD from console w/o PlatformIO. Can pass continue
command and led starts blink. It is before power off.
Further investigation revealed after power reset in DBGMCU register bit D3DBGCKEN, D1DBGCKEN set to 0, so Domain 1 and Domain 3 debug clock is disabled. And related reference D3 power settings reset after power cycle. That why after power off and on I have “no link” and that why hot-plug connection is not working.
I think it is related to can’t start debug session. May be application must initialise D3 power / clock / DBG registers during initialization.
Now my head is off. I will test some initialization tomorrow.
Already post a lot of messages Just append.
I think I got it!
I have two not related problems, but topic starter just one.
-
Can’t start debug because can’t upload firmware. The reason is DBGMCU_CR register has 0x00000000 value after reset, and D1 + D3 domain’s debug is disabled. Just proper initialization resolve it.
-
Can’t start debug like @fisherman6v6 describe. The image flashed but we got hw failure.
We have two cores. On M7 we have uploaded fw and on M4 where is no fw, but core started by default. When PlatformIO starts debug session it starts OpenOCD with pipe mode by default. But we have two cores and OpenOCD put output from both cores in one pipe. So hw failure from M4 core, not from M7. M7 from this moment halted for gdb.
Resolve it simple: just put debug_port = localhost:3333
in env settings in platformio.ini for M7 core and localhost:3334
for M4 core. This disables pipe (debug/process/server.py
) and enable tcp server.
Now I starts debug, and see break at main() function. But when press F10/F11 system never break again. But it is another story.
Hi belolap,
Actually after setting debug_port = localhost:3333
in platformio.ini file the debug starts successfully.
However as you pointed, after the first breakpoint hit, if a continue or a step is given, no further debug can be done, since the program never breaks again.
Do you have any news on this topic?
Not yet. I think problems can be related with clocks not property configured specialy for domain D1 and D3. Now I carefully read reference manual and checks registers to understand that clocks and power supply configuration are good.
Hi belolap,
Would like to know if there is any follow up on this. Im quite stuck at exactly where you left it off.
Update, I have researched a bit. I got it to work. Debugger stopping in main() but not at my breakpont in setup() - #2 by manuelbl
In that thread they talk about a limited amount of breaking points. For now I can only make it work by adding:
debug_init_break = tbreak main ;you dont really need this
and start debugging… Thing is, I HAVE to clear the first break point (basically the only one) and set it elsewhere (wherever you wish to break next). It works… but quite annoying. Continue works but not the other commands such as “step into” or “out”, and eventually “return” doesn’t work either.
Meaning I have ONLY 1 break point to work with.
What I am saying is probably not entirely correct and there must be some reason and fix to this. In the thread they discuss 2-3 break points.
BR,
BCruz