I was using FreeRTOS v4.7.2 as provided by Atmel. My code is derived from their FreeRTOS + LwIP demo. Today I merged in the changes between 5.0.2 and my code, including the needed change to macb.c that was provided with the 5.0.2 code. I merged files partly because I’d modified a couple of headers (moved timing info to a central header file) and partly so I could get a feel for where & how extensive the changes were. I’m pretty sure I merged things correctly, although there’s always the chance of error. I’ve deleted most of the examples from my code, leaving just vLEDFlashTask as a visual indicator that things are running. In the demo code, only the Basic web server is enabled, the tftp & smtp  options are disabled. I’ve implemented SDRAM, and re-done the linker script so that I can place globals and such in SDRAM when needed. Currently the heap (using heap3.c) is implemented in SDRAM, so all stacks & such are located in SDRAM. I haven’t run into any problems with this, and so far nothing but the heap is in SDRAM. Heap size is 128k. I’ve set the default stack size to 4k. My code still compiles, but throws a data exception error during runtime. All tasks are running at priority tskIDLE_PRIORITY + 1. I’ve added one small task called MeterTask, which is created last (6th task, idle task is 7th). configMAX_PRIORITIES is set to 16. The tasks are all created before the scheduler runs. Pre-emption is enabled. When I call xTaskCreate() for my task, it calls prvAddTaskToReadyQueue() which calls vListInsertEnd(). This line then yields a data exception:     pxIndex->pxNext->pxPrevious = ( volatile xListItem * ) pxNewListItem; Stepping the assembly and watching the registers doesn’t show me any invalid data addresses, at least that I can tell – I’m pretty new to the AVR32 processor. This is highly repeatable. However, if I change MeterTask’s priority to tskIDLE_PRIORITY + 2, this no longer causes errors. However, when the scheduler starts, it then throws a different but related exception (bus error data fetch). I haven’t yet run this one down to the exact source line. Any thoughts? Jeff

Your task MeterTask is created before the scheduler starts, so it cannot  be something in the context switch that is causing the problem. Are there any interrupts firing that are attempting to unblock a task or cause a context switch before the scheduler has been started? Are you using the same compiler version as before.  I know there was some issue with the size of the code created when Atmel brought out a new compiler but this was some months back. Have you updated all occurrences of xQueueGiveFromISR() to the new version where the last parameter is different?  This was the major change in V5.0.0.

In the initial case, the failure was occurring reliably during xTaskCreate() before the scheduler ran, so I agree, it’s not a context switch issue. No IRQs are firing that are attempting to do a context switch at the time of failure. Single stepping the assembly code showed the exception being generated inside vListInsertEnd(), not from something an ISR did. Unless an ISR can run "invisibly" while single stepping assembly inside the debugger… Same compiler, environment, etc. This stuff built & ran a couple days ago before I upgraded the RTOS. Only one queue/semaphore usage that needed to be changed (it’s still early days on my project), that was in macb.c and I took that function from the demo code that’s part of the RTOS 5.0.2 distribution.

ARRRGGGHHH! Never mind, I’m an idiot. I have code that tests the SDRAM by filling it and then reading back & checking the fill values. Somehow I managed to move the call to this to AFTER a couple taks had been created, thus trashing everything that had been malloc’d already, including the task ready list that appeared to be the problem. Amazingly, not trashing memory seems to make things work just fine. :-) Thanks for your time!