At the end of xPortStartScheduler(), the portRestoreContext is botching the stack frame for the first task to run. Somehow it is pulling a bad value for the CP0 Status register off the stack and corrupting several important bits including the CU1 fpu coprocessor enable bit. I don’t observe any other problems with the first task; it starts up well and continues on to several other tasks, seemingly without a hitch. It does seem, though, if I restore the Status register manually after corruption, that it gets corrupted again at each call of portRestoreContext.
Here’s what’s at the ( UBaseType_t * ) pxCurrentTCB: a nice address = 0x80004F2C.
The contents of this is, according to the memory view, is 0xA5A5A5A5. I know, not a valid value. The saved stack pointer, just before the call to portRestoreContext, is a different kind of invalid, I think:
uxSavedTaskStackPointer = *( UBaseType_t * ) pxCurrentTCB = 0x00000000 !
I don’t know why this doesn’t come up as the value 0xA5A5A5A5 that the memory view shows. But neither value seems valid as a stack pointer.
Any ideas as to the cause of this?
I’ve raised the configMAX_SYSCALL_INTERRUPT_PRIORITY and configMAX_PRIORITIES to relatively high levels. I’m trying to see whether any FreeRTOS API gets called before xPortStartScheduler(). Any other diagnostics?
Setup: the latest FreeRTOS v 8.x.x, shipping with MHC 1.06 for PIC32MZ EF family processors.