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


Tracking down bug in SAM4L-EK

Posted by Chuck M. on June 29, 2013
So Atmel has a training course for the SAM4L (Cortex M4) which I just took, their software frame work has updated to 3.9.1 with FreeRTOS 7.3.0. In their training the are trying to demonstrate FreeRTOSTrace and that has students create a project which creates two tasks, each which simply burn CPU time then suspend themselves. And their test code is

xTaskCreate(worker1 ... priority 2)
xTaskCreate(worker2, ...priority 1)

When you pull the trace you are expected to see start time, then worker 2 runs for a while, then worker 1 runs for a while. Then nothing (they are both suspended at that point). However, what I actually see is that one of the tasks runs, and the suspends and that is all that happens.

Looking a the code I've verified that PendSV_Handler is getting called but it looks like the suspended task (which has the higher priority) is getting called. These workers are simply

static void worker1_task(void *pvParameters) {
static uint32_t i, delay;
delay = 10000;
for (;;) {
for (i = 0; i < delay; i++);

In the first part of the training configUSE_TIMERS is 0 in FreeRTOS_config but in later parts of the training they turn that on and add a timer task. Since their final solution works as expected I've been bisecting backwards and the behavior changes when I enable TIMERS. If this is set on, the traces appear as the training manual says they will, without that set the scheduler never seems to switch tasks.

I'm slowly digging into the scheduler code but as you know its painful with the debugger around interrupts. My next step is going to be to toggle LED0 whenever we change tasks but if this is a known issue I'd love to hear the resolution.


RE: Tracking down bug in SAM4L-EK

Posted by Richard on June 30, 2013
If you are asking if its a known problem that the scheduler does not schedule - then no - that is definitely not a known problem.

You can determine if both tasks are running by setting a break point on entry to both tasks, say on the "delay =" line. Assuming both tasks are being created (did you check the return value of the xTaskCreate() function) then both break points should be hit.


[ 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