Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Real time embedded FreeRTOS mailing list 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem TCP & FAT Training




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) 2004-2010 Richard Barry. Copyright (C) 2010-2016 Real Time Engineers Ltd.
Any and all data, files, source code, html content and documentation included in the FreeRTOSTM distribution or available on this site are the exclusive property of Real Time Engineers Ltd.. See the files license.txt (included in the distribution) and this copyright notice for more information. FreeRTOSTM and FreeRTOS.orgTM are trade marks of Real Time Engineers Ltd.

Latest News:

FreeRTOS V9.0.0 is now available for download.


Free TCP/IP and file system demos for the RTOS


Sponsored Links

⇓ Now With No Code Size Limit! ⇓
⇑ Free Download Without Registering ⇑


FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Renesas Electronics Gold Alliance RTOS Partner.jpg

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

Atmel RTOS partner supporting ARM Cortex-M3 and AVR32 microcontrollers

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

Xilinx Microblaze and Zynq partner

Silicon Labs low power RTOS partner

Altera RTOS partner for Nios II and Cortex-A9 SoC

Freescale Alliance RTOS Member supporting ARM and ColdFire microcontrollers

Infineon ARM Cortex-M microcontrollers

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

Cypress RTOS partner supporting ARM Cortex-M3

Fujitsu RTOS partner supporting ARM Cortex-M3 and FM3

Microsemi (previously Actel) RTOS partner supporting ARM Cortex-M3

Atollic Partner

IAR Partner

Keil ARM Partner

Embedded Artists