helliwell_cj wrote on Monday, April 27, 2015:
I’m using v8.1.2 on an Atmel SAM4N, with ‘tickless idle’. I’ve used the implementation of the SAM4L low_power_tick_management.c from v8.0.1; modified - because it doesn’t have an AST - to the SAM4N’s similarly-slow-running RTT. The tick rate is 128Hz. configEXPECTED_IDLE_TIME_BEFORE_SLEEP is set to 5.
This seems to be working, but I’ve encountered an issue with one particular task (there’s only 3 in the app so far) which is waiting on a semaphore (xSemaphoreCreateBinary) given by an ISR: the tick count, comparing it with real time, is running 50% slow. In my current set-up the semaphore is never given (and I’ve disabled the interrupt).
The timeout on the xSemaphoreTake is 1sec; and the task loop then has a further 1sec vTaskDelay.
If I add a delay to the task before it enters its for loop, then the tick rate is fine until that delay ends.
Now there may be a problem with my low_power_tick_management.c, but I’ve discovered that if I change the xSemaphoreTake() to a plain vTaskDelay() then the problem goes away. Which makes me instead suspect something kernel-related - shouldn’t they then be amounting, in broad terms, to the same thing? i.e. delay the task for 1sec.
I haven’t spotted anything relevant in the change history, but is there a fix/update I’ve missed? I’m also unsure of the best way to dig to track the issue down further…?