davedoors wrote on Wednesday, March 30, 2011:
as the scheduler starts I am just falling through to:
DEFAULT_ISR_HANDLER HardFaultException
Is xTaskStartScheduler() returning? If so you are running out of heap when the idle task is being created. If xTaskStartScheduler() is not returning, step through the code to find where the exception is happening. If you can’t do that then you can inspect the stack in the exception handler to find the PC value when the exception happened, but that is fiddly.
If xTaskStartScheduler() is not returning, does the first task ever start?
xLEDSemaphore = xSemaphoreCreateMutex();
if (xLEDSemaphore == NULL)
i = 6;
However, it does not drop to the i = 6 line.
But it is returning from xSemaphoreCreateMutex()?
don’t have stack overflow checking, no. Do I understand correctly that each task would need to do its own checking? If I did switch this on I would still need to use uxTaskGetStackHighWaterMark in each task?
Overflow trapping will only work during a context switch, so when the scheduler is running. It might not help then if you have a problem starting the scheduler.
http://www.freertos.org/Stacks-and-stack-overflow-checking.html
If I understand correctly, the tasks have their own stacks and anything else is done from the heap. So, if you have an initialisation routine that is called once and never again, that would use the heap? As an aside, Is it bad practice to do the latter? Should all initialisations be done in the task itself before the infinite loop is reached?
main() uses the stack from the linker script. Tasks have stacks allocated from the heap. Semaphores are allocated from the heap.
Are you using heap_1.c or heap_2.c, or a different heap manager? If you are using heap_1.c or heap_2.c then the heap is statically allocated so the linker should take care of it. If you are using something else then it could be that the heap is being overflowed, or a linker script problem.