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

Minimizing the power draw using System OFF and RAM retention

Hi everyone,

I'm having an issue with the power draw of my application (SDK 15.0.0, SD 132 v6, Sparkfun nRF52832 Breakout). The application does roughly the following: it sleeps until it receives an GPIO interrupt (there are two different GPIOs which can wake up the application), does some (non connectable) advertising and resumes sleeping.

According to the data sheet of the nRF52832 0.7 µA are possible with full RAM retention and in system state System OFF. The power draw of my application exceeds this number (around ten times higher), however I'm not utilising the System OFF mode yet (currently using only the nrf_pwr_mgmt_run() function).

I did some research and discovered the sd_power_off() function. When I add the sd_power_off() function to my code, the system "freezes" / 'hangs" and draws about 10mA.

I did take a look at the example "ble_app_pwr_profiling" but it is rather complex - has anyone created / found a simpler solution (do some advertising, go to System OFF with RAM retention, wake up to an GPIO interrupt, repeat) yet?

How can I differentiate the two different GPIO interrupt sources when using them to wake up? (I want to count the times my application has woken up to sources 1 and 2)


Best,

lhochstetter

Parents
  • Hi,

     

    If you are using the nrf_pwr_mgmt library, you should call the appropriate API for entering system off mode:

    nrf_pwr_mgmt_shutdown(NRF_PWR_MGMT_SHUTDOWN_GOTO_SYSOFF);
    Are you debugging while trying to enter system off mode? Emulated systemoff (entering system off in debug mode) will not work as intended, as it will return immediately due to the debugger being attached.
    Kind regards,
    Håkon
  • Hi, I would ask what do you mean by "Are you debugging while trying to enter system off mode?". Do you mean connect your board with an usb to pc? if I unplug the board with the usb, is this mean I am not in the debug mode?

  • By debugging, I mean that you actively entered "debug mode" through your IDE and single-stepping through your code.

  • Hi Håkon,

    What do you mean "single-stepping through your code"?

    my code is just as simple as below:

    #include "boards.h"
    
    /**
    * @brief Function for application main entry.
    */
    int main(void)
    {
    NRF_POWER->SYSTEMOFF = 1;
    }
    /** @} */

    So am I in the debug mode?

    Thanks Slight smile

  • The nRF52840 board has integrated Segger J-Link debugger which is accessible via USB. The J-Link in turn talks to the 52840 chip via its Serial Wire Debug (SWD) pins. SWD is an ARM standard debug interface present on Cortex-M chips. This is how you flash the board, you can also use it to take control of the 52840 CPU and dump its memory, control its execution of code. You can use OpenOCD to connect to the J-Link interface and then use gdb to set breakpoints and single step the CPU one line or one instruction at a time, e.g.:

    (gdb) target remote localhost:3333 # connect to OpenOCD running on local machine

    (gdb) monitor reset init # reset CPU

    (gdb) break main          # set breakpoint at main()

    (gdb) continue             # let the CPU run

    <target continues, until it hits main>

    (gdb) step                   # step one line

    (gdb) stepi                  # step one instruction

    (gdb) info registers     # examine machine state

    (etc...)

    It sounds like system off mode won't work as long as the SWD interface on the CPU is in use, which means you have to let the CPU run without GDB connected in order to test it.

Reply
  • The nRF52840 board has integrated Segger J-Link debugger which is accessible via USB. The J-Link in turn talks to the 52840 chip via its Serial Wire Debug (SWD) pins. SWD is an ARM standard debug interface present on Cortex-M chips. This is how you flash the board, you can also use it to take control of the 52840 CPU and dump its memory, control its execution of code. You can use OpenOCD to connect to the J-Link interface and then use gdb to set breakpoints and single step the CPU one line or one instruction at a time, e.g.:

    (gdb) target remote localhost:3333 # connect to OpenOCD running on local machine

    (gdb) monitor reset init # reset CPU

    (gdb) break main          # set breakpoint at main()

    (gdb) continue             # let the CPU run

    <target continues, until it hits main>

    (gdb) step                   # step one line

    (gdb) stepi                  # step one instruction

    (gdb) info registers     # examine machine state

    (etc...)

    It sounds like system off mode won't work as long as the SWD interface on the CPU is in use, which means you have to let the CPU run without GDB connected in order to test it.

Children
Related