anonymous wrote on Monday, February 20, 2012:
I’ve got v7.1.0 working nicely under an atmega 2560 in pre-emptive mode, but when I switch to non pre-emptive it blows up, even though the tasks are calling vTaskDelayUntil(). Actually it blows up completely so i it isn’t that one task is hogging the cpu. looking at some old posts, I found that if I kept pre-emptive enabled but commented out the switch context call, everything still worked.
I want to verify, does this indicate a problem with frame-pointers? should I recompile with -fno-omit-frame-pointer, and then non-premptive will work out of the box? Does this indicate some other deeper issue?
I have a second issue as well. To do with checking max stack use:
When I print the unsigned long output of uxTaskGetStackHighWaterMark( NULL ) in my first task it does not match that which is printed inside the table generated by vTaskLIst ( ). With a 1500 byte stack, it prints 32 bytes, but with a 800 byte stack, it prints a larger number. How can that be? it basically seems to get it wrong, but the vTaskList() table seems correct.
Additionally, the amount printed in vTaskList() table seems to change a little and not always get smaller. I thought that “high water” meant that it could only ever get smaller?
And a hint for anyone looking at FreeRTOS on atmega. Don’t use heap_3.c and use the vPortMalloc/Free routines because they just call malloc/free and the avr malloc/free has detection for heap/stack collision which breaks inside a freeRTOS task as the stack is unexpectedly (to AVR) inside the heap! So you must use heap_1 or heap_2, and then ensure all malloc/free calls are converted or #define’d to the FreeRTOS versions that alloc from this fixed heap.