WICED Studio Wi-Fi Combo

[user_108962310]

Is there a bug in the `gpio_button_init` function?

The code is:

    return wiced_gpio_init( button->gpio, ( button->polarity == WICED_ACTIVE_HIGH )? INPUT_PULL_UP: INPUT_PULL_DOWN );

If a button is set up as active-low, so that the GPIO is connected to ground went it is pressed, shouldn't the micro therefor provide a pull UP, to restore the input to the non-active state?
And vice versa for active-high: GPIO goes high while button is pressed, then a pull DOWN is needed to return it to inactive when the button is released.

I ran into this when trying to set up the button_manager in SDK 5.1 .

[Zhengbao_Zhang]

Hi Andrew:

    I will look into this case, by the way do you meet some issues when you configure the GPIO functions?

and  which evb or chip you are using now?

[user_108962310]

The issue that I was seeing was that that the on-chip PU/PD was not being activated correctly.

Patching this line to:

return wiced_gpio_init( button->gpio, ( button->polarity == WICED_ACTIVE_HIGH )? INPUT_PULL_DOWN: INPUT_PULL_UP );

and corresponding changes in gpio_button_enable() and wiced_gpio_input_get() make my configuration with button_manager work as expected. On chip PU is switched on, IRQ's are called, and click/hold/double click events are detectable.

I hope I am not missing something obvious; this logic just appears to be inverted, but consistently through the gpio_button library.

I'm not using an EVM, I am working on custom-designed hardware (product prototype). The micro is STM32F4.

A separate but follow-up issue I have is that button manager does perform too well in the presence of certain noise or slow rising edges for an active-low button, and detects 0 or 1ms duration events rather than a qualifying "click" event. I will follow up with scope traces, if I get a chance.

[AlanH_86 · Accepted solution]

Yes that is a bug

I filed an internal case.

Alan