Quality RTOS & Embedded Software

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


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 ]    [ Privacy ]    [ Sitemap ]    [ ]

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

Latest News

FreeRTOS v10.2.0 is available for immediate download. MIT licensed, and including RISC-V and ARMv8-M (Cortex-M33) demos.

NXP tweet showing LPC5500 (ARMv8-M Cortex-M33) running FreeRTOS.

View a recording of the "OTA Update Security and Reliability" webinar, presented by TI and AWS.


FreeRTOS and other embedded software careers at AWS.

FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Cadence Tensilica Cortes

Espressif ESP32

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