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

Inability to sleep the nRF52832. Number of possible buttons in using the BSP module?

Hi, 

We have a custom device that has 15 buttons. Presently we use the following code to initialize and use the button interrupts. I am using a __WFE(); to wait for the next event (i.e. a button press) however when I press two specific buttons (by design) together it brings the device partially into sleep_mode. This method works sufficient for detecting the button presses, but in attempting to put the device into a lower power mode it seems that some sort of interrupt is triggering the device to come right out of the low power mode or not completely go into low power mode. The device does come out of the "low power (5mA)" mode but completes a reset in the process. The current draw drops from about 9 mA (with I2C device) down to 5 mA (likely, just without I2C device), but never drops to uA levels. My thought is that another interrupt triggers the device to come right out while keeping the I2C device off, but I'm not sure which one would do that.

/*
*
* The following contain the interrupt handlers for all button presses
*
*/
void in_pin_handler(nrf_drv_gpiote_pin_t pin, nrf_gpiote_polarity_t action)
{
   buttons_pressed = true;
   chirp_led(BLUE_LED);

   ret_code_t err_code; 
   
   if(power_off_mode)
      {
              
            //Disable power-down button to prevent System-off wakeup
                      
            for(int i = 0; i < NUM_BUTTONS; i++) {
                    
                    nrf_drv_gpiote_in_uninit(buttons[i]);
                    nrf_drv_gpiote_in_event_disable(buttons[i]);      
            }

            //Configure wake-up button
           
            for(int i = 0; i < NUM_BUTTONS; i++) {
                nrf_drv_gpiote_in_config_t in_config = GPIOTE_CONFIG_IN_SENSE_LOTOHI(false);    //Configure to generate interrupt and wakeup on pin signal high.
                in_config.pull = NRF_GPIO_PIN_PULLDOWN;                                         //Configure pulldown for input pin to prevent it from floating.
                err_code = nrf_drv_gpiote_in_init(buttons[i], &in_config, in_pin_handler);      //Initialize the wake-up pin
                APP_ERROR_CHECK(err_code);                                                      //Check error code returned
                nrf_drv_gpiote_in_event_enable(buttons[i], true);                               //Enable event and interrupt for the wakeup pin
            }
          
          //Enter System-off
          NRF_POWER->SYSTEMOFF = 1;
      }
}


//
//@brief Function for configuring: PIN_IN pin for input, PIN_OUT pin for output,
// and configures GPIOTE to give an interrupt on pin change.
//
static void gpio_init(void)
{
    ret_code_t err_code;

    nrf_gpio_cfg_output(BLUE_LED);
    nrf_gpio_cfg_output(RED_LED);
    
    if(nrf_drv_gpiote_is_init() == false)
    {
        err_code = nrf_drv_gpiote_init();
        APP_ERROR_CHECK(err_code);  
    }

    for(int i = 0; i < NUM_BUTTONS; i++) {
        nrf_drv_gpiote_in_config_t in_config = GPIOTE_CONFIG_IN_SENSE_LOTOHI(false);
        in_config.pull = NRF_GPIO_PIN_PULLDOWN;

        err_code = nrf_drv_gpiote_in_init(buttons[i], &in_config, in_pin_handler);
        APP_ERROR_CHECK(err_code);

        nrf_drv_gpiote_in_event_enable(buttons[i], true);
    }
}

Searching around I found a handful of explanations of using the BSP module along with a sleep_mode_enter() based on a button press. However, all of the documentation only shows 8 buttons available in the BSP module. Is there the ability to handle more buttons than that, 15 or more? If so what steps would need to be taken to modify the included files to allow for this? Do I need to modify the pca10040.h, bsp.h/c, boards.h/c, others? How so?

Thanks for the help!

