cancel
Showing results for 
Search instead for 
Did you mean: 

HardFault by stack overflow(maybe) but not break in HardFault_Handler()

Thoufiel
Associate III

I am using the STM32H562VGT6 and IAR Workbench.

I have set up a 4kHz interrupt with LPTIM3 and started transmitting 32 bytes of data using HAL_SPI_Transmit_DMA.

If I break and resume execution after starting the timer interrupt, the SP becomes 0xffff ffd8, causing a HardFault error.  The call stack only contains (Exception frame), making it untraceable. The stack area is from 0x2000'0f90 to 0x2000'4f8f.

Although HardFault_Handler() is defined in stm32h5xx_it.c, breaking there does not hit during a HardFault.
Breaking in MemManage_Handler or BusFault_Handler also does not hit.

Commenting out HAL_SPI_Transmit_DMA during the 4kHz interrupt prevents the HardFault, but adding macros to check if the SP is out of range within the HAL API does not trigger any response.

#define CHECK_MSP() {\
uint32_t msp; \
__asm volatile ("MRS %0, msp" : "=r" (msp)); \
if (msp < 0x20000f80 || 0x20004f7f < msp) { \
__BKPT(0); \
} \
}


How can I capture the cause of this issue?

20 REPLIES 20

This is one of the situations where HW Trace would be very helpful.

Poor-man's trace can be done with a ring-buffer, with a function you call that adds LR and perhaps a sequence number to the ring, and strategically add a call to those functions that you know are in the immediate execution path of the observed failure.

That and stack-dump what you can see currently.

Get both PSP/MSP initialized

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..