Maximum expected interrupt delay when using Softdevice

RE: Maximum expected interrupt delay when using Softdevice

MartinBL — Mon, 15 Jan 2018 15:58:58 GMT

If you want to investigate that I think we will need to see your code. You can edit your question here and attach your code as a file, or you can open a case in mypage, our official support portal, if you prefer confidentiality.

RE: Maximum expected interrupt delay when using Softdevice

pajo — Wed, 10 Jan 2018 16:02:05 GMT

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.

RE: Maximum expected interrupt delay when using Softdevice

pajo — Wed, 03 Jan 2018 16:01:46 GMT

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.

RE: Maximum expected interrupt delay when using Softdevice

MartinBL — Wed, 03 Jan 2018 13:37:04 GMT

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.

RE: Maximum expected interrupt delay when using Softdevice

pajo — Wed, 03 Jan 2018 10:52:11 GMT

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.

RE: Maximum expected interrupt delay when using Softdevice

Dave_couling — Tue, 02 Jan 2018 20:01:51 GMT

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.