2024-05-20 11:58 PM - edited 2024-05-21 02:19 AM
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 */
Solved! Go to Solution.
2024-06-03 10:08 PM
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.
2024-05-21 02:07 AM
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. |
0xFFFFFF9 | Return to Thread mode. |
0xFFFFFFD | Return to Thread mode. |
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.
2024-05-21 03:05 AM - edited 2024-05-21 03:22 AM
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.
2024-05-21 03:33 AM - edited 2024-05-21 03:33 AM
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
2024-05-21 03:57 AM
Look at stack corruption.
Focus more of the location of the fault, the registers and the code.
Review stack depth
Clear auto/local variables
2024-05-21 04:51 AM - edited 2024-05-21 04:52 AM
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.
2024-06-03 10:08 PM
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.
2024-06-04 12:14 AM
Thanks for coming back with the solution.
This is indeed a nasty bug.
JW