STM32G0 hardfault and signal handler FFFFFFF1

[Xme]

I'm trying to find the cause of a hard fault in my code. The problem repeatedly appears after a few or more minutes after starting the  code, sometimes not at all, sometimes every time at close startup after enabling interrupts, and somethimes after a few seconds, as if it were dependent on the compilation. Somethimes watchdog re-runs code.

CubeIDE, STM32G0

I tried debugger IDE and here apears something like this:

 

 

 

What does mean signal handler FFFFFFF1 and FFFFFF9 ? Maybe it helps me to find the problem.

I dont use freertos, I dont use dynamic memory allocations. Only interrupts with 4 priority levels

_Min_Heap_Size = 0x1000 ; /* required amount of heap */
_Min_Stack_Size = 0x2000 ; /* required amount of stack */

 

 

 

[Danish1]

Have a look at the Programming manual for your stm32 to find out about the 0xfffffff1 type of LR values.

In the section"Exception entry and return" it tells you that a special value with bits[31:4] 0xfffffff indicates a return from exception which involves things like changing processor-mode and using a different stack pointer.

 

Exception return

Exception return occurs when the processor is in Handler mode and execution of one of the following instructions attempts to set the PC to an EXC_RETURN value:

• A POP instruction that loads the PC.

• B PBX instruction using any register.

  The processor saves an EXC_RETURN value to the LR on exception entry. The exception mechanism relies on this value to detect when the processor has completed an exception handler. Bits[31:4] of an EXC_RETURN value are 0xFFFFFFF. When the processor loads a value matching this pattern to the PC it detects that the operation is a not a normal branch operation and, instead, that the exception is complete. As a result, it starts the exception return sequence. Bits[3:0] of the EXC_RETURN value indicate the required return stack and processor mode, as Table 13 on page 32 shows.

  Table 13. Exception return behavior

EXC_RETURN	Description
0xFFFFFF1	Return to Handler mode. Exception return gets state from the main stack. Execution uses MSP after return.
0xFFFFFF9	Return to Thread mode. Exception return gets state from MSP. Execution uses MSP after return.
0xFFFFFFD	Return to Thread mode. Exception return gets state from PSP. Execution uses PSP after return.
All other values	Reserved.

 

My suspicion is that your USB_GetUSBConnection() wants to know the state of a pin, calling LL_GPIO_IsInputPinSet, but the pin definition is bad, not yet set up, or corrupt.

[Xme]

Thanks.

After recompile i get hardfault each time after 5 seconds program starts. But is is in debug mode. 

This time i get 0xFFFFFF9 only

And here there is no pin access, only to variables.

When I compile release version program gos into hard fault handler almost after enable interrupts.

Very suspicious is interrupt handler, when I use 3 different usart interrupt handlers.

void USART3_4_5_6_LPUART1_IRQHandler(void)

{

  /* USER CODE BEGIN USART3_4_5_6_LPUART1_IRQn 0 */

My_Dev1_USART_IRQHandler();

My_Dev2_USART_IRQHandler();

My_Dev3_USART_IRQHandler();

}

 

Now I have no idea what it is going on. After some compilations, and removing some not important code - it works without crash.

 

I am using global __enabe_irq()  and __disable_irq() in my code. Can it be a problem ?

[waclawek.jan]

If failures are seemingly random, chances are (read, it's not a certainty) that you have a hardware problem - unstable power supply, problematic external clock, incorrectly set latency, excessive external noise/interference on GPIO pins, etc.

JW

[Tesla DeLorean]

Look at stack corruption.

Focus more of the location of the fault, the registers and the code.

Review stack depth

Clear auto/local variables 

[Xme]

very strange

Inlcuding modules (that are not even called at all - I moved calls to them to section that are used only in special configuration) generates that hardfault after 5 seconds after startup.

When theese modules are excluded from compilled code, everything works ok.

 

It looks like a software problem. But stack trace when hardfault occures is useless.

[Xme]

Problem of hardfault solved. There is a bug in the silicon of the processor, making it necessary to disable prefetch for code above 256kBytes. As a result, depending on the compilation and layout of the code, it sometimes worked and sometimes didn't.

[waclawek.jan]

Thanks for coming back with the solution.

This is indeed a nasty bug.

JW

[ebMuseKinetics]

We lost 2 months to this bug, stripped everything down to the frame and built it up but couldn't stop these hard faults until we disabled prefetching. Once we knew this was the issue, it became much easier to identify the hard fault by confirming in the stack trace that functions across bank pages were calling/returning. 

[waclawek.jan]

I presume, both @Xme and @ebMuseKinetics talks about the STM32G0B1/C1/B0 and its Prefetch failure when branching across flash memory banks erratum. Can you please confirm.

User @berendi  asked a couple of related questions about this issue in a different thread. Can ST please comment.

JW