PPI Timer2 weird behavior on Bluetooth connect

[technicc]

Hello!

We're using PPI to connect one pin to clear and capture events on Timer2. On pin low-to-high we're clearing the timer and on pin high-to-low, we're capturing the timer. We have S110 enables and inited on PCA10001 board.

The application works great until we connect the PCA10001 to the PCA10000 (via master control panel) at which moment the values from the timer become erratic and random. It stays the same after Bluetooth disconnect.

[Susheel Nuguru]

There should be a GPIOTE involved in the usecase you mentioned. GPIOTE will convert the pin state change into events, which should be connected to PPI to convert into a timer task. After configuration there is no software involved in clearing and capturing the timer value. It is done by hardware so S110 connections and disconecctions shall not effect this.

1)Did you use different GPIOTE and PPI channels to configure the pin state change? 2) how are you reading these values, is your reading interrupt based?If your processing time for your interrupt is less than 100us, you could set the interrupt priority to APP_HIGH to see if that helps. 3)If pin state change is happening faster than the softdevice is allowing the app to read it then it is possible that after connection (softdevice blocks cpu for 1ms-6ms depending on packet length) then you are missing few read cycles of timer capture register.

[RK]

Hmm this seems similar to your last question.

How are you using one pin to do two different tasks? You can only have one GPIOTE channel per physical pin (according to the documentation). If you're reconfiguring the GPIOTE and PPI mapping after the CLEAR event happens, you may be running into the same interrupt latency you found with the last question.

That's why I suggested in my last answer that you use two pins, just connected to the same source input, the pulse output from your distance measuring device. Then you can set up both GPIOTEs and both PPIs before you start and it should work.

[technicc]

We're not using an interrupt handler, we're just reading the captured value of the timer in the main while(1) loop. This is the relevant code:

nrf_gpiote_event_config(2, 10, NRF_GPIOTE_POLARITY_LOTOHI);        
nrf_gpiote_event_config(3, 10, NRF_GPIOTE_POLARITY_HITOLO);

sd_ppi_channel_assign(2, &NRF_GPIOTE->EVENTS_IN[2], &NRF_TIMER2->TASKS_CLEAR);
sd_ppi_channel_enable_set(1 << 2);
sd_ppi_channel_assign(3, &NRF_GPIOTE->EVENTS_IN[3], &NRF_TIMER2->TASKS_CAPTURE[0]);
sd_ppi_channel_enable_set(1 << 3);

In the main while(1) we're reading the value periodically like this:

counter = NRF_TIMER2->CC[0];

We did a bit more playing around though ... If we assign channels on PPI (last four lines at the top) AT bluetooth connect (case BLE_GAP_EVT_CONNECTED), it seems to be working fine.

Does the soft-device stack change PPI channels (channels 2 and 3) on Bluetooth connect?

[Susheel Nuguru]

softdevice does not change anything for PPI channels 0 -13. But like RK said

Only one GPIOTE channel can be assigned to one physical pin. Failing to do so may result in unpredictable behavior.

I cannot think of any reason why assigning PPI channel when you get a connected event changed the behavior here. It seems that configuring different GPIOTE channels with same pin gives different behaviour depending on the state of the pin when configured, this is what unpredictable means. I strongly recommend you not to build your logic on this behavior.

[RK]

I just had a hunt through some of my code. I have one app uses PPIs 0-2 and it sets them up early and never changes them - they appear to work even after advertising starts. This is S110 (that code uses V7 as I've not upgraded it yet). That's one piece of empirical evidence that the softdevice doesn't touch the PPI channels, it's certainly not meant to.

Can you check the PPI config in the debugger when advertising starts and see if it's what you set it to earlier? You won't be able to continue after stopping but you should be able to tell if the config was messed up.