Maximum expected interrupt delay when using Softdevice

[pajo]

I am trying to create an 80ms pulse by setting a GPIO high, starting an application timer with 80ms timeout and then setting the GPIO low in the timer ISR. I am aware that it is a common problem when trying to time accurately with the Softdevice also running. From looking at the Softdevice documentation, the worst case ISR delay (assuming no flash writing is going on) is a few us.

However when I look at the pulses on a scope, I see that they fluctuate in period from 80ms to around 130ms. So I am seeing a worst case ISR delay of 50ms. Is that to be expected?

I have set:

#define APP_TIMER_CONFIG_IRQ_PRIORITY 2

so only the highest priority Softdevice interrupts should pre-empt my timer's ISR.

I don't need very accurate timing: a period range of 80ms to 110ms would be perfectly fine. Is there a way to achieve that? My feeling is that moving to a h/w timer wouldn't change matters because it wouldn't allow a higher ISR priority. I need to send a specific number of pulses and have a mark/space ratio of roughly 80:1, so I'm not sure that I can do it with a PWM.

n.b. If I disable the softdevice then the period is exactly 80ms every time.

[Dave_couling]

That seems a bit too long of a block time for the Softdevice. So something else might be going on. However to answer your question, the most accurate way of doing this is through PPI and GPIOTE. This eliminates the need for the CPU to execute code to toggle your GPIO pin. Its the Peripherals which are configured to do this for you. So Softdevice blocking the CPU doesn't affect your timing. Look into the GPIOTE examples for source code. Its a little hard to wrap your head around. But once you do, its a very powerful tool.

[pajo]

Thanks Dave. I'll give that a try. I also have noticed that it only occurs in debug mode. In release mode the timing is fine.

[MartinBL]

Delays of 50ms is definitely not to be expected. Here you can see what to expect: Processor usage patterns and availability.

Maybe you should look into using PPI together with GPIOTE and a Timer. It is possible to make a GPIO toggle completely autonomously without interfering with the CPU (or the Softdevice) at all. Dependent on your use case, you can probably also use two timers and/or two capture/compare registers to generate a periodic pulse train.

[pajo]

Thanks Martin. That's what I thought, 50ms seems too long. We are using the BLE uart service for debug messages so it's possible that we have quite a lot of traffic. That would also explain why the timing is so much more accurate in release mode. The only other option is that another ISR at priority 2 is pre-empting for an extended period, but from examining the code that seems unlikely. I'm looking into the GPIOTE option.

[pajo]

I can't fully explain why the delay of 50ms was occurring, but it only happened when using the APP timer. When I switched to using a h/w timer the maximum delay to service the ISR was <1ms.