Button stuck upon pressing, keeps sending signal to my device

[Gerardo Martin]

Hello everyone, 

I'm using a modified version of SDK 15.0.0 ble_app_hids_keyboard on my nRF52 DK. It sends a volume up and a volume down command when I press buttons 1 or 2. However, the program gets stuck and won't stop sending that command. My button 4 which sends a pwm signal to led 4 seems to work fine. I've tried switching around the case lines in the button_event_handler function that I've attached here but that made things worse. Any help would be appreciated. Thank you.

static void button_event_handler(uint8_t pin_no, uint8_t button_action)
{
    if (button_action == APP_BUTTON_PUSH)
    {
        switch (pin_no)
        {
            case VOLUP_BUTTON:
                APP_ERROR_CHECK(consumer_control_send(CONSUMER_CTRL_VOL_UP));
                break;
            case VOLDOWN_BUTTON:
                APP_ERROR_CHECK(consumer_control_send(CONSUMER_CTRL_VOL_DW));
                break;
            case IR_BUTTON:
            {
                if(!pwm_on && !nrf_gpio_pin_read(IR_BUTTON))
                {
                    pwm_on = true;
                    app_pwm_channel_duty_set(&PWM1, 0, 50); 
                }
                else
                {
                    pwm_on = false;
                    app_pwm_channel_duty_set(&PWM1, 0, 0);
                }
                break;
            }
            case KEY_PRESS_BUTTON_PIN_NO:
            {
                APP_ERROR_CHECK(hid_kbd_send_string());
                break;
            }
            default:
                APP_ERROR_HANDLER(pin_no);
                break;
        } // end of switch
    } // end of if(button....)
    else if (button_action == APP_BUTTON_RELEASE)
    {
        switch (pin_no)
        {
            case IR_BUTTON: 

                break;
            case VOLDOWN_BUTTON:
                // Fall-through 
            case VOLUP_BUTTON:
                APP_ERROR_CHECK(consumer_control_send(RELEASE_KEY)); 
                break;
            case KEY_PRESS_BUTTON_PIN_NO:    
                APP_ERROR_CHECK(hid_kbd_send_release());
                break;
            default:
                APP_ERROR_HANDLER(pin_no);
                break;
        }
    }
}

[Sigurd]

Hi,

However, the program gets stuck and won't stop sending that command

How often does it happen?

 Do you know where it's "stuck" ?

What's the reason for why the command is sent? Is e.g. button_event_handler() being constantly called?

[Gerardo Martin]

It happens at the first instance of a push on either button 1 or 2. So everything will be okay until the first push of those two buttons that it keeps sending that command. I don't know where it's getting stuck but it is not registering that the button is being released or else it would've stopped sending the command. The two buttons send a 'vol up' and 'vol down' command so what I see on my phone is something spamming the volume up or down repeatedly. If I push vol up, it'll spam vol up and the other way is true. 

[run_ar]

Hi,

Did you check that the function "consumer_control_send(RELEASE_KEY)" is called when you release the button?

[Gerardo Martin]

Yes, I set a breakpoint on that line but it seems to trigger when I push the button, not release it. I've made sure that APP_BUTTON_PUSH and APP_BUTTON_RELEASE are the correct values and would not trigger at the same time. However, it looks like the release function acts the same as the push function, hence constantly sending the same command over and over.

[Karl Ylvisaker]

Hello, 

Thank you for your patience with this. The summer holidays have begun here in Norway, and DevZone is therefore operating with reduced staff for the time being. Sorry for any inconvenience this might cause.

Runar is currently out of office, so I will be handling this case in his absence.

Gerardo Martin said:

However, it looks like the release function acts the same as the push function, hence constantly sending the same command over and over.

Interesting. Do you have debounce on your button? Have you made any changes to the BSP module, if so, could you detail these?
It would be great if you could share a more complete version of your code, preferably containing the button initialization and configuration, along with any changes you might have made to the BSP module.

Looking forward to resolving this issue together!

Best regards,
Karl

[Gerardo Martin]

Hi

No worries! I understand.

Debouncing hasn't been implemented yet. This code is mostly the ble_app_hids_keyboard in the sdk 15.0.0 folder. The changes that were made were adding one more button and letting the original buttons to send a different command. The added button was configured to send a pwm signal to an led. No changes were made specifically to the BSP module. I will be attaching my project folder since that will probably be easier to look through than snipets of code. As I remember, the buttons that are named volup_button and voldown_button used to work correctly until the button that sent the pwm signal worked correctly. Is there a conflict between the button configurations that causing the buttons to bounce?

3051.ble_app_hids_keyboard.zip

[Karl Ylvisaker]

Hello again,

Thank you for your understanding, and for providing the project code.

Looking over your code I see that you are not checking the returned error code from app_button_init, for example. If the app_button_init function makes it all the way to the end, it will return the error code from its call to start the detection delay timer.
This means that the detection timer might be failing to start, without the application knowing.
Please add an APP_ERROR_CHECK to this returned error code, and see if an error is returned here. If it is, please let me know which error was generated, so we may look into the API to figure out how we may fix it.

Please also make sure to have DEBUG defined in your preprocessor defines, like shown in the included image:

This will make a detailed error message be outputted by your logger whenever a non-NRF_SUCCESS error code is passed to an APP_ERROR_CHECK.

I would also recommend that you take a look through the code in general, to make sure that all returned error codes are checked. The returned error codes is the only way for the application to know if a function call performed the expected function, or if some error handling is required.

Looking forward to resolving this issue together!

Best regards,
Karl