Advertising causes timer1 delay?

[gwayne]

My project: nRF51422, S110, based on SDK 7.1.

My project employs several application timers (run via the scheduler) and a continuously running Timer1-based 1ms timestamp counter. Timer1 increments a static counter variable on each CC0 interrupt. An application (scheduled) timer runs a battery check every 5 seconds (for BAS service). The system appears to run fine while advertising as long as a potential client (not connected) is NOT activated in the vicinity. As soon as a potential client (again, not connected) is switched on (iPhone /iOS8.1, running "LightBlue" app) Timer1 looses over 1 second between the 5 second battery check intervals. In the Segger RTT captures below each battery reading is preceded by the (Timer1 based) 1ms timestamp, followed by the time since the last reading. The "LightBlue" app is activated at timestamp [66017].

If the client connects, the timer once again becomes accurate.

Upon disconnection, the timer once again looses time.

I have Timer1 set for HIGH interrupt priority. Is this expected? Any idea why this is happening?

Update: Altering the timer to interrupt at 10ms, instead of 1ms, intervals appears to remedy the issue. Apparently the processor can't keep up with all the interrupts while the soft device is working on advertising.

[Stefan Birnir Sverrisson]

Hi

I think your assumption is correct. The peripheral will send an advertising packet, then start the RX receiver in order to listen for a potential connection request or scan request. If the central device is an active scanner (i.e. sends a scan request) the peripheral will respond with a scan response packet, which will increase the blocking time of the CPU.

IOS generally performs active scanning when the IOS app is in the foreground, which explains the behavior. When the peripheral is advertising and does not send scan response packet, I suspect the CPU is blocked for less than 1 ms, but when sending scan response packet the CPU is blocked for more than 1 ms.

If the CPU is blocked during two consecutive Timer1 interrupts, you will lose one interrupt, i.e. for two timer1 interrupts, the counter will only be incremented once.

---

I suspect the problem can be solved by using third revision nRF51 hardware and softdevice 110 7.1+ which allows for the CPU to be used during radio activity. See this thread how to unblock the CPU for S110 v7.1.0 (only works with third revision nRF51, see comp matrix for what nRF51 devices are third revision). For S110 v8.0.0, the CPU is unblocked by default.

If you look at the S110_softdevice Specification version 1.3 (targeted at softdevice 7.0.0), section 11.3.1, you see that the softdevice can block the CPU up to 1700 us. If you however look at the same section in S110_softdevice Specification version 2.0 (targeted at softdevice 8.0.0), you see the CPU blocking time during advertising is only 440 us.

An idea of a workaround is to use Timer1 with 1ms interrupt frequency and use Timer2 as counter, and let Timer1 CC0 event trigger a counter task on Timer2 trough a PPI channel. That way, no CPU is needed to increment the ms counter.

Another dirty workaround would be to advertise with whitelist. The peripheral will not send scan response packet to a central that is not in the whitelist.

[hawk]

@stefan， we have the external crystal oscillator，// Initialize the SoftDevice handler module. SOFTDEVICE_HANDLER_INIT(NRF_CLOCK_LFCLKSRC_XTAL_20_PPM, false); the detail is described in this url： devzone.nordicsemi.com/.../