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
  • I have created some unit test in our repository and recreate the problem. In attachment I am including quick preview of updated CMSIS port part. Please copy this files into .../freertos/portable: CMSIS.zip

    The solution is to lock interrupts little longer, but only application interrupts, not using BASEPRI register - as interrupts blocked this way would not wake up the MCU. It gives a little higher response time for interrupt when in tickless idle. But now it should be safe at last.

    The NRF52 port passes perfectly the test. NRF51 seems to miss 1 unexpected tick count. Just including file for reference because we have a holidays tomorow and I would not be able to polish it before the weekend.

  • Hi Jules, the GPIO ISR could be masking the sys tick interrupt too long, Could you try to remove the RTT prints in the ISR and see if this improves? if systick interrupt is masked (by other ISRs or by disabling RTOS interrupts) more than 1 ms then there is a good chance that tick interrupts will be lost.

Reply Children
No Data
Related