This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

SDK 14.3. BLE stops advertising when I set BUTTONS_NUMBER to any number greater than 4

Hi,

I'm adding some custom buttons to the NRF52-DK and I've been playing around in PCA10040.h. So far, I have everything working with 4 buttons. The DK can connect to the nRF Connect app, and each of the 4 buttons is able to send some sort of message over BLE to the app.

However, right now I'm trying to add extra buttons by changing code within pca10040.h to this:

#define BUTTONS_NUMBER 7

#define BUTTON_START   13
#define BUTTON_1       13
#define BUTTON_2       14
#define BUTTON_3       15
#define BUTTON_4       16
#define BUTTON_5       22
#define BUTTON_6       23
#define BUTTON_7       24
#define BUTTON_STOP    24
#define BUTTON_PULL    NRF_GPIO_PIN_PULLUP

#define BUTTONS_ACTIVE_STATE 0

#define BUTTONS_LIST { BUTTON_1, BUTTON_2, BUTTON_3, BUTTON_4, BUTTON_5, BUTTON_6, BUTTON_7 }

#define BSP_BUTTON_0   BUTTON_1
#define BSP_BUTTON_1   BUTTON_2
#define BSP_BUTTON_2   BUTTON_3
#define BSP_BUTTON_3   BUTTON_4
#define BSP_BUTTON_4   BUTTON_5
#define BSP_BUTTON_5   BUTTON_6
#define BSP_BUTTON_6   BUTTON_7

After changing "BUTTONS_NUMBER" to 7, the device will no longer advertise over Bluetooth. Instead, it keeps LED3 lit up. If I press BTN4, it goes into "DfuTarg" mode which makes me believe that it is repeatedly boot cycling since holding BTN4 and power cycling puts the device into DFU mode. (BTW, I am using a DFU bootloader and SoftDevice 132 v5.0.0).

The funny part is that if I keep "BUTTONS_NUMBER" at 4 or lower, it continues to function just fine. If I set it to 5 or any greater number, it fails in the fashion mentioned above. I tried scouring the entire SDK for mentions of "BUTTONS_NUMBER" or anything else related that might be causing this issue but I'm at my wit's end. Please help me if you know what's going on...

Parents
  • Hi,

     

    You can add the preprocessor define "DEBUG" to enable blocking assertions, where you can read out info on where the error occurred (file/line/err_code), but in this case, I suspect the issue comes from nrf_drv_gpiote, as it has a default setting of 4 low power pin events. This config can be found in the sdk_config.h, GPIOTE_CONFIG_NUM_OF_LOW_POWER_EVENTS.

    Could you try adjusting this to match your required buttons?

     

    Kind regards,

    Håkon

Reply
  • Hi,

     

    You can add the preprocessor define "DEBUG" to enable blocking assertions, where you can read out info on where the error occurred (file/line/err_code), but in this case, I suspect the issue comes from nrf_drv_gpiote, as it has a default setting of 4 low power pin events. This config can be found in the sdk_config.h, GPIOTE_CONFIG_NUM_OF_LOW_POWER_EVENTS.

    Could you try adjusting this to match your required buttons?

     

    Kind regards,

    Håkon

Children
Related