Parents Reply Children
  • Hi, 

    Thanks for the suggestions. I am not presently using the button handling library, I've defined a buttons.h file and have initialized them as GPIOTE_CONFIG_IN_SENSE_LOTOHI as shown above. I may want to use it though as I still cannot identify the root issue of the high power. 

    I've looked into the RESETREAS register before and after applying the power settings. The value never changes from 0x00000006 indicating the following. 

             1. Reset from watchdog detected

             2. Reset from soft reset detected

    I am using a watchdog, but based on the value never changing and the fact that our current draw reduces to only 5 mA (from 9mA by putting our I2C device into sleep mode) it still seems like the device never actually enters a lower power mode. Could the Watch Dog be preventing entry into the sleep mode? Or what else could prevent this?

    Additionally I tried to use an idle_state_handler(); which calls nrf_pwr_mgmt_run(); to set the device into System ON mode (to preserve the state of the machine better). This eliminates the resetting on wake-up button pressing, but again it doesn't seem like the device even enters a lower power mode (just turns off our I2C device).  

    /**@brief Function for handling the idle state (main loop).
     *
     * @details If there is no pending log operation, then sleep until next the next event occurs.
     */
    static void idle_state_handle(void)
    {
        if (NRF_LOG_PROCESS() == false)
        {
            nrf_pwr_mgmt_run();
        }
    }

    Also, 

    So I'm gathering If I define a custom_board.h file the only limitation on number of inputs to track and use with BSP is the number of I/O the device has? Is that correct that I can define 15 or more buttons this way? I may have to try this route of detecting button presses if I cannot get the power draw lower since it seems like the power management is more defined and functional with it. 

    Thanks for the help!

  • Hi, 

    Just an update. I tried removing the Watch Dog completely. The problem of not entering the sleep mode is not due to the Watch Dog as I got no different results by doing so. 

    Another thing to mention. At the point I am trying to sleep the device (peripheral) it is connected to a central device. Do I need to terminate the connection or do any house-keeping before calling the sleep function, or should that happen automatically with the methods I've tried?

    Thanks!

  • Hi,

    BendaEng said:
    Additionally I tried to use an idle_state_handler(); which calls nrf_pwr_mgmt_run(); to set the device into System ON mode (to preserve the state of the machine better). This eliminates the resetting on wake-up button pressing, but again it doesn't seem like the device even enters a lower power mode (just turns off our I2C device).  

     

    Could you step through the code and verify if the nRF actually calls the sleep function? Ble events might be waking the application from sleep, I suggest that you try terminating the connection before going to sleep. I'm suspecting that the high current consumption might be due floating pins. Could you read the PIN_CNF register and see that all pins are set as input with input buffer disconnected. This would prevent any pins from floating and therefore raising the current consumption during sleep. 

     regards

    Jared

  • Hi Jared, 

    I've stepped through the program and it does call the sleep function. I also tried terminating the connection before going to sleep with the following, but it would hardfault on me everytime I called the sleep function. Is there another way to do this or am I calling this correctly from the peripheral side?

        if(sleep_pressed)
        {
            sleep_sensor();
            NRF_LOG_INFO("Sleep\n");
            
            err_code = sd_ble_gap_disconnect(m_conn_handle, BLE_HCI_REMOTE_USER_TERMINATED_CONNECTION);
    
            sleep_pressed = false;
            power_off_mode = true;
    
            power_off();
        }

    So I looked through the PIN_CNF registers for all GPIO. I got back the following (annotated with each pins use). I believe I've interpreted the registers correctly. All unused pins are set to input with disconnected input buffers. 

    Pin 0 (button) = 0x00020004  : 2 = RW SENSE for high level, 4 = RW Pulldown on Pin 
    Pin 1 (mosfet) = 0x00000003  : 3 = Configured as output pin, disconnected input buffer
    Pin 2 (unused) = 0x00000002  : 2 = Configured as input pin, disconnected input buffer
    Pin 3 (unused) = 0x00000002  : 2 = Configured as input pin, disconnected input buffer
    Pin 4 (unused) = 0x00000002  : 2 = Configured as input pin, disconnected input buffer
    Pin 5 (unused) = 0x00000002  : 2 = Configured as input pin, disconnected input buffer
    Pin 6 (unused) = 0x00000002  : 2 = Configured as input pin, disconnected input buffer
    Pin 7 (unused) = 0x00000002  : 2 = Configured as input pin, disconnected input buffer
    Pin 8 (unused) = 0x00000002  : 2 = Configured as input pin, disconnected input buffer
    Pin 9 (unused) = 0x00000002  : 2 = Configured as input pin, disconnected input buffer
    Pin 10 (unused) = 0x00000002  : 2 = Configured as input pin, disconnected input buffer
    Pin 11 (led) = 0x00000003  : 3 = Configured as output pin, disconnected input buffer
    Pin 12 (led) = 0x00000003  : 3 = Configured as output pin, disconnected input buffer
    Pin 13 (unused) = 0x00000002  : 2 = Configured as input pin, disconnected input buffer
    Pin 14 (button) = 0x00020004  : 2 = RW SENSE for high level, 4 = RW Pulldown on Pin
    Pin 15 (button) = 0x00020004  : 2 = RW SENSE for high level, 4 = RW Pulldown on Pin
    Pin 16 (button) = 0x00020004  : 2 = RW SENSE for high level, 4 = RW Pulldown on Pin
    Pin 17 (button) = 0x00020004  : 2 = RW SENSE for high level, 4 = RW Pulldown on Pin
    Pin 18 (button) = 0x00020004  : 2 = RW SENSE for high level, 4 = RW Pulldown on Pin
    Pin 19 (button) = 0x00020004  : 2 = RW SENSE for high level, 4 = RW Pulldown on Pin
    Pin 20 (button) = 0x00020004  : 2 = RW SENSE for high level, 4 = RW Pulldown on Pin
    Pin 21 (unused) = 0x00000002  : 2 = Configured as input pin, disconnected input buffer
    Pin 22 (button) = 0x00020004  : 2 = RW SENSE for high level, 4 = RW Pulldown on Pin
    Pin 23 (button) = 0x00020004  : 2 = RW SENSE for high level, 4 = RW Pulldown on Pin
    Pin 24 (button) = 0x00020004  : 2 = RW SENSE for high level, 4 = RW Pulldown on Pin
    Pin 25 (unused) = 0x00000002  : 2 = Configured as input pin, disconnected input buffer
    Pin 26 (SDA) = 0x0000060c  : 6 = Standard '0'. disconnect '1' (normally used for wired-and connections), c = pullup on pin
    Pin 27 (SCL) = 0x0000060c  : 6 = Standard '0'. disconnect '1' (normally used for wired-and connections), c = pullup on pin
    Pin 28 (button) = 0x00020004  : 2 = RW SENSE for high level, 4 = RW Pulldown on Pin
    Pin 29 (button) = 0x00020004  : 2 = RW SENSE for high level, 4 = RW Pulldown on Pin
    Pin 30 (button) = 0x00020004  : 2 = RW SENSE for high level, 4 = RW Pulldown on Pin
    Pin 31 (button) = 0x00020004  : 2 = RW SENSE for high level, 4 = RW Pulldown on Pin

    Does each pin 'have' to be set as input with input buffer disconnected? If so how can an interrupt on pin state change be used to wake the device back up?

    Another thought I had was the bootloader holding SWDIO and SWDCLK lines on. The reason I say this is because currently I am using the attached debug bootloader. I've read that in debug mode the device will not be able to properly sleep. I built in release mode, disconnected my debugger, and measured the power consumption during "normal operation". The 5 mA still is the lowest I can get it. Could this debug bootloader cause backend peripherals to not be allowed to shut down? If so where can I find a bootloader (with DFU functionality) that wouldn't have those characteristics?

    nrf52832_xxaa_s132_bootloader_with_settings_Debug.hex

    Thanks again for the help!

  • Hi,

    No, only unused pins should be set as input with buffer disconnected. 

    BendaEng said:
    I've read that in debug mode the device will not be able to properly sleep. I built in release mode, disconnected my debugger, and measured the power consumption during "normal operation".

    Yes, if the nRF is in debug mode then it will not go into system OFF but emulate it, which will not give a current consumption similar to the what is expected in sleep. A complete power cycle should set the nRF to normal mode. Do you have a DK available? Could you try using the external debugger on the DK and program the custom board with the Power Profiling Application from the SDK? What is the current consumption that you're measuring? The result from this would highlight what causes this issue, i.e a problem with the design of the custom board or the application that you're using.  Could you also describe how you measure the current consumption? Are you using the power profiler kit?

    The application also shows how to implement sleep mode properly with BLE.

    regards

    Jared 

Related