Exception return value 0xffff fff9 on stack?

[Lars Beiderbecke]

When debugging start-up problems, I've found this stack in TrueSTUDIO:

 

According to the Programming Manual, an exception return value of 0xffff fff9 denotes "Return to Thread mode, exception return uses non-floating-point state from MSP and execution uses MSP after return.".

While I don't know what MSP refers to (m... stack pointer?), I'd be interested in which exception the MCU returned from.

Note that in all my error handlers, I have an infinite loop, so that they show up in the stack, and cannot be left except for interrupts.

void HardFault_Handler(void)
{
  volatile uint32_t cfsr  = SCB->CFSR;
  volatile uint32_t hfsr  = SCB->HFSR;
  volatile uint32_t mmfar = SCB->MMFAR;
  volatile uint32_t bfar  = SCB->BFAR;
 
  while (1);
}

So which handler could have been left here, if all handlers in stm32f7xx_it.c have infinite loops (with the exception of SysTick_Handler)?

[Pavel A. · Accepted solution]

In your stack trace you have NOT returned from the interrupt yet, you are still in the handler!

The exception is the EXTI interrupt. If the interrupts are nested, one handler can preempt another so the return context can be exception/interrupt as well.

Keep reading the field manual =)

-- pa

[Lars Beiderbecke]

That's an excellent idea! I did apply it to my code. Unfortunately, it didn't change anything in my stack. I still have main(), then 0xffff fff9, then EXTI1 handler. It's always EXTI1 handler on top.

I also tried optimization level -O1, but didn't see a handler on the stack. With -O0, my program doesn't compile because of inline functions not being inlined.

Could this be something entirely different? My code uses EXTI0 and EXTI1 interrupts, both of prio 0, and EXTI1 disables EXTI0 by first clearing its pending bit (and re-enabling it later). Would that cause 0xffff fff9 being put on the stack? This happens a thousand times per second, but I guess I only see the 0xffff fff9 on the stack if I break just in the right moment?

[TDK]

I think you're missing what Pavel A is saying. You are in the interrupt handler (EXTI1_IRQHandler), and you got there from the interrupt being triggered while in main(). This is how that scenario shows up in the stack trace.

MSP = main stack pointer.

[Lars Beiderbecke]

Oh I see. So the 0xffff fff9 is perfectly normal when entering an IR handler.

I think I remember this, but right now I'm pulling at straws. So thanks, and never mind.