This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Why is the FreeRTOS function xTimerResetFromISR not working in tickless mode?

Hi,

I modified the blinky_freertos example from SDK 12 slightly to perform the following:

I have one timer and one task. The task blinks a LED and then suspends. In the timer callback function (one second period) I resume the task to have a LED that blinks every second. I now want to synchronise my timer to the "1 pulse per second" output of GPS module. To achieve this, I create a interrupt routine that resets my timer and resumes my task (so if the timer is reset just before it would call its callback, my task is still resumed). I took care not to resume a task from the ISR with a priority higher than the task that was interrupted.

If I'm running this code with tickless mode off, everything behaves as I expect. I attached a scope screenshot that shows the blinking LED (blue) is nicely synchronized to the external interrupt (yellow). Now when I turn tickless mode on, the synchronization will fail. It looks like the end of the delay in the task is synchronized with with the interrupt, and not the start of the task. Is this a bug? If not, can anybody tell me what I'm doing wrong? Our application is battery powered so tickless mode is really a must have.

I attached my main.c, FreeRTOSConfig.h, makefile and two scope screencaps.

Thanks!

Jules

main.c updated

FreeRTOSConfig.h

tickless_off.png

tickless_on.png

blinky_freertos.rar

Parents
  • Furthermore the first time the interrupt occurs after startup, the timer is reset correctly, but in the following seconds, it drifts slowly to the left on my scope until it stabilizes with the moment the LED is turned of synchronized to the interrupt.

    On explanation could be that when the interrupt occurs during the delay of the function, It incorrectly thinks the current time is the time the delay started (the time is not updated during the delay and also not during the interrupt!) The reset of the timer is simply a function that sets the callback time of the timer equal to the current time + the timer period. If the current time is not correct, the timer is not correctly reset. Could this be happening? (I'm definitely not an expert in this matter!)

Reply
  • Furthermore the first time the interrupt occurs after startup, the timer is reset correctly, but in the following seconds, it drifts slowly to the left on my scope until it stabilizes with the moment the LED is turned of synchronized to the interrupt.

    On explanation could be that when the interrupt occurs during the delay of the function, It incorrectly thinks the current time is the time the delay started (the time is not updated during the delay and also not during the interrupt!) The reset of the timer is simply a function that sets the callback time of the timer equal to the current time + the timer period. If the current time is not correct, the timer is not correctly reset. Could this be happening? (I'm definitely not an expert in this matter!)

Children
No Data
Related