GPIO port event issue.

[Chongchun Moon]

Hello,

  I am using NRF52832 with nRF5_SDK_15.2.0.

  I have met lock up situation. Actually, Device is running but it doesn't wake up.

  I am using 2 external interrupt to wake up device from IDLE. I am using port event to do that.

  I trying to find out root cause. But, I can not reproduce it.  But it still happen in the field.

 

I have a suspicious about two part in PORT event as above in red box. 

Could you explain more about first red box? Because, I don't understand how that situation is possible.

Can you give me a example how to make that situation happen?

And, Regarding to seconds red box, In my code, I don't follow that procedure to configure the source(PIN_CNF(n).SENSE) before entering sleep.

What is "spurious" meaning in the context? Is there any possibility that GPIO interrupt is not occurred?

Thanks,

  Chongchun Moon

[Håkon Alseth]

Hi,

 

The first chapter is related to if the pin is kept active (ie: DETECT is active), then entering sleep (WFE/WFI). This will cause the DETECT signal to be set. The workaround here is to check if your GPIOs configured with SENSE is active.

Figure 2 here shows this a bit better:

https://infocenter.nordicsemi.com/topic/com.nordic.infocenter.nrf52832.ps.v1.1/gpio.html?cp=3_2_0_19_0#concept_o12_bgv_bs

What is "spurious" meaning in the context? Is there any possibility that GPIO interrupt is not occurred?

This is related to the pin state when it is configured with SENSE. If this pin is first configured with SENSE, then afterwards with a PULL resistor, the state is undefined for a very small period of time, where the DETECT signal can occur.

 

Kind regards,

Håkon

[Chongchun Moon]

Håkon Alseth said:

The first chapter is related to if the pin is kept active (ie: DETECT is active), then entering sleep (WFE/WFI). This will cause the DETECT signal to be set.

Regarding to this explanation, I understand if DETECT is active, it will not catch another PINx.DETECT.

But, What I don't understand is which case device goes to sleep, If DETECT signal is active(If PORT EVENT is occurred, Interrupt handler is exist).  Could you give me more insight?

Håkon Alseth said:

The workaround here is to check if your GPIOs configured with SENSE is active.

Could you tell me how to do it? 

Håkon Alseth said:

This is related to the pin state when it is configured with SENSE. If this pin is first configured with SENSE, then afterwards with a PULL resistor, the state is undefined for a very small period of time, where the DETECT signal can occur.

Can this moment impact to the first situation (While DETECT is active, device goes to sleep)? Because I changed sense configuration before device goes to sleep(WFI/WFE).

Regards,

  Chongchun Moon

[Håkon Alseth]

Chongchun Moon said:

Could you tell me how to do it? 

Check the state of those GPIOs before you go to sleep, to see if that improves the scenario:

if (nrf_gpio_pin_read(MY_PIN) == NOT_ACTIVE) {
  sleep();
}

 

Chongchun Moon said:

Can this moment impact to the first situation (While DETECT is active, device goes to sleep)? Because I changed sense configuration before device goes to sleep(WFI/WFE).

Yes, that can impact if you reconfigure the IO with SENSE (and it's in floating state), then apply PULL configuration. Set it as input with PULL first, then configure it with SENSE.

Chongchun Moon said:

What I don't understand is which case device goes to sleep, If DETECT signal is active(If PORT EVENT is occurred, Interrupt handler is exist).  Could you give me more insight?

 DETECT is a level triggered signal, and will be kept high as long as one or more sources are active (signal is logically ORed with other SENSE enabled sources), as per figure 2 in the link I formerly posted. You will get an event when DETECT is active, but it can be active for longer periods of time, so to avoid this, you check the state of your SENSE enabled GPIOs before entering sleep.

 

Kind regards,

Håkon

[Chongchun Moon]

I am concern about checking what you suggest to checking state of GPIOs.

Because I am using toggle mode for those two GPIOs. I thought It may caused another issue.

Can I check latch register in GPIO instead of checking state of GPIOs? Every 125ms, RTC interrupt is occured. I like do something in that RTC handler. What do I need to do or check in that RTC handler to correct situation?

Thanks,

  Chongchun Moon

[Håkon Alseth]

Chongchun Moon said:

Because I am using toggle mode for those two GPIOs.

 Toggle mode (NRF_GPIOTE_POLARITY_TOGGLE) will essentially emulate rising and falling edge, by inverting the SENSE field when you get the interrupt. Pins that are configured with this should, due to the implementation in nrfx_gpiote, not be affected by this. GPIOs with SENSE and GPIOTE_CONFIG_POLARITY_LoToHi/GPIOTE_CONFIG_POLARITY_HiToLo will need to be checked if they are still active when entering sleep.

 

Chongchun Moon said:

Can I check latch register in GPIO instead of checking state of GPIOs? Every 125ms, RTC interrupt is occured. I like do something in that RTC handler. What do I need to do or check in that RTC handler to correct situation?

Yes, you can implement a "pin debouncer check" with an app_timer or RTC handler. You need to check the pin state, as described in my former post.

 

Kind regards,

Håkon