xPortPendSVHandler 中 FreeRTOS 中的硬故障

Question

I have a hard fault occurring in my FreeRTOS application running on ATSAME54 (ARM Cortex-M4).

I am only using statically allocated memory. The hard fault occurs when I am sending CAN messages to it at a very high rate. I need to run it for a couple of seconds up to one minute.

The type of hard fault is a precise BusFault error ( CFSR.PRECISERR and CFSR.BFARVALID bits set), with a BFAR of 5a5a5a5a .

I decoded the stack frame using the code from https://www.freertos.org/Debugging-Hard-Faults-On-Cortex-M-Microcontrollers.html .

This gives:

r0  = 200030e8   <= part of a task stack
r1  = 200030a4
r2  = 5a5a5a5a   <= same as BFAR
r3  = 20003934
r12 = 2000317c   <= pxCurrentTCB
lr  = a5a5a5a5   <= ????? could this be the reason?
pc  = 00000955   <= in the middle of xPortPendSVHandler
psr = 00000960

Following the memory task stack r0 points to, the FreeRTOS memory starts. I have put a memory barrier in between the two as one of my tests, but this stays untouched, so if there is corruption of the stack it is not by something writing from the FreeRTOS memory into my task stack.

The 5a5a5a5a value happens to be the integrity check value that FreeRTOS adds to its structures. The a5a5a5a5 is the normal fill value for stack memory.

What more can I try to find out what is causing this?

Answer 1

In the end, I could not find the issue. I resorted to removing the FreeRTOS altogether and replace it by some bare metal code. This worked flawlessly. This is, however, not a satisfying solution route, and is also not a general solution in case of issues with FreeRTOS.f

During my research, I found that ARM program code should be word-aligned or half-word aligned (16-bit or 32-bit wide instructions), so 0x955 is a strange value for a program counter. It is also remarkably close to the value of the PSR so this makes me wonder whether the stack decoding happened correctly and whether the PC at the time of the hard fault was not actually pointing elsewhere.

Answer 2

xPortPendSVHandler is FreeRTOS 's context switcher. If a bus fault happens in there you may have a corrupted process stack pointer as a result of a corrupted task control block in SRAM, besides the corrupted stack frame. You may want to use a static analyzer to check the code for common bugs like NULL-pointer de-references, array index out-of-bounds and such. In addition, the fact that it only happens when sending messages at a high rate makes it look like a racing related problem.