Reset when adding or removing breakpoints

[SKled.1]

I have a STM32L072 and when last I worked on the project, from what I rmember, there were no debugging issues at all.

When I started to work at it again now, I see this effect that, when, in STM32CubeIDE, using a STLINK V3SET debugger, I am in a debugging session, the program is running, when I remove or add a breakpoint, in a part of the code currently not being run, the MCU resets.

Now, one of the later things added was a watchdog (WWDG), so I'd expect to have the WWDG do a reset when breaking. But not just for adding breakpoints in currently inactive code? Or is this normal and I just don't remember?

Now, in the debug settings of CubeIDE, I set the option "Suspend watchdog counters while halted" to ENABLE.

I also already had this line in the watchdog config code:

DBGMCU->APB1FZ |= DBGMCU_APB1_FZ_DBG_WWDG_STOP;

The behavior is still there...

If this is not normal, what could cause it?

Edit:

It also seems the case that, only when the debugger is connected, I reset the device by writing to it via I2C (the MCU acting as slace), while writing and reading back from the same of my implemented I2C registers works correctly when the debugger is not attached, but the binary version is still the debug version.

[TDK]

No such issues here.

Read the values in RCC->CSR to determine the cause of the reset.

[SKled.1]

Ah, thanks, of course. I already dump that info on the serial console - could it be that the causes for reset are not cleared until the next power cycle? I saw WWDG as cause even when manually reset. After power cycle, I only saw:

 (26) PINRSTF

 (27) PORRSTF

But I might just be confused, I'll look at it more deeply tomorrow 😉

[TDK]

You need to set RMVF to clear the flags after reading them.

[SKled.1]

When resetting due to debugger, I get reset flags: PIN, SFT.

When setting any breakpoint in a piece of code that's not active (e.g. some system init routine), it resets, and the reset flags are: PIN, WWDG.

If I comment out the line that enables the watchdog, this behavior is not there.

Btw., there are no active breakpoints when I try this, so no failed attempt of installing one or such.

Does adding a breakpoint in the running system cause some lag that may impact a watchdog that's running close to the timeout? Although it would seem curious that this reliably happens. The program does not have a perfectly constant time main loop, there are a few conditionals that sometimes kick in, such that I get this:

MainLoopInterval histogram (ms : count)
  1	: 2472088
  2	: 267
  8	: 1

I.e. most loops take <= 1ms, some <=2ms, even one with 8ms (or just barely over 4, for that bin), which did not trigger the watchdog, and IIRC I set to the max possible value. So unless installing a breakpoint causes a system lag of longer than that, this doesn't look like a plausible cause...

[TDK]

> When resetting due to debugger, I get reset flags: PIN, SFT.

Okay, sounds as expected.

> When setting any breakpoint in a piece of code that's not active (e.g. some system init routine), it resets, and the reset flags are: PIN, WWDG.

Okay, so the WWDG is indeed resetting it.

Set the watchdog to be stopped during debug via the DBG_WWDG_STOP bit.

> Does adding a breakpoint in the running system cause some lag that may impact a watchdog that's running close to the timeout?

Sure sounds like it. You could toggle a pin in a tight loop and verify. It certainly needs to communicate with the core to set up a hardware breakpoint. I'm a little surprised that it would take more than a few ms, but seems possible.

[SKled.1]

That's the thing - this flag already is on, as this is in my watchdog init:

DBGMCU->APB1FZ |= DBGMCU_APB1_FZ_DBG_WWDG_STOP; // Make Watchdog stop when debugger halt!
RCC->APB1ENR |= RCC_APB1ENR_WWDGEN; // Enable the clock for the thing, before giving it commands

 I'll look at what adding a breakpoint does to a toggled pin on the scope. Edit: ah well, on this board this can take me a while to set that up, it's not a devboard with a bunch of nice exposed extra pins, but the program won't run as is on a devboard.

[TDK]

> You could toggle a pin in a tight loop and verify.

I did this. On an F429, setting a hardware breakpoint while the program is running halts the CPU for 110ms. Certainly explains the issue. Likely setting DBG_WWDG_STOP would prevent the WWDG from resetting here.

[SKled.1]

Whoa! Thanks. I wouldn't have guessed it's that much.

But DBG_WWDG_STOP is already set when configuring, it always was, from the beginning.

I searched in the project for all places where DBGMCU->APB1FZ is accessed, there is only that one place, so it's not accidentally erased again anywhere or something.

I also found that CubeIDE has a setting for debug configuration, in the Debugger tab, Device settings, "Suspend wachdog counters while halted", that sounds like it is that. It was on "Disabled" in the beginning, so maybe it overwrites this setting... I set it to Enabled, that didn't change anything.

I'm also wondering why writing to the MCU as a I2C slave addressee (generating an interrupt), it resets the MCU - when the debugger is connected but CubeIDE shows no active breakpoints. Writing I2C works fine when no debugger is connected.