I have TIMER1 configured as 16-bits wide with no prescaler (62.5ns tick) and CC[2] set up for a varying value near 65535. My work is based on the Nordic blog post about synchronizing wireless systems.
To achieve this, I have the PPI configured thusly:
- one PPI channel configured to connect TIMER1->EVENTS_COMPARE[2] to TIMER1->TASKS_CLEAR
- one PPI channel configured to connect TIMER1->EVENTS_COMPARE[2] to PPI->TASKS_CHG[].DIS
- PPI->CHG[] set up to disable the PPI channel which does the TIMER1->CLEAR
So when the timer matches the compare time, the timer is cleared and PPI channel which does the clear is disabled.
To visualize this, I've also set up a PPI channel which connects TIMER1->EVENTS_COMPARE[2] to a GPIOTE channel which toggles a GPIO whenever this occurs.
The system works fine, but I am noticing that occasionally (1 in 2 to 1 in 6 timer compare events), the GPIOTE triggers twice in very quick succession; usually 120ns apart. A logic analyzer can see this very easily:
Now I've been using numerous nRF51822 rev silicon: QFAAC0, QFAAG0, QFAAFA and CEAAE00 and the problem occurs across all of them. There is a PAN v2.4 which I've read and #26 (manual setup required to enable use of peripherals) and #57 (Concurrent operations on the PPI peripheral will fail). These PANs don't apply to the CEAAE00 part but even with the workarounds the glitching persists.
I'm also using four nRF51422 QFACA1 dev boards which also exhibit the glitch.
What is the cause of this? Can it be mitigated?
Note that I am using SDK 12.2.0 on all devices. I'm using the same software on all devices. I am *not* using a soft device nor am I using a bootloader. Aside from using the app_timer API (which only uses the RTC timer) and the app_uart_fifio api to print messages, I am not using any drivers nor APIs from the SDK.
