Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem


Loading

Problems with Task Timing.

Posted by Bill Den Beste on April 19, 2006
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

RE: Problems with Task Timing.

Posted by Richard on April 19, 2006
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.

RE: Problems with Task Timing.

Posted by Bill Den Beste on April 19, 2006
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

RE: Problems with Task Timing.

Posted by Nobody/Anonymous on April 19, 2006
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.

RE: Problems with Task Timing.

Posted by Bill Den Beste on April 20, 2006
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


[ Back to the top ]    [ About FreeRTOS ]    [ Sitemap ]    [ ]




Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.

Latest News

FreeRTOS kernel V10.0.1 is available for immediate download. Now MIT licensed.

Video: Watch James Gosling & Richard Barry at re:Invent, Las Vegas 2017.

New FAQ page about the FreeRTOS kernel and Amazon FreeRTOS.


FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

IAR Partner

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

OpenRTOS and SafeRTOS

Xilinx Microblaze and Zynq partner