Why am I getting a hard fault when adding a breakpoint in the IDE while the device is in stop mode

[Tom MacDonald]

Scenario is that I am debugging my application using ST-Link V2.

The device enters stop mode (with debugging still enabled). If I then add a breakpoint while the device is in stop mode, I immediately trigger a hard fault ISR.

This is new behaviour that seems to have only began happening recently with this project.

I therefore suspect it is either from some change in my app or from some change in Cube HAL drivers or IDE's debug layer after updating to STM32CubeIDE_v1.11.0

Below is a screenshot showing the recovered stack frame, and the assembly code and debug console output when the hard fault happens.

I am using STM32G030F6

 

[dagan]

Hi,
Any update here?
I'm having the same issue on WB55, running using visualGDB 5.6R9 on visual studio.
I've also noticed that adding the following ASSERT definition causes this to happen every time I try to "Break All" (pause) with the debugger:

#define configASSERT( x ) if ((x) == 0) {__asm volatile("BKPT #01"); taskDISABLE_INTERRUPTS(); for( ;; );}

I'm using SEGGER J-LINK.

[Andrew Neil]

Have you got a HardFault handler, and have you looked at the info that provides?

Perhaps you've disabled clocks that the debugger needs ... ?

[Pavel A.]

This is likely because the breakpoints are implemented in the flash subsystem of the MCU. In stop mode most of the MCU's guts are not responding. Perhaps a J-Link with its "unlimited breakpoints" feature could help here.

[dagan]

Adding more details:

When the configASSERT is define as a breakpoint

#define configASSERT( x ) if ((x) == 0) {__asm volatile("BKPT #01"); taskDISABLE_INTERRUPTS(); for( ;; );}

and I "Break All", the PC is inside the HAL_PWREx_EnterSTOP1Mode function, in the instruction

/* Request Wait For Interrupt */
__WFI();

When I press "Continue" I'm getting:

Received a SIGTRAP: Trace/breakpoint trap

[dagan]

When removing the configASSERT definition, "Break-All" while in STOP1 and then "Step Over" few times, I'm getting the hard fault
the LR is pointer to the first instruction of HAL_PWREx_EnterSTOP0Mode(STOPEntry):

HAL_PWREx_EnterSTOP0Mode(STOPEntry);
0x0804b0f8 FB 78 ldrb r3, [r7, #3]
0x0804b0fa 18 46 mov r0, r3
0x0804b0fc 00 F0 FC F8 bl 0x804b2f8 <HAL_PWREx_EnterSTOP0Mode>
0x0804b100 00 BF nop
0x0804b102 10 37 adds r7, #16
0x0804b104 BD 46 mov sp, r7
0x0804b106 80 BD pop {r7, pc}

The PSR = 0x01000200

When disabling the DBG_STOP bit in the DBGMCU_CR, no hard fault occured...
However, every "Break-all" command is causing the MCU to step out of the STOP1 mode.

[Pavel A.]

@dagan the SIGTRAP looks like a debug exception, quite expected when debugging. But the debugger gets confused and fails.You're using 3rd party tools: VisualGDB debugger and J-Link. Have you tried to reach their support? 

[Andrew Neil]

---

@Pavel A. wrote:

 looks like a debug exception ...using 3rd party tools: VisualGDB debugger and J-Link 

---

J-Link has been known to do some "clever" stuff with debug exceptions ...