Tracking down bug in SAM4L-EK

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

Tracking down bug in SAM4L-EK

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.