nRF52840, SDK version 17.0.2_d674dde, SD140.
Our code uses the PPI extensively to manipulate some GPIOs and start SPIM transfers from peripherals using EasyDMA to store results in memory. Periodically, that data is written to a NAND flash during a software interrupt, and also, periodically, some subset of that data is sent to a phone or watch using notifications.
Our PPI configuration is using TIMER1 as a counter, TIMER2 as a timer, TIMER3 as a counter, and TIMER4 as a timer. We are using HFCLK.
Normally, all is well and everything works well and consistently. However, when the phone that has subscribed to notifications, goes out of reach, the PPI appears to stop, or the timers stop.
In this screenshot, there are 2 of our nrf52840 boards, each sending notifications to a phone. There are 3 GPIOs being monitored on each of our boards. Channel 2 and 6 are being set/cleared inside of a software interrupt handler, but channel 0/1 and channel 4/5 are being driven by TIMER2 COMPARE events with the PPI.
Looking closer,
We see that after our software interrupt has exited, the GPIO being pulsed by the PPI on Channel 5 has been held high for the duration of the dropout. That pulse is normally low and the pulse duration is 30uS:
This tells me that the PPI or the associated TIMERs were stalled suddenly during the generation of that pulse.
The abridged PPI init code looks like:
err_code = nrfx_ppi_channel_alloc(&channel[0]);
err_code = nrfx_ppi_channel_assign(channel[0],
nrfx_timer_event_address_get(&timer_per_sensor, NRF_TIMER_EVENT_COMPARE0),
nrfx_gpiote_out_task_addr_get(COUNTER_RESET));
err_code = nrfx_ppi_channel_alloc(&channel[1]);
err_code = nrfx_ppi_channel_assign(channel[1],
nrfx_timer_event_address_get(&timer_per_sensor, NRF_TIMER_EVENT_COMPARE1),
nrfx_gpiote_out_task_addr_get(COUNTER_RESET));
Trying to understand what is happening here? I am under the impression that the PPI and TIMER[1-4] are safe while the SD is performing whatever it's performing. It would appear that the SD is halting our timers.
