[stm32h743]: Breakpoints only start working about two seconds after reset

[arbrauns]

This is a report of the same symptoms as #1059, but that issue was deemed to be fixed and thus locked almost a year ago.

• [x] Programmer/board type: ST-LINK/V2.1
• [x] Operating system an version: Arch Linux
• [x] stlink tools version and/or git commit hash: e97f438
• [x] stlink commandline tool name: st-util
• [x] Target chip (and board, if applicable): STM32H743XIH

Commandline output:

st-util

st-util 1.7.0-123-ge97f438
2021-11-10T16:42:39 WARN common.c: NRST is not connected
---------- old ------------
# Chip-ID file for H74x/H75x
#
chip_id 0x450
description H74x/H75x
flash_type  10
flash_size_reg 0x1ff1e880
flash_pagesize 0x20000
sram_size 0x20000
bootrom_base 0x1ff00000
bootrom_size 0x20000
option_base 0x5200201c
option_size 0x2c
flags 3

---------- new ------------
# Chip-ID file for H74x/H75x
#
chip_id 0x450
description H74x/H75x
flash_type  10
flash_size_reg 0x0
flash_pagesize 0x20000
sram_size 0x20000
bootrom_base 0x1ff00000
bootrom_size 0x20000
option_base 0x5200201c
option_size 0x2c
flags 13

2021-11-10T16:42:39 INFO common.c: H74x/H75x: 128 KiB SRAM, 41854 KiB flash in at least 128 KiB pages.
2021-11-10T16:42:39 INFO gdb-server.c: Listening at *:4242...
2021-11-10T16:42:43 WARN common.c: NRST is not connected
---------- old ------------
# Chip-ID file for H74x/H75x
#
chip_id 0x450
description H74x/H75x
flash_type  10
flash_size_reg 0x1ff1e880
flash_pagesize 0x20000
sram_size 0x20000
bootrom_base 0x1ff00000
bootrom_size 0x20000
option_base 0x5200201c
option_size 0x2c
flags 3

---------- new ------------
# Chip-ID file for H74x/H75x
#
chip_id 0x450
description H74x/H75x
flash_type  10
flash_size_reg 0x0
flash_pagesize 0x20000
sram_size 0x20000
bootrom_base 0x1ff00000
bootrom_size 0x20000
option_base 0x5200201c
option_size 0x2c
flags 13

2021-11-10T16:42:43 INFO common.c: H74x/H75x: 128 KiB SRAM, 41854 KiB flash in at least 128 KiB pages.
2021-11-10T16:42:43 INFO gdb-server.c: Found 8 hw breakpoint registers
2021-11-10T16:42:43 INFO gdb-server.c: Chip clidr: 09000003, I-Cache: off, D-Cache: off
2021-11-10T16:42:43 INFO gdb-server.c:  cache: LoUU: 1, LoC: 1, LoUIS: 0
2021-11-10T16:42:43 INFO gdb-server.c:  cache: ctr: 8303c003, DminLine: 32 bytes, IminLine: 32 bytes
2021-11-10T16:42:43 INFO gdb-server.c: D-Cache L0: 2021-11-10T16:42:43 INFO gdb-server.c: f00fe019 LineSize: 8, ways: 4, sets: 128 (width: 12)
2021-11-10T16:42:43 INFO gdb-server.c: I-Cache L0: 2021-11-10T16:42:43 INFO gdb-server.c: f01fe009 LineSize: 8, ways: 2, sets: 256 (width: 13)
2021-11-10T16:42:43 INFO gdb-server.c: GDB connected.
2021-11-10T16:42:43 WARN common.c: NRST is not connected
2021-11-10T16:42:43 INFO gdb-server.c: Found 8 hw breakpoint registers
2021-11-10T16:42:53 WARN common.c: NRST is not connected
2021-11-10T16:42:53 INFO gdb-server.c: Found 8 hw breakpoint registers
2021-11-10T16:43:06 ERROR gdb-server.c: cannot recv: -2
2021-11-10T16:43:06 INFO gdb-server.c: Listening at *:4242...
^CReceive signal 2. Exiting...

I used the same approach as in https://github.com/stlink-org/stlink/issues/1059#issuecomment-719432499, setting a breakpoint in a busy loop that increments a counter:

uint32_t counter = 0;
while (1) {
    HAL_Delay(10);
    counter++;
}

gdb output:

(gdb) b main.c:52
Breakpoint 1 at 0x805a9a2: file [redacted]/main.c, line 52.
Note: automatically using hardware breakpoints for read-only addresses.
(gdb) r
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: [redacted].elf

Breakpoint 1, main () at [redacted]/main.c:52
52		  counter++;
(gdb) p counter
$1 = 180

As can be seen, the loop runs for 180 * 10ms = 1.8s before the breakpoint triggers for the first time.

Expected/description:

The breakpoint triggers the first time the address is encountered, even if it's the very first instruction.

[2old4it]

I have the same issue. Need to debug an issue at the beginning of my code but that break point never gets hit. If I set a break point somewhere that is called regularly the break point hits after some time (didn't time it) Is there a work-around for this? I need to solve my bug yesterday :-(

• host is Linux Manjaro
• st-util --version = 1.7.0
• target device = STM32L4S9

I have attached two files with debug output from st-util -v 99 First file initial_output_st-util.txt is the output from starting st-util until the break point is hit (did 'run' in gdb) Second file output_st-util_after_continue.txt is the output after the 'continue' command in gdb until the break point hits again. I hope these are helpful initial_output_st-util.txt output_st-util_after_conitnue.txt .