GPIOTE/PPI/TIMER errors

RE: GPIOTE/PPI/TIMER errors

Tim — Fri, 07 Aug 2020 19:16:03 GMT

Thanks Dmitry. Under normal use, there are random trailing pulses after the initial measured pulse. In testing, though, I'm using a function generator to generate a single 250ms pulse every 5 seconds. There are no trailing random pulses.

I continue to see good results with current code that uses nrfx_gpiote calls. I wonder if nrfx_gpiote_in_event_disable/enable calls are setting MODE of GPIOTE->CONFIG[] to 0/1 rather than disabling/enabling GPIOTE interrupts.

Thanks,

Tim

RE: GPIOTE/PPI/TIMER errors

Dmitry — Thu, 06 Aug 2020 08:16:56 GMT

Hi,

I think the problem is that GPIOTE event is not cleared when you enable an interrupt (sd_nvic_ClearPendingIRQ is not enough), and right after enabling interrupts you're receiving an event from some random pulse.

RE: GPIOTE/PPI/TIMER errors

Tim — Wed, 05 Aug 2020 17:06:28 GMT

Hello again,

I may have discovered the source of intermittent errors. The code is designed to measure a pulse (LoToHi followed by HiToLo) of a signal. Our circuit connects the signal to two GPIO pins so I don't break the one-pin-one-GPIOTE event rule.

After detecting and measuring a pulse, other random pulses are expected for a couple seconds following the initial pulse. Only the first pulse is of interest, so in the GPIOTE interrupt routine (which is called on HiToLo marking the end of the pulse) I disable GPIOTE interrupts with

sd_nvic_DisableIRQ(GPIOTE_IRQn);

I set up a timer to fire three seconds later and execute:

sd_nvic_SetPriority(GPIOTE_IRQn,APP_IRQ_PRIORITY_HIGH);
sd_nvic_ClearPendingIRQ(GPIOTE_IRQn);
sd_nvic_EnableIRQ(GPIOTE_IRQn);

Is it possible that this can result in an erroneous GPIOTE event?

I changed the GPIOTE code to use nrfx_gpiote instead of manipulating GPIOTE registers directly.

nrfx_err_t err_code = NRF_SUCCESS;

nrfx_gpiote_in_config_t configLoToHi = NRFX_GPIOTE_CONFIG_IN_SENSE_LOTOHI(true);
configLoToHi.pull = NRF_GPIO_PIN_PULLUP;

// do not interrupt on LoToHi
err_code = nrfx_gpiote_in_init(COMPARATOR_PIN1,&configLoToHi,NULL);
APP_ERROR_CHECK(err_code);

nrfx_gpiote_in_config_t configHiToLo = NRFX_GPIOTE_CONFIG_IN_SENSE_HITOLO(true);
configLoToHi.pull = NRF_GPIO_PIN_PULLUP;

// interrupt on HiToLo
err_code = nrfx_gpiote_in_init(COMPARATOR_PIN2,&configHiToLo,gpiote_event_handler);
APP_ERROR_CHECK(err_code);

nrfx_gpiote_in_event_enable(COMPARATOR_PIN1,false);
nrfx_gpiote_in_event_enable(COMPARATOR_PIN2,true);

Then to ignore events following initial pulse, I use:

nrfx_gpiote_in_event_disable(COMPARATOR_PIN1);
nrfx_gpiote_in_event_disable(COMPARATOR_PIN2);

And to enable 3 seconds later:

nrfx_gpiote_in_event_enable(COMPARATOR_PIN1,false);
nrfx_gpiote_in_event_enable(COMPARATOR_PIN2,true);

I imagine that the nrfx calls to enable/disable an event are manipulating the NRF_GPIOTE->INTENSET and NRF_GPIOTE->INTENCLR registers and not enabling/disabling GPIOTE interrupts.

I've been running tests and finding zero errors. I would be glad to hear from Nordic or others confirmation that disabling/enabling GPIOTE interrupts (sd_nvic_EnableIRQ(GPIOTE_IRQn)/sd_nvic_DisableIRQ(GPIOTE_IRQn)) could have been a source of previous intermittent errors. Then I would be confident that current code is stable and reliable.

Many thanks,

Tim

RE: GPIOTE/PPI/TIMER errors

Tim — Fri, 31 Jul 2020 06:03:32 GMT

Thanks again Dmitry. I've simplified code as you suggest and am running tests. Still finding errors. Will try to offer more information that might be helpful investigating.

Again, thanks.

Tim

RE: GPIOTE/PPI/TIMER errors

Dmitry — Thu, 30 Jul 2020 10:22:06 GMT

It's hard to debug a floating problem, perhaps there's a race condition somewhere.

With a single timer, assing one PPI channel to start timer on rising edge, and a second one to stop and capture timer value on falling edge - that's all you need.

[quote userid="7638" url="~/f/nordic-q-a/64298/gpiote-ppi-timer-errors/262265"]Do you know when to use nrfx_ppi_channel_alloc() and when to use sd_ppi_channel_alloc()?[/quote]

sd_ppi_... functions are softdevice API calls, they should be used when softdevice is enabled, as some resources are blocked by softdevice from direct access.

RE: GPIOTE/PPI/TIMER errors

Tim — Wed, 29 Jul 2020 21:07:46 GMT

Hi Dmitry,

Thanks for replying. Good point. I didn't realize all timers on nRF52832 can be used in 32-bit mode. I will need to back port this to work on nRF51822 and the two available timers (TIMER1, TIMER2) are limited to 16 bit. (TIMER0, which supports 32-bit mode, is reserved for SoftDevice.) At maximum prescaler (9), timer will overflow in 2.097152 seconds which, while unlikely, is within my use case.

Would you suggest other ways to simplify? Can you see any issues with code as it is? Anything that might explain the very occasional errors?

Do you know when to use nrfx_ppi_channel_alloc() and when to use sd_ppi_channel_alloc()?

Thanks, appreciate it.

Tim

RE: GPIOTE/PPI/TIMER errors

Dmitry — Wed, 29 Jul 2020 20:12:14 GMT

Hi Tim,

your solution looks too complex.. the tick value is converted to uint32_t, why not to use a single timer in 32-bit mode?

RE: GPIOTE/PPI/TIMER errors

Tim — Wed, 29 Jul 2020 14:08:54 GMT

I forgot to include a few lines of code in gpiote_ppi_init() to enable GPIOTE interrupts. I've edited the original post.

Also will mention, during setup the application sets:

NRF_POWER->TASKS_CONSTLAT = 1;

Thanks,

Tim