RE: Huge problems with RTC1->Counter and S310

Stefan Birnir Sverrisson — Fri, 12 Aug 2016 13:52:42 GMT

Hi Flemming

Thank you for your question

I suspect that the RTC1 interrupt handler execution is delay as softdevice activity and other higher priority tasks block the CPU for period of time to service the RTC1 interrupt. You can find delay caused by softdevice in chapter 13 in the S310 Softdevice Specification (SDS) document. Furthermore, if you have your RTC1 interrupt priority as APP_IRQ_PRIORITY_LOW, all softdevice callbacks will block the RTC1 interrupt handler. Setting the RTC1 priority to APP_IRQ_PRIORITY_HIGH however makes it have priority over softdevice callbacks, and I suspect it will make your timing more accurate. Still, BLE events will interrupt or block the application regardsless. Priority scheme for the nRF51 Cortex-M0 processor is found here. APP_IRQ_PRIORITY_LOW maps to Cortex-M0 priority 3 and APP_IRQ_PRIORITY_HIGH maps to Cortex-M0 priority 1. Softdevice callbacks have priority 2 and BLE protocol events have priority 0. Lower priority number is higher priority.

If you want however to get very precise timing, it is hard to do with the RTC. If you get the interrupt from the hall sensor via signal change on a GPIO pin then you could use GPIOTE+PPI+TIMER to get very precise timing. Connect GPIOTE event with TIMER task via PPI channel. Make the TIMER count the time. When signal change occurs on GPIO, GPIOTE event will trigger and immediately trigger TIMER capture event which will capture TIMER counter value into a CC compare register. You can then generate a timer interrupt to read the timer value from the CC compare register in the same way as you have done in the RTC1 interrupt handler. To see how GPIOTE+PPI+TIMER can be set up, look at the gpiote example in the SDK.