NRFX GPIOTE API and sensing with multiple pins recovering from system off

[Christopher Hunt]

Hi there,

I've configured the NRFX API of GPIOTE to sense four pins to go from low to high. This works well while the device is on. When the device is off (via having called sd_power_system_off) then the sensing no longer appears to work. However, if I sense just one or two pins then it does work... I'm using nRF5_SDK_17.0.2_d674dde with an s140 soft device on the nRF52840 DK.

I'm wondering if I'm experiencing some race conditions as discussed in other threads.

Here's how my main calls up the GPIOTE initialisation function:

static void gpio_init()
{
    ret_code_t err_code;
    nrfx_gpiote_in_config_t pir_pin_config = NRFX_GPIOTE_CONFIG_IN_SENSE_LOTOHI(false);

    if (!nrfx_gpiote_is_init())
    {
        err_code = nrfx_gpiote_init();
        APP_ERROR_CHECK(err_code);
    }

    err_code = nrfx_gpiote_in_init(m_left_entry_exit_outside_pir_pin, &pir_pin_config, on_gpio_in_evt);
    APP_ERROR_CHECK(err_code);
    nrfx_gpiote_in_event_enable(m_left_entry_exit_outside_pir_pin, true);

    err_code = nrfx_gpiote_in_init(m_left_entry_exit_inside_pir_pin, &pir_pin_config, on_gpio_in_evt);
    APP_ERROR_CHECK(err_code);
    nrfx_gpiote_in_event_enable(m_left_entry_exit_inside_pir_pin, true);

    err_code = nrfx_gpiote_in_init(m_right_entry_exit_outside_pir_pin, &pir_pin_config, on_gpio_in_evt);
    APP_ERROR_CHECK(err_code);
    nrfx_gpiote_in_event_enable(m_right_entry_exit_outside_pir_pin, true);

    err_code = nrfx_gpiote_in_init(m_right_entry_exit_inside_pir_pin, &pir_pin_config, on_gpio_in_evt);
    APP_ERROR_CHECK(err_code);
    nrfx_gpiote_in_event_enable(m_right_entry_exit_inside_pir_pin, true);
}

This function is called each time the device wakes up from sleep. I'm assuming that the NRFX GPIOTE API is built to handle the situation where GPIO events exist on entry otherwise the one/two sensing scenario wouldn't work.

Thanks for any pointers. This behaviour has been troubling me for a few days.

[Christopher Hunt]

ovrebekk said:

Do you know if there is any chance that one of the 4 input pins are already set when you enter sleep?

I’m unsure. However, I’m thinking that the nrfx interrupt handler should see this not to be the case. 

[ovrebekk]

Hi 

Have you checked that the code is actually entering sleep, or might it be continuing after the call to sd_power_system_off?

Is the issue consistent, or will it only happen a certain percentage of the time?

Best regards
Torbjørn

[ovrebekk]

Hi 

Are you able to share your code project, so I can take a closer look at the code, and try to reproduce the issue?

I can make the case private if you want, so you don't have to make the code available in public. 

Best regards
Torbjørn

[Christopher Hunt]

ovrebekk said:

Are you able to share your code project, so I can take a closer look at the code, and try to reproduce the issue?

Sure thing. I’ll share a reproducer tomorrow (+11 UTC here). Thanks for the follow up. 

[Christopher Hunt]

ovrebekk said:

Are you able to share your code project, so I can take a closer look at the code, and try to reproduce the issue?

I've created a project as reproducer. The main file configures GPIOTE to sense on four pins. It then deliberately goes into a power-off situation. In my situation, I had pins 3 and 4 connected to two sensors respectively. On startup, the program reports some sensing on pins 1 and 2 (which aren't connected to anything) and then powers off.

The next bit is interesting. If I then sense something on one of my connected sensors then the device never goes to power down, or rather, it does, but then quickly wakes up again.

More interesting: if I just sense up to two devices by commenting out the enabling of pin1 and pin2 sensing, all appears well. If I just enable one more then the continuous wake-up occurs.

I recognise that this is slightly different to the original problem I reported, but there's a strong correlation between what I observed for my larger project and that of this reproducer: I can sense up to two sensors just fine, but beyond that, problems occur.

Here's the project: https://github.com/titanclass/gpiote-nrfx-demo (I've configured just the pca10056 based target using SEGGER studio).

[ovrebekk]

Hi 

Thanks for sharing the example. I have got it running, and I also can't get it to go to sleep more than once. 

I will have to do some more testing over the weekend and get back to you. 

Best regards
Torbjørn

[Christopher Hunt]

Hi there - were you able to make any progress on understanding why the sleeping occurs only once?

[ovrebekk]

Hi 

Sorry for the slow response. 

I have done some more testing, and it seems the library is not able to handle the situation where more than one pin is already activated when you enter sleep. 

If two or more pins are activated by the time you enter system OFF then the device will reset immediately, configure the driver again in the same configuration, try to go to sleep again, and then reset again, going into an infinite reset loop until one or less pins are activated. 

I have forwarded these findings to the developer, and he will also look into it to see if this is an issue in the driver. 

As a workaround I expect this should work if you check the state of the pins before entering sleep, and configure the pins accordingly. 

IE: Any pin that is currently high should be configured as HITOLO, and any pin that is currently low should be configured as LOTOHI. 

Best regards
Torbjørn

[ovrebekk]

Hi again

The developer looked into this, and found some potential issues in the driver that might explain the issues you are seeing. 

I can describe the specifics in detail if you are interested, but first it would be helpful if you can try his proposed workaround and see if it solves it. 

Essentially, at the start of main(), before you initialize the GPIOTE driver, you need to run the following two commands for every GPIO pin that you use for wakeup:

nrf_gpio_cfg_default(PIN);
nrf_gpio_pin_latch_clear(PIN);

Can you try this and see if it works better?

Best regards
Torbjørn

[Christopher Hunt]

Thanks for this - I will try shortly.

[ovrebekk]

No problem, just let me know when you have been able to test it.