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 < danieljayfergu...@gmail.com> wrote: > Hello; > > I'm stuck. > > vTaskStartScheduler() calls > vPortISRStartFirstTask() which then calls > portRESTORE_CONTEXT() > > 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 > > ~DanielF > > > > _______________________________________________ > psas-avionics mailing list > psas-avionics@lists.psas.pdx.edu > http://lists.psas.pdx.edu/mailman/listinfo/psas-avionics > >
_______________________________________________ psas-avionics mailing list psas-avionics@lists.psas.pdx.edu http://lists.psas.pdx.edu/mailman/listinfo/psas-avionics
