Problems with Task Timing.

I have a FreeRTOS application with three tasks which exhibits funny timing behavior.  My first task is derived from the flashing LED task in the demo (some changes to use vTaskDelayUntil).  This task makes a good visual indication that I haven’t broken anything. My other two tasks implement a Queued LCD driver and a test task that sends it strings to be displayed.  The queue is similar to the pollQ demo task.  Functionally, both tasks seem to be OK by themselves. I am using pre-emptive mode and no co-tasks.  I am running on a Silabs C8051F120 using the Silabs IDE and the SDCC compiler. When I run only the flashing LED task, the timing looks just as I would expect.  When I add the LCD driver and test task, the LED task speeds up.  Not just a little, but a lot.  It also becomes very irregular.  It looks as though some ticks are happening very much faster than others. Obviously this is more likely to be a problem I have caused than a bug in the FreeRTOS code, but at this point I don’t know where to look next.  Any suggestions would be welcome. - Bill

Problems with Task Timing.

People that read this regularly will guess what I’m going to say ;-)  Have you checked the stacks used by your tasks?  Maybe the LCD driver requires more than the minimal stack and is causing some corruption. Regards.

Problems with Task Timing.

Richard, Thanks for the quick reply.  I am a regular reader, and I already thought of that.  I can’t say for sure, as I don’t know how to test this inside the guts of FreeRTOS, but I don’t think so.  I have a very small queue (10 bytes). I have the task stack set as large as I think I can (256 – start address).  I don’t see any other evidence of corruption.  I have re-ordered large blocks of code to change the adjacency of various blocks in memory, with no changes in behavior.  I have re-written the task code to minimize stack usage with no change in behavior. How would you go about checking for stack overflow? - Bill

Problems with Task Timing.

Each task stack is filled with 0xa5.  I don’t know which debugger you are using, but you should be able to find the stack in memory.  Either make note of where the stack is when the task is created, or stop the task on a breakpoint and check the tack pointer.  You will hopefully see lots of 0xa5’s.  Let the code run for a while, then check again to see how many are left.  There is also a function in task.c that can be optionally included to walk the stack and tell you how much is left (can’t rememeber the name off the top of my head). It is very odd that you seem to get the tasks going faster.  On the assumption you have not changed the timer setup by mistake some sort of corruption is most likely but normally this would lead to a complete failure.

Problems with Task Timing.

Well,  as i suspected, the task stack is not being corrupted.  In fact, it is very lightly used.  At the deepest my subroutines have pushed it down by about 20 bytes or so.  Still lost on this one, so I will press ahead on other issues for a few days. - Bill