FreeRTOS - Stack corruption on STM32F4

Question

I am currently having problems with what I think is stack corruption of some error of configuration while running FreeRTOS on an STM32F407 target.

I have looked at FreeRTOS stack corruption on STM32F4 with gcc but got no help there.

The application runs two tasks and relies on one CAN interrupt. The workflow is as follows:

1. The two tasks, network_task and app_task is created along with two queues, raw_msg_queue and app_msg_queue. The CAN interrupt is also set up.
2. The network_task has the highest priority and starts waiting on the raw_msg_queue, indefinitely.
3. The app_task is next and starts waiting on the app_msg_queue.
4. The CAN interrupt then triggers because of an external event, adding a CAN message to the raw_msg_queue.
5. The network_task wakes up, process the message, adds the processed message to the app_msg_queue and then continues to wait on the raw_msg_queue.
6. The app_task wakes up and I get a hard fault.

The thing is that I have wrapped the calls that app_task makes to xQueueReceive in two steps because of end-user convenience and portability. The app_task total function chain is that it calls network_receive(..) -> os_queue_receive(..) -> xQueueReceive(..). This works well, but when it returns from xQueueReceive(..) it only manages to return to os_queue_receive(..) before it returns to a seemingly random memory location and i get a hard-fault.

The stack sizes should be adequate and are set to 2048 for both, all large data structures are passed around as pointers.

I am running my code on two STM32F407. FreeRTOS is at version 7.4.2, the latest at the time of writing.

I am really hoping that someone can help me out here!

Answer 1

First, you can take a look here and try to get more info about the hard fault. You may also want to check your interrupt priority setting, as the tricky ARM Cortex-M interrupt priority mechanism causes some trouble in FreeRTOS. Refer to here.

Answer 2

I know this question is rather old, but perhaps this could help other people out facing a similar issue. In FreeRTOS, you can utilize the

void vApplicationStackOverflowHook(xTaskHandle xTask, signed char *pcTaskName)

function to detect a stack overflow and grab relevent information about the offending task. It's possible that data would be corrupt due to the overflow, but you can atleast address the fact that an overflow occured (reset system, set error flag/LED, etc.)

For this specific question, I'd be curious to see the thread initialization code as well as the interrupt routine. If the problem is in fact an overflow, I think it would be fairly simply to adjust these parameters until the problem goes away. You mention 2048 bytes should be sufficient for each thread - if that's truly the case, I doubt the problem is an overflow. At that point, it's more likely you're dereferencing a dangling pointer to a stale memory address.