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

[Thoufiel]

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?

[Tesla DeLorean]

Invalid SP is going to cause near immediate failure, and going to make very difficult to pin point. Might need to have checkpoint values or output character stream to review dynamic flow.

SP most likely to break at content change for RTOS or Handler return.

Errant DMA can trash whole environment and can't be breakpointed. Always range check the configuration on memory writes.

[Tesla DeLorean]

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