Data breakpoint (watchpoint) triggers too late (STMCubeIDE1.5.0 / Segger Jlink/STM32F745Z)

[Peeters.Bram]

Hi,

I was hitting a memory corruption problem and wanted to find where the memory was being overwritten by using a data breakpoint (or watchpoint in stm32cubeide terminology).

But for some reason the breakpoint is only triggered much later than were the actual writing happens.

In the attached screenshot, the watchpoint was hit at 0x0808352e, which is a totally innocent cpm r3,#0.

While the actual overwriting (I found this by going back to the stone age approach an single stepping asm intructions till i found it) happens at 0x0808352f which is a str r5, [r4,#8].

(the corruptions is caused by a stack overflow)

I placed the watchpoint by right clicking on the address in the memory viewer, add watchpoint. Range = 4, write and enable are checked, no condition and ignore count is 0

I am using stm32cubeide 1.5.0 and a segger jlink debugger on a STM32F745.

It is 100% reproducible.

Are data breakpoints/watchpoints suppose to work or is this a work in progress ?

(In the past I used IAR on with STM32F4's with segger jlink debuggers and I never had problems with data breakpoints.)

Regards

Bram

[mattias norlander]

Hi,

We can re-produce this issue. We dont know why. This is probably a question best answered by SEGGER. Or at least this is what we believe right now.

We did some tests

• Re-produced with SEGGER
• Re-produced with ST-LINK running ST-LINK GDB-server in non-stop debug mode
• NOT re-produced with ST-LINK running ST-LINK GDB-server without non-stop debug mode
• NOT re-produced with ST-LINK running OpenOCD

So our best guess is that this is an issue in the GDB client / server communication when using SEGGER or ST-LINK GDB-server in non-stop mode.

As you said it worked SEGGER + IAR. I assume that IAR does not use GDB to interact with the SEGGER. So it is quite possible that SEGGER could have different behavior with IAR.

We will ask SEGGER if they are aware of this issue, and if they have a solution. For ST-LINK GDB server, for now we just recommend turning off non-stop debug mode (disables Live expression) which has some limitations.