nrf_delay_ms seems to break timers in bootloader SDK15

[Andy]

Hello,

I just wanted to report some strange behavior I've observed in my application. The bootloader timers stop working when nrf_delay_ms is called. In my case this could be reproduced with a periodic timer firing every 100 ms and a 200 ms delay. After the delay was executed, the timers stopped firing.

I'm working on a custom bootloader based on the one provided with SDK15, with app_timer2. This is on a NRF52832.

I removed the delay and now the timers keep working as expected. I however didn't expect that a single delay would break my bootloader (depends on the 100 ms timer to generate unblocking delays).

I'm not having problems anymore, but I'd like to know why this happens.

Thanks in advance :)

[Martin Lesund]

Hi Andy,

That's because nrf_delay_ms halts the CPU. The reason you do not want to use nrf_delay_ms is that it implements waiting by calling a sequence of NOP__ to the processor core, keeping it active and thus drawing current.

[Andy]

I know how nrf_delay works and I know about the __NOPs. My concern is that after calling the delay, the timers don't work. It makes sense that they don't work at all for 200 ms, but in this case after those 200 ms they're still not working any longer.

[RK]

In general it doesn't make sense that they don't work for 200ms because the timers are interrupt driven and __NOP is just  an instruction running in the  CPU which is entirely interruptible. Of  course, if you're calling nrf_delay_ms inside a timer callback, or another interrupt with higher priority than the timer, indeed that will block the timers because they won't be able to interrupt you. So were you calling nrf_delay_ms()  inside a timer callback? If so that also explains why they stop working, because they return from the delay, schedule themselves for the next timeout, however that time's already passed during the nrf_delay, so they don't fire. If you left the code running long enough the timers would eventually wrap around and start working again. 

So if you were calling nrf_delay_ms inside a timer callback, it's entirely explainable, if you weren't, then it isn't. 

[Andy]

I had the delay somewhere after executing on_data_obj_execute_request_sched(), after nrf_dfu_validation_post_data_execute(). That call comes from the scheduler which to the best of my knowledge executes everything on the main context, not on an interrupt context.