Timer Latency - Tickless Mode

joshy42 wrote on Tuesday, September 02, 2014:

I am using Atmel ARM Cortex (ASF) with FreeRTOS 8.1.1.

I need to read from an ADC at a rate of 2 kHz. I setup a hardware timer to trigger at a rate of 2 kHz and toggle an LED which I am probing.

If I run bare metal (don’t start scheduler) I see a nice 2 kHz toggle. If I start the scheduler and am using a tick mode, I see a nice 2 kHz toggle. However, if I start the scheduler in tickless mode, I see a horrible looking waveform, by this I mean that my toggles are very non-periodic, some very short, others very long.

I took this to mean that tickless mode is doing some type of non deterministic interrupt disabling for “long” periods of time which is causing me to miss interrupts or delay my interrupts. Or am I doing something wrong?

I verified my hardware timer has an interrupt priority of 0 (highest), and it doesn’t call any API functions. I also tried preventing any sleeping modes by “locking” myself in active, and that didn’t help either.

Any help much appreciated!


rtel wrote on Tuesday, September 02, 2014:

Are you using the default Cortex-M tickless mode, or a special that is tailored to the architecture? If the default then you will only be using a light sleep mode, so the wake up time should be short - however going tickless will introduce some jitter and timing slippage for sure, that is the trade off (as per the comments in the source code).

However in your case I don’t think tickless is appropriate because of the speed you are running the interrupt. The tickless implementation only knows for sure when the next task needs to run, it has no way of knowing when your interrupt is going to come in. So it will repeatedly turn the tick off, reprogram the clock, then as soon as it goes to sleep be woken up again and have to undo everything it just did - as well as try and work out how long it actually slept for. Also presumably the time it actually slept for will be a fraction of a tick period (assuming the tick is a lot slower than 2Khz), so you will also get lots of rounding areas.

You will probably be better off just leaving the tick running and using the idle hook to put the CPU into a sleep mode each time the idle task is running (so there are no higher priority application tasks that need to run). That can be done with a simple WFI instruction.


joshy42 wrote on Tuesday, September 02, 2014:

I am using the ticless mode as defined by “SAM4L_low_power_tick_management.c”.

So the problem is I only run my ADC for a short period of time. I really like the low power advantages of tickless mode all the other times but can’t handle the latency when I need to interface to my ADC…

Is there not a way to lock in tickless mode to prevent the clock reprogramming, sleep, etc. then to unlock after my ADC operations are complete? Any other ideas are much appreciated.


rtel wrote on Tuesday, September 02, 2014:

If you look in the source file you reference you will notice a macro called configPRE_SLEEP_PROCESSING(). That is intended as an opportunity to call back into the application code to determine whether or not the sleep should go ahead. If your ADC is active then you can use that macro to set xModifiableIdleTime to 0, and in so doing, abort the sleep. The macro might already be defined, in which case you can extend the current definition. You may also find the macro is in the wrong place for your needs, but you could always move it.