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

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

BendaEng — Fri, 30 Aug 2019 13:02:18 GMT

Hi,

To answer your question, no I do not. However, basically what my equipment is telling me is the presence or absence of sleep (if 5 mA = ON, if 0mA = OFF, not taking into account any sort of accuracy).

On a different note, I have now been able to sleep my device. The following was the changes that I made to make the device sleep. Basically, I didn't let all of the 15 pins be a wakeup. Only two of them. I could never identify it, but I think one of those other pins (that are now not enabled for wakeup), was causing the wake-up. Maybe someone can shed light on this, but the pin cnf registers all seemed fine. Part of the issue could have been that my shutdown was contained in the input pin handler. Now it's in a separate function.

Anyway here's my changes.

OLD Non-Working

/*
*
* 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;
      }
}

NEW Working Code

void device_power_off(void)
{
  ret_code_t err_code = 0; 

 if(power_off_mode)
      {
              
            for(int i = 0; i < 5; i++)
            {
              chirp_led(RED_LED);
              nrf_delay_ms(100);
            }
            
            //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
            }
            */

            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[14], &in_config, in_pin_handler);      //Initialize the wake-up pin on FCN Button
            APP_ERROR_CHECK(err_code);                                                      //Check error code returned
            nrf_drv_gpiote_in_event_enable(buttons[14], true);                               //Enable event and interrupt for the FCN Button Wakeup Pin
            
            err_code = nrf_drv_gpiote_in_init(buttons[12], &in_config, in_pin_handler);      //Initialize the wake-up pin on BT Button
            APP_ERROR_CHECK(err_code);                                                      //Check error code returned
            nrf_drv_gpiote_in_event_enable(buttons[12], true);                               //Enable event and interrupt for the BT Button wakeup pin
          
          //Enter System-off
          power_off_mode = false;

          NRF_POWER -> SYSTEMOFF = 1; 

          //sd_power_system_off();     
      }


}

Thanks for the suggestions to get me here @Jared. Much appreciated!

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

Jared — Tue, 27 Aug 2019 11:10:20 GMT

Hi,

The boot loader shouldn't have any effect on keeping the pins on as it will jump directly to the app if it's valid. It seems from the documentation that the TinkerForge does not have a high enough resolution to measure the sleep current, as the current during sleep is in µA:

From description of features:

"1mW, 1mV, 1mA resolution over the whole range"

Do you have any other available device that can measure at µA range with a high enough resolution?

Best regards

Jared

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

BendaEng — Mon, 26 Aug 2019 12:04:12 GMT

Hi Jared,

Thanks for getting back to me. Ok, so if I'm understanding correctly my pins are setup properly?

I regards to the debug mode emulating sleep, I have power cycled my device with the same results returning upon power up. I am using a BL652 DK, which is not the same as the Nordic, but I program and debug externally on a custom board in the following way (I believe no different than the Nordic DK). To answer your follow-up question, no I am not using a power profiler kit, rather a Tinkerforge Voltage/Current Bricklet. My custom device is powered with a battery and measured through this current shunt in-line with the power connection.

Upon disconnecting my SWDIO and SWCLK from the custom board and power cycling my device after programming it I am using my enter sleep mode through button press. This consistently results in 5mA of draw.

In my previous reply I asked about the bootloader (as my application has a Buttonless DFU integration for OTA upgrading the firmware). Does the bootloader have any effect on forcing the I/O to remain on? I.e. the SWDIO and SWCLK or other peripheral? If so, what is the recommended bootloader for a Buttonless DFU application to retain low power capabilities?

Thanks!

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

Jared — Wed, 21 Aug 2019 12:41:31 GMT

Hi,

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

[quote user="BendaEng"]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". [/quote]

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

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

BendaEng — Sun, 18 Aug 2019 03:09:41 GMT

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?

devzone.nordicsemi.com/.../nrf52832_5F00_xxaa_5F00_s132_5F00_bootloader_5F00_with_5F00_settings_5F00_Debug.hex

Thanks again for the help!

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

Jared — Wed, 14 Aug 2019 13:56:37 GMT

Hi,

[quote user="BendaEng"]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). [/quote]

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

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

BendaEng — Mon, 12 Aug 2019 21:24:29 GMT

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!

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

BendaEng — Mon, 12 Aug 2019 21:09:06 GMT

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!

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

Jared — Mon, 12 Aug 2019 13:54:25 GMT

Hi,

The prouduct specification states:"When the system wakes up from System OFF mode, it gets reset. For more details, see Reset behavior". You could check the reason for the reset by reading register RESETREAS. Are you using the button handling library? The library handles debouncing which could otherwise cause a pin reset. You should use a custom board file if you're using a custom board with the BSP module.

regards

Jared.