GPIOTE rising and falling edge detection at the same time

[Jimmie Johansson]

Hi,

I'm writing a decoder for a custom radio protocol and I need to measure the rising and falling edges of a signal with high precision. I'm currently using the COMP peripheral since it can generate both UP and DOWN events that I use with PPI and a TIMER to capture a timestamp of the edges.

I would have preferred to use GPIOTE since the signal is digital, but according to the datasheet, "Only one GPIOTE channel can be assigned to one physical pin. Failing to do so may result in unpredictable behavior." And I would need to use two GPIOTE events, one for HiToLo and one for LoToHi.

In this question (https://devzone.nordicsemi.com/f/nordic-q-a/33273/what-s-the-maximum-frequency-for-a-pin-event-on-rising-edge-or-falling-edge/128113#128113) Edvin recommends using multiple GPIOTE channels on the same pin.

What issues could I run into if I use one GPIOTE to detect HiToLo and one to detect LoToHi, both connected to the same GPIO?

[ovrebekk]

Hi Jimmie

While it isn't officially supported I have yet to notice any issues when connecting two GPIOTE channels in input mode to the same pin. 

I have used this feature on a couple of occasions in applications where a separate event for the rising and falling edge is required, and it has worked fine during my testing at least. 

So while I can't guarantee that this will work fine in all occasions there are no known issues using the GPIOTE in this way. 

Best regards
Torbjørn

[Jimmie Johansson]

Thank you for the answer, can you give some more information on why it is not officially supported?

We are writing code for receiving critical alarms, so we would need to know some more specifics if we are going to ship a product using a non-supported feature. I have also confirmed that is seems to work as well as the analog comparator (the reason why I want to use GPIOTE is that the hardware design can be simplified if we can select any GPIO and not just the analog pins).

[ovrebekk]

Hi Jimmie

Essentially this wasn't identified as a requirement when the module was originally specified, and no one has gone through the loops of qualifying this use case later on. 

Still, connecting two peripherals to the same pin has been shown to work fine if both or one of them are inputs only, but if both are set up as outputs then you will obviously have issues. 

A workaround if you can spare a GPIO is to connect your signal to two different GPIO's at the same time, and assign one GPIOTE channel to each of them. Then you don't have to 'go against' the recommendation in the specification. 

Alternatively this would have to be tested so we can guarantee that connecting two channels to the same pin will work fine, which needs to be prioritized towards other tasks the test group is working on. I can open an internal ticket to see if we can do this work, but I can't make any promises obviously. 

Best regards
Torbjørn

[shna6159]

Hey Jimmie,

I saw that you implemented GPIOTE rising and falling edge detection at the same time. I am trying to implement something similar. Is it possible for you to share your implementation of the same?

Also, have you run into any sort of stability issues with this implementation?

[Jimmie Johansson]

We re-designed the hardware and used the LPCOMP-module instead since the GPIOTE-function is not officially supported. We simply cannot risk edge-cases where it could fail. But the proof of concept was done directly with the nrfx-drivers (or direct register access, don't remember fully). We simply se up two different gpiote channels on the same pin.