cancel
Showing results for 
Search instead for 
Did you mean: 

STM32G0 hardfault and signal handler FFFFFFF1

Xme
Associate II

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:

 

Xme_0-1716273865159.png

 

Xme_2-1716274145362.png

 

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 */

 

 

 

1 ACCEPTED SOLUTION

Accepted Solutions
Xme
Associate II

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.

View solution in original post

7 REPLIES 7
Danish1
Lead II

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
Associate II

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

Xme_0-1716285594053.png

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 ?

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

Look at stack corruption.

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

Review stack depth

Clear auto/local variables 

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

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
Associate II

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.

Thanks for coming back with the solution.

This is indeed a nasty bug.

JW