nRF52 delay_us and delay_ms are not accurate

[mhaggag]

Hello,

I currently working with the nRF52832 chip on a custom board. The external clock is a 32MHz clock with +/- 10 ppm. When I use nrf_delay_us or nrf_delay_ms the delay is always not accurate. The following part of the code:

						nrf_gpio_pin_set(GPIO2_EXT);
						nrf_delay_ms(100);
						nrf_gpio_pin_clear(GPIO2_EXT);

Shows on the logic analyzer the following delays for different values:

nrf_delay_ms(100) ==> 96.81 ms delay nrf_delay_ms(40) ==> 38.73 ms delay nrf_delay_ms(10) ==> 9.682 ms delay

nrf_delay_us(100) ==> 95.1 us delay nrf_delay_us(40) ==> 38.2 us delay nrf_delay_us(10) ==> 9.975 us delay

Any idea whats causing this behavior or how to fix it ?

[endnode]

As @gacek16 pointed out this function is using cycle of NOP instructions so indeed it isn't accurate. I believe that documentation on infocenter and inside SDK indicate that this function should never be used for actual time measurement, only test purposes or inaccurate blocking busy loops. Use RTC por TIMER peripherals/libraries for everything else.

[mhaggag]

I know how the function is implemented by nRF52. I am not using the function for actual time measurements, I am using it for busy blocking. But that doesn't mask the fact that the function is off by 5% !!

[endnode]

Well if you want time-accurate blocking busy loop then disable all interrupts and call NOP instruction directly as many times as 64MHz clock cycles you need to achieve given timing. But I guess that's not very useful... For anything else use timers.

[mhaggag]

"disable all interrupts and call NOP instruction directly as many times as 64MHz clock cycles you need to achieve given timing" is not even remotely useful and timers are not busy blocking. I had the nRF51822 before the nRF52832 and the delay blocks there had a much better accuracy (close to within 1%)