Duplicate GPIO callbacks after initializing button to support "wake up" from power OFF

RE: Duplicate GPIO callbacks after initializing button to support "wake up" from power OFF

Vidar Berg — Mon, 11 Mar 2024 14:34:09 GMT

There is a smaller chance of losing events when using PIN events instead of PORT events, since PIN events provide a dedicated event for a single pin, as opposed to a PORT event, which is common to all pins with sense enabled. I was also able to reproduce the same issue of duplicated events with PIN events, but not as easily.

I suspect the problem is related to button debouncing, and your software workaround effectively acts as a debouncing filter in software. The DK doesn't have a debounce filter for the button inputs.

RE: Duplicate GPIO callbacks after initializing button to support "wake up" from power OFF

cal.rubbo — Mon, 11 Mar 2024 11:57:50 GMT

UPDATE: I've mostly mitigated the issue, but this seems sort-of hacky and I am still curious whether this "GPIO sense callback accuracy" is a known issue or not, or if there's a better way to resolve it than what I've come up with.

This is how I mitigated the issue:

In the GPIO callback, add a check to only process the callback if it's been a certain amount of time since the previous callback (I chose 15 milliseconds)
Move the actual "work" that needs to be done after a GPIO callback to a work queue
Sleep for a short amount of time at the beginning of this "work" (I also chose 15 milliseconds)

Here's the result:

#define AF_BUTTON_EVENT_MINIMUM_MSEC 15
uint32_t af_button_previous_event = 0;

// Callback when button is either released or pressed
void af_button_state_cb(const struct device *dev, struct gpio_callback *cb, uint32_t pins) {
    
    // Ignore this event if a previous event happened within the millisecond threshold
    uint32_t af_button_current_event = k_uptime_get_32();
    if ((af_button_current_event - af_button_previous_event) < AF_BUTTON_EVENT_MINIMUM_MSEC)
        return;
    
    // Submit event work!
    k_work_submit(&af_button_state_work);
    af_button_previous_event = af_button_current_event;
}


// Do the actual work of updating advertising set #1's advertising data
void af_button_state_work_cb(struct k_work *item) {

    // To avoid reading the wrong GPIO state (e.g. two "high" events in a row, when it should be a "low" event)
    k_msleep(AF_BUTTON_EVENT_MINIMUM_MSEC);

    // Check current state to determine if this is a pressed or released event
    int val = af_button_get_state();

    // If this is a "press" event
    if (val > 0) {
        // ...
    }
    // If this is a "release" event
    else {
        // ...
    }
}
K_WORK_DEFINE(af_button_state_work, af_button_state_work_cb);  // To do the actual work that processes a button "high" or "low" event

RE: Duplicate GPIO callbacks after initializing button to support "wake up" from power OFF

cal.rubbo — Mon, 11 Mar 2024 11:05:59 GMT

Thanks Vidar.

Using this, I can confirm the GPIO callback now works (almost) as expected, and that the "sense" functionality is clearly enabled because I'm able to wake the device from sleep.

However, I'm now seeing the GPIO callback isn't as accurate as before. Is that expected? After a few presses, it looks like the callback is returning the GPIO state as "high" many times in a row (which should be impossible, since it's supposed to be called only once "high" and then once again when it's "low").

I'm using a very simple callback for now, here it is:

// Callback when button is either released or pressed
void af_button_state_cb(const struct device *dev, struct gpio_callback *cb, uint32_t pins) {
    
    // Check current state to determine if this is a pressed or released event
    int val = gpio_pin_get_dt(&af_button);
    
    printk("Button pressed at %" PRIu32 ", val=%d\n", k_cycle_get_32(), val);
}

For example, here's me pressing the button twice in a row. You can see the second press, the callback was returned "val=1" or "high" on the release event, as well as the press event. Sometimes this happens many times in a row. Note that I think it's related to how long you hold the button down.

Button pressed at 1484010, val=1
Button pressed at 1487371, val=0
Button pressed at 1491250, val=1
Button pressed at 1558829, val=1

RE: Duplicate GPIO callbacks after initializing button to support "wake up" from power OFF

Vidar Berg — Mon, 11 Mar 2024 08:41:42 GMT

I wasn't aware that configuring GPIO_INT_LEVEL_ACTIVE would cause the event to fire repeatedly. After testing with the Zephyr button sample, I discovered that the solution is to the GPIO_INT_EDGE_BOTH flag and apply the 'sense-edge-mask' property to the gpio node in the device tree. This enables edge triggering as before, but with port events.

Devicetree overlay with sense-edge-mask

Input configuration with sense edge mask

GPIOTE configuration

RE: Duplicate GPIO callbacks after initializing button to support "wake up" from power OFF

cal.rubbo — Fri, 08 Mar 2024 17:52:29 GMT

Sounds like Port events are the way to go from a idle current standpoint, however I'm confused about how they trigger GPIO callbacks.

Using GPIO_INT_LEVEL_ACTIVE as you suggested, the GPIO callback is repeatedly (and only) called while the button is held down. It also blocks anything else on the CPU until the button is released.

Is it possible to have a Port event trigger the GPIO callback on press AND release events? like an interrupt?

RE: Duplicate GPIO callbacks after initializing button to support "wake up" from power OFF

Vidar Berg — Fri, 08 Mar 2024 16:57:00 GMT

Hello,

Please try enabling LEVEL triggering instead of EDGE triggering by changing the GPIO_INT_EDGE_BOTH flag to GPIO_INT_LEVEL_ACTIVE. This should configure the pin with sense enabled and use Port events instead of Pin events, making the additional call to nrf_gpio_cfg_sense_set() redundant. Using PORT events also has the added benefit of reducing idle current and should be accurate enough to detect button events.

Sleep

Best regards,

Vidar