During initialization FreeRTOS setups a single stack frame in the task
control block for the respective task to be started. This initial stack
frame contains the address of the function for the task, and the other
relevant register values that will need to be restored to the CPU during
that first context switch. The portRESTORE_CONTEXT() will pull all those
register values off the respective stack int the user-mode registers and
start running the task (in theory).
We have seen issues where the crt.s does not leave the CPU in the correct
CPU mode and it fails to restore context correctly. We've also seen cases
where disabling thumb interworking breaks it. We've also seen cases where
omitting the -fomit-frame-pointers during compilation breaks it...
Has anything changed in the makefiles, compiler flags, crt.s etc?
On Mon, Jul 19, 2010 at 9:36 PM, Daniel Ferguson <
> I'm stuck.
> vTaskStartScheduler() calls
> vPortISRStartFirstTask() which then calls
> Since portRESTORE_CONTEXT() is a macro that does some tail wagging that I
> haven't dug into,
> all I can say is it resets the chip.
> Has anyone seen this before?
> FreeRTOS 5.1.2
> GDB 6.6
> gcc 4.2.1
> psas-avionics mailing list
psas-avionics mailing list