FreeRTOS, debugging hardfault when HardFault_Handler breakpoint is never triggered?

[NNagy.1]

I'm looking at the "Debugging and diagnosing hard faults" on FreeRTOS' website (https://www.freertos.org/Debugging-Hard-Faults-On-Cortex-M-Microcontrollers.html), and I populated my HardFault_Handler() function and defined prvGetRegistersFromStack(). And I set a breakpoint in HardFault_Handler().

However, I cannot get the program to land in either of these functions while debugging. Instead I just get stuck in the infinite loop in the default handler.

Would moving the code from HardFault_Hanlder() into the default handler still give me what I need? ie,

Default_Handler:
  tst lr, #4
  ite eq
  mrseq r0, msp
  mrsne r0, psp
  ldr r1, [r0, #24]
  b  Infinite_Loop
  .size  Default_Handler, .-Default_Handler
 
.align 4

And if not, how can I get around this?

#RTOS​ #HardFault​ #DEBUG​ 

[TDK]

Related:

https://community.st.com/s/question/0D53W00001EfyBUSAZ/freertos-how-to-give-adc-and-dac-dma-buffers-to-task

If it's going to Default_Handler on a hard fault instead of HardFault_Handler, it means HardFault_Handler is not defined correctly or being linked correctly.

But yes, the data you get in HardFault_Handler if it goes there is identical to what you'd see in Default_Handler if it went there instead.

As I suggested in the other post, look at SCB registers to determine the cause of the fault.

[NNagy.1]

I've changed the code a few times since that thread, but currently SCB->INVSTATE is set.

"When this bit is set, the PC value stacked for the exception return points to the instruction that attempted the illegal use of the ESPR"

What exactly is meant by "the PC value stacked for the exception return". Stacked where? The LR register?

I'm still confused by the register values (this is at the infinite loop). I don't really trust the pc noting WWDG_IRQHandler because VECTACTIVE still stores 0x3.

I also can't use lr to see where the program crashed since it's just showing 0xffffffe1. I'm confused which register to look at to figure out where the fault was generated. And as I mentioned in the other thread, the call stack doesn't go back far enough for me to see where the fault happened.