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.