Huge problems with RTC1->Counter and S310

[Flemming Jensen]

Hi All,

I am using the nrf51422 and softdevice S310 to send out ANT+ and BT Smart in my project.

I use RTC1->Counter in order to get a timestamp for an interrupt from a hall sensor.

But the there seem to be something strange going on because suddenly i get strange values from the RTC1->Counter register.

If i read the Counter register every second i get the following:

1  00008002
2  0001000E
3  00018002
4  00020005
5  00028002
6  00030005
7  00038002
8  00040008
9  00048004
10  00050006
11  00058002
12  00060005
13  00068002
14  00070005
15  00078002
16  00080003
17  00080014
18  00088002
19  00090005

But look at line 17! Because I am running RTC1 as a 32Khz counter i should see an increment of approx 0x8000 each read.

But suddenly i read a difference of 0x11

I use SEGGER_RTT_printf for the printout

and the following code:

uint32_t timer = NRF_RTC1->COUNTER;

SEGGER_RTT_printf(0, 
	"%d  %04X%04X\n",
	cnt++,
	(uint16_t)(timer >> 16),
	(uint16_t)(timer));

Please help :)

[Stefan Birnir Sverrisson]

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.