0

I'm using STM32H745ZI Nucleo board with STLinkV3. I have successfully compiled and run simple program that flashes LEDs on Cortex M7 core. When program runs without debugger, everything's fine.

The problem appears while degugging. When I set breakpoint on line that turns the LED on, debugger stops in this place. The problem is that once stopped, continue and step over aren't working until the breakpoint is unset.

Code isn't much complicated:

while (1) {
  LD1_SET(1);
  HAL_Delay(100);
  LD2_SET(1);
  HAL_Delay(100);
  LD3_SET(1);
  HAL_Delay(100);

  LD1_SET(0);
  HAL_Delay(100);
  LD2_SET(0);
  HAL_Delay(100);
  LD3_SET(0);
  HAL_Delay(100);
}

This is how it looks like in gdb console:

# Setting breakpoint on LED ON
(gdb) b main.c:166
Breakpoint 1 at 0x8001788: file Src/main.c, line 166.
(gdb) c
Continuing.
Note: automatically using hardware breakpoints for read-only addresses.

# Hit! Debugger seems working, LED is still OFF   
Breakpoint 1, main () at Src/main.c:166
166     LD1_SET(1);
(gdb) c
Continuing.

# Hit the same breakpoint with no blinking between
Breakpoint 1, main () at Src/main.c:166
166     LD1_SET(1);

# Setting breakpoint on LED OFF
(gdb) b main.c:174
Breakpoint 2 at 0x80017c6: file Src/main.c, line 174.
(gdb) c
Continuing.

# Still hits LED ON, LED is still OFF
Breakpoint 1, main () at Src/main.c:166
166     LD1_SET(1);
(gdb) info b
Num     Type           Disp Enb Address    What
1       breakpoint     keep y   0x08001788 in main at Src/main.c:166
    breakpoint already hit 3 times
2       breakpoint     keep y   0x080017c6 in main at Src/main.c:174

# Removing breakpoint on LED ON
(gdb) del 1
(gdb) c
Continuing.

# LED is ON, prorgram finally hit next breakpoint
Breakpoint 2, main () at Src/main.c:174
174     LD1_SET(0);

How to make it work? Have you experienced similar problem before?

Konrad Sikorski
  • 399
  • 5
  • 11
  • delay is a problem – 0___________ Apr 18 '20 at 19:11
  • What do you mean @P__J__ ? If you meant "HAL_Delay" calls - it should not be a problem. The same problem happens no matter what line is after breakpoint. – Konrad Sikorski Apr 18 '20 at 20:02
  • when you examined the disassembly (not through gdb use objdump) what did you see at 0x8001788? and 0x080017c6, are you compiling for debug? with optimizations off? how was the library compiled? – old_timer Apr 21 '20 at 11:12
  • Did you ever figure out a cause for this? There was a bug in the M7 chip version < r0p2 that would cause this issue, but I am seeing this issue on a newer revision r1p1, but only using OpenOCD under LInux. STM32CubeIDE under windows works fine. – Eric May 11 '23 at 12:09

0 Answers0