NRF_GPIOTE EVENTS_PORT woes (again)

RE: NRF_GPIOTE EVENTS_PORT woes (again)

jsheaney — Thu, 13 Oct 2022 19:03:45 GMT

After thrashing this over and over, it seems like the worst case scenario (looking at the actual driver and its order of operations) is that a P0 bit gets set after checking it, but before checking P1. That's the only race condition where it looks like both LATCH registers are clear, but they really are not. In that case, you will exit the ISR, but then the ISR will be immediately re-entered with the P0 bit still set because EVENTS_PORT has already been cleared and set again and the interrupt bit will be pending.

OK, I believe it! Thanks for your patience!

RE: NRF_GPIOTE EVENTS_PORT woes (again)

Kenneth — Thu, 13 Oct 2022 08:40:22 GMT

Hi,

[quote user="jsheaney"]At the start of your reply, there is an implication that there are two DETECT signals; on per port. At the end, you quote the GPIOTE text, which sounds like there is only one DETECT signal.[/quote]

I can understand this is not straight forward, but in short you may say that the two DETECT signals that can be generated from Port0 and Port1 is OR'ed together before input to the GPIOTE module, the GPIOTE module will generate the PORT EVENT when this OR'ed DETECT signal go from low to high. It is also worth mentioning that when configuring to use LDTECT to generate the DETECT signal(s), then there is also some additional circuitry between the OR'gate and the GPIOTE module that is used to trigger a DETECT signal in the following corner case condition: "If one or more bits in the LATCH register are 1 after the CPU has performed a clear operation on the LATCH register, a rising edge will be generated on the LDETECT signal."

[quote user="jsheaney"]So if P0->LATCH has a bit set and P1->LATCH has a bit set then both have to be cleared in the one ISR. In this scenario, if I clear the bit in P0->LATCH will a new event be generated, even though I haven't cleared P1->LATCH, yet?[/quote]

No.

[quote user="jsheaney"]If so, that means my ISR is going to be re-entered before I service the P1 bits.[/quote]

This will never happen, an interrupt will never be interrupted by itself. What can happen is that the PORT event is triggered again during execution of the GPIOTE handler, in which case the interrupt will be pending and thereby run again afterwards (presuming of course that you cleared the port event BEFORE you started clearing the LATCH registers, and not the other way around).

[quote user="jsheaney"]If not, then there's a race condition getting both LATCH registers clear.[/quote]

There is a possible race condition here, but it can be solved. You just need to ensure that both LATCH registers are 0 the last time you read them by the MCU in the GPIOTE handler. Yes it is possible that they are set after you have read them, but that is not a problem (let me try to explain why). By doing it this way you know that the DETECT signal must have been low at some point (since both LATCH registers were 0), even if it could have changed since you read them. The fact that they both have been 0 at the same time means that any changes afterwards have triggered the DETECT signal and thereby the PORT event (allowing a second GPIOTE handler to be pending).

What you should _not_ do: "Enter GPIOTE handler. Read and clear Port event if set. Read P0->LATCH, and possible clear it if it's set. Then you read the P1->LATCH, you find it's set and you clear it. Then exit the GPIOTE handler."

In the above case the problem is the red text, because there is a chance that you will miss any change to P0->LATCH this way. Instead you need to change it to something like this:

What you should do: "Enter GPIOTE handler. Read and clear Port event if set. (*)Read P0->LATCH, and clear it if it's set. Then you read the P1->LATCH, you find it's set and you clear it. Read both P0->LATCH and P1->LATCH and check they are both 0, if not repeat from (*). Then exit the GPIOTE handler."

Best regards,
Kenneth

RE: NRF_GPIOTE EVENTS_PORT woes (again)

jsheaney — Wed, 12 Oct 2022 19:05:51 GMT

That link doesn't work for me and I haven't been able to do a web search that leads me to that text you quoted. I'm looking at the Nordic Infocenter documentation for nRF52 Series:nRF25833:GPIO.

I agree that the ambiguity is related to how the two GPIO:DETECT signals are joined to trigger the one GPIOTE:EVENTS_PORT, which is why I think it would be very helpful to have both a logic and timing diagram. In that sense, GPIO:Figure 1 isn't "wrong", just incomplete.

At the start of your reply, there is an implication that there are two DETECT signals; on per port. At the end, you quote the GPIOTE text, which sounds like there is only one DETECT signal.

The problem is that one ISR has to service interrupts for two ports. This is different from other peripherals (e.g. I2c), where each instance has its own interrupt handler. So if P0->LATCH has a bit set and P1->LATCH has a bit set then both have to be cleared in the one ISR. In this scenario, if I clear the bit in P0->LATCH will a new event be generated, even though I haven't cleared P1->LATCH, yet? If so, that means my ISR is going to be re-entered before I service the P1 bits. If not, then there's a race condition getting both LATCH registers clear. Both seem fraught with peril. But knowing which is correct would be helpful.

All of this seemed perfectly clear when there is one port, but maddeningly unclear when there are two. Pictures are nice. 🙂

RE: NRF_GPIOTE EVENTS_PORT woes (again)

Kenneth — Wed, 12 Oct 2022 15:05:27 GMT

Hello again,

I have done some digging here.

I see your point about the documentation seems wrong, but the GPIO chapter do describe each port individually, so it do seem fine if you look at it this way (I do however have some additional information about how the DETECT signal is "joined" from each port to the GPIOTE module at the end here):

But to answer your most pressing problem about GPIO_EVENT, DETECT and SENSE I want to refer to the following chapter:
https://infocenter.nordicsemi.com/topic/ps_nrf52833/gpio.html#concept_o12_bgv_bs

"The LDETECT signal will be set high when one or more bits in the LATCH register are 1. The LDETECT signal will be set low when all bits in the LATCH register are successfully cleared to 0.

If one or more bits in the LATCH register are 1 after the CPU has performed a clear operation on the LATCH register, a rising edge will be generated on the LDETECT signal. This is illustrated in DETECT signal behavior."

With DETECTMODE=LDETECT, the DETECT signal comes from LATCH instead of directly from pins, and if you clear LATCH, it automatically pulls the DETECT low in order to generate a new edge. It's important that you use LDETECT in this case, because I have received confirmation from one of the designers that the DETECT signal is gated by LATCH clearing *after* OR'ing all port+pin contributions (but only when DETECTMODE=LDETECT.) The "masking" of the LATCH clearing occurs for 16 clock cycles.

Based on the above I do believe the implementation now is safe to always trigger the Port event by using LDETECT, ref: "PORT is an event that can be generated from multiple input pins using the GPIO DETECT signal. The event will be generated on the rising edge of the DETECT signal."

Best regards,
Kenneth

RE: NRF_GPIOTE EVENTS_PORT woes (again)

Kenneth — Mon, 10 Oct 2022 15:05:07 GMT

Let me check internally and get back to you (this will take several days).

Kenneth

RE: NRF_GPIOTE EVENTS_PORT woes (again)

jsheaney — Mon, 10 Oct 2022 13:15:35 GMT

Kenneth, Thanks for chiming in. I'm hoping a new perspective will help me set this aside.

1) The documentation is wrong, as I indicated. There are two LATCH registers and two DETECTMODE registers. The 52833 documentation should be updated, accordingly, so that we can see how the hardware really works.

2) The GPIOTE documentation says "The event will be generated on the rising edge of the DETECT signal.". That means the DETECT signal must be brought low before there can be a (subsequent) rising edge. Simply setting the EVENTS_PORT register to 0 will not cause another interrupt.

3) The race condition stems from the fact that you have to read two different (LATCH) registers to detect the bits that need to be cleared because there is no way to read the DETECT signal. (It would be nice if there was a secret register somewhere that would allow it.) Since these bits are set in hardware, the setting of them cannot be disabled while reading the registers. That means while reading P0->LATCH, bits in P1->LATCH can be set and vice versa. This is really the crux of the problem. Typically, if you run into a situation like this, you create a critical region around your non-atomic reads. In this case, you can't. There doesn't appear to be a way to stop the hardware from updating the LATCH registers.

4) I installed a workaround by looking at the LATCH registers in my main (non-interrupt) loop. Sometimes I see a bit set in a LATCH register. (To be clear, this should never happen because an interrupt should be generated before my main context code has a chance to read it.) Upon detection, I set the LATCH bits back to 0 and that keeps the system going, although I obviously lost an interrupt in the process.

RE: NRF_GPIOTE EVENTS_PORT woes (again)

Kenneth — Mon, 10 Oct 2022 10:56:04 GMT

Hello,

I am not sure if I fully understand the problem, if you in the gpiote interrupt handler find that the EVENT_PORT has occured (and clear it) and then check the LATCH register(s) (and clear those set), this may iterate a few times depending whether new EVENT_PORT/LATCH are triggered during gpiote handler execution as you write, however if there are new source(s) for the DETECT signal triggering the EVENT_PORT, after EVENT_PORT was cleared, would then not the gpiote interrupt be fired again immediately after such that those also can be handled?

Looking at the nrfx_gpiote_irq_handler() and port_event_handler() implementation in nrfx_gpiote.c I don't quite understand where the race condition you are afraid of occurs:
https://github.com/NordicSemiconductor/nrfx/blob/master/drivers/src/nrfx_gpiote.c#L1316
https://github.com/NordicSemiconductor/nrfx/blob/master/drivers/src/nrfx_gpiote.c#L1157

If you are the nRF5 SDK you may need to look at this file instead:
https://github.com/NordicSemiconductor/nrfx/blob/nrfx-1.x/master/drivers/src/nrfx_gpiote.c

Edit: I might be able to see a problem if you have fast toggling input signal (e.g. >1kHz range), but in that case maybe using IN event is a better suggestion than PORT_EVENT for those pins in specific.

Kenneth