FreeRTOS Support Archive
The FreeRTOS support forum is used to obtain active support directly from Real
Time Engineers Ltd. In return for using our top quality software and services for
free, we request you play fair and do your bit to help others too! Sign up
to receive notifications of new support topics then help where you can.
This is a read only archive of threads posted to the FreeRTOS support forum.
The archive is updated every week, so will not always contain the very latest posts.
Use these archive pages to search previous posts. Use the Live FreeRTOS Forum
link to reply to a post, or start a new support thread.
[FreeRTOS Home] [Live FreeRTOS Forum] [FAQ] [Archive Top] [June 2013 Threads] Tracking down bug in SAM4L-EKPosted 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) vTaskStartScheduler() while(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++); vTaskSuspend(worker1_id); } vTaskDelete(worker1_id); }
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.
--Chuck
RE: Tracking down bug in SAM4L-EKPosted 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.
Regards.
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.
|