vTaskDelay cause HardFault_Handler

matita87 wrote on Tuesday, August 01, 2017:

Hi
My application run on stm32F4 with FreeRTOS V9.0.0 and port files Source\portable\RVDS\ARM_CM4F (imported via RTE Keil).
The main, call some initialization functions, then create the task and then call the vTaskStartScheduler.
The task simply call vTaskDelay(1000) which never return (causing the HardFault_Handler).
The code is:
int main(void)
{
init_foo1()
init_foo2()
xTaskCreate(aTask, “name”,1280, NULL, 6, NULL);
init_foo3();
vTaskStartScheduler();
}
void aTask()
{
vTaskDelay(1000);//At this time I have 2 task: this taks and the task Scheduler.
bar();//never go here, becaouse a HardFault_Handler appears before.
}
This problem appears almost always.
Note: if I remove all the function before the task creation the vTaskDelay works correctly.
What is wrong?
Could be a problem related to the main “corrupted” (stack pointer)?
If yes, how can I solve it?
Thanks all
m

rtel wrote on Wednesday, August 02, 2017:

What is wrong?

Impossible to say from the information provided, but here are some pointers to help you debug:

  1. Step through the code to see where the hard fault happens. If it is hard to find because it is occuring in an interrupt (or some place other than where you are stepping) then try this technique: Debugging and diagnosing hard faults on ARM Cortex-M CPUs
  2. Did you check xTaskCreate() returned pass?
  3. How do you know bar() never gets executed? Could it be executed without you knowing? Your task should either be in an infinite loop so it doesn’t return or call vTaskDelete() before it exits. If bar does execute and return then the task will run off the end and crash. Writing RTOS tasks in FreeRTOS - implementing tasks as forever loops
  4. Do you have configASSERT() defined? FreeRTOS - The Free RTOS configuration constants and configuration options - FREE Open Source RTOS for small real time embedded systems
  5. It looks like you have enough stack, but just for good measure: FreeRTOS - stacks and stack overflow checking
  6. Are there any interrupts executing? If so, are the priorities set correctly: RTOS for ARM Cortex-M