Bug in app_button_is_pushed()?

RE: Bug in app_button_is_pushed()?

Sam Lin — Fri, 12 Sep 2014 10:26:06 GMT

I think the API app_button_is_pushed assuming button index is poor. Because the behavior is implicit. you might change button array declare order and the whole thing goes wrong without clue. It's dangerous. Even beacon reference design example made wrong assumption. : From beacon reference code:

err_code = app_button_is_pushed(CONFIG_MODE_BUTTON_PIN, &config_mode);

CONFIG_MODE_BUTTON_PIN is defined as BUTTON_1 (1).

but in fact :

static app_button_cfg_t buttons[] =
{
    {CONFIG_MODE_BUTTON_PIN, false, BUTTON_PULL, button_handler},
    {BOOTLOADER_BUTTON_PIN, false, BUTTON_PULL, button_handler}
};

what it expects is index 0.

This causes mess.

RE: Bug in app_button_is_pushed()?

Sam Lin — Fri, 12 Sep 2014 09:35:28 GMT

such API design is strange, I have to keep 2 enumeration for one button. one is button pin and another one is (trivial) button index of button array. they are totally different, and existing ALL examples wrongly assume they are the same.

RE: Bug in app_button_is_pushed()?

Charles Custon — Wed, 27 Aug 2014 08:14:16 GMT

This is still an issue, as the function also uses:

    // If the pin is active low, then the pin being high means it is not pushed.
    if(((active_pins >> pin_no) & 0x01))
    {
        *p_is_pushed = false;
    }

pin_no is used to index an array that has BUTTON_COUNT number of elements, yet is also being used to logically shift a 32 bit register.

We've modified the functions for our purposes as follows, with the first argument being the button number, instead of pin number:

uint32_t app_button_is_pushed(uint8_t button_no, bool * p_is_pushed)
{
uint32_t err_code;
uint32_t active_pins;

app_button_cfg_t * p_btn = &mp_buttons[button_no];

if (mp_buttons == NULL)
{
    return NRF_ERROR_INVALID_STATE;
}

err_code = app_gpiote_pins_state_get(m_gpiote_user_id, &active_pins);

if (err_code != NRF_SUCCESS)
{
    return err_code;
}

if(p_btn->active_state == APP_BUTTON_ACTIVE_LOW)
{
    // If the pin is active low, then the pin being high means it is not pushed.
    if(((active_pins >> p_btn->pin_no) & 0x01))
    {
        *p_is_pushed = false;
    }
    else
    {
        *p_is_pushed = true;  
    }            
}
else if(p_btn->active_state == APP_BUTTON_ACTIVE_HIGH)
{
    // If the pin is active high, then the pin being high means it is pushed.
    if(((active_pins >> p_btn->pin_no) & 0x01))
    {
        *p_is_pushed = true;
    }
    else
    {
        *p_is_pushed = false;   
    }
}

return NRF_SUCCESS;

}

RE: Bug in app_button_is_pushed()?

Leif-Alexandre ASCHEHOUG — Wed, 16 Jul 2014 10:57:52 GMT

Hi Actually, the input parameter of the app_button_is_pushed has changed and documentation is not reflecting this change, which is misleading. It should be the actual pin number being passed to the function but the index of the button in the array of configured buttons (which has been given to the init function).

RE: Bug in app_button_is_pushed()?

RK — Sun, 13 Jul 2014 12:23:47 GMT

That looks like a huge bug to me, I agree that that array is an array of buttons which exist, not an array of pins and that's just not going to work in most cases. The pointer is only checked for NULL on the next line as well, which is rather strange.

I'd suggest filing a support case with this one but perhaps report back after that's concluded.