Minimizing the power draw using System OFF and RAM retention

RE: Minimizing the power draw using System OFF and RAM retention

lhochstetter — Fri, 14 Dec 2018 16:06:41 GMT

Hi Håkon,

thanks for the link and hints!

I'll mark your 'quick and dirty' solution as answer as it was quite helpful.

Kind regards,

lhochstetter

RE: Minimizing the power draw using System OFF and RAM retention

Håkon Alseth — Tue, 11 Dec 2018 09:56:24 GMT

Hi lhochstetter,

Glad to hear that it worked.

You do not need to set the "POWER_RAM_POWER_S1POWER_On" field, as it is already set (reset value is '1').

Regarding the .ld scripts and syntax, this is given by the toolchain: https://sourceware.org/binutils/docs/ld/Scripts.html

You may find better ways of describing the linker scripts, I'd recommend searching around and checking on stack overflow etc. to see if you can find any resources there.

Kind regards,

Håkon

RE: Minimizing the power draw using System OFF and RAM retention

lhochstetter — Mon, 10 Dec 2018 17:06:05 GMT

Hi Håkon,

it just works (tm)! Thank you!

I took a closer look at your .ld and .c files and noticed some differences:

In the .ld file you "included" the no_init declaration in the section which was to be "inserted after .text" (if I understand the .ld file correctly). I used the "spare" section at the very beginning without the "INSERT AFTER ..." command.

I therefore suspect that my main issue was the no_init declaration at the wrong section.

In the .c file / in the main function you "only enabled RAM retention" and did not touch the "POWER_RAM_POWER_S1POWER_On register" at all.

One more question: could you provide me with a couple terms to research, so I can properly understand the .ld files syntax / notation?

Thanks again!

Kind regards,

lhochstetter

RE: Minimizing the power draw using System OFF and RAM retention

Håkon Alseth — Mon, 10 Dec 2018 09:06:07 GMT

Hi,

I integrated the previous example into ble_app_beacon (quick and dirty, my apologies), here's the main file and linker file (SDK v15.2):

devzone.nordicsemi.com/.../ble_5F00_app_5F00_beacon_5F00_gcc_5F00_nrf52.ld

devzone.nordicsemi.com/.../main.c

I didn't have any problems running this code, it loops through the LEDs like it should. Could you try this and see if that works?

Kind regards,

Håkon

RE: Minimizing the power draw using System OFF and RAM retention

Bluesky — Mon, 10 Dec 2018 03:55:05 GMT

Hi wpaul,

Do you mean I connect to OpenOCD for debugging? Actually my problem is to find out how to get the current draw from the nrf52832 to be 0.7uA when it is in SYSTEM OFF. But I can only get 1.7uA when I flash the code above into it.

Thank you very much!

RE: Minimizing the power draw using System OFF and RAM retention

wpaul — Fri, 07 Dec 2018 18:41:01 GMT

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

(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.

RE: Minimizing the power draw using System OFF and RAM retention

lhochstetter — Fri, 07 Dec 2018 17:31:35 GMT

Hi,

thanks for the link, I tried to merge your example (the gcc one) with mine, but sadly it didn't work out i.e. the value was not retained. Again I'm trying to only save the second slave of the 7th RAM tile.

Code snippets:

uint32_t j __attribute__((section(".no_init"))) __attribute__((used));

int main(void)
{
	// Initialize.
	gpio_init();
	ble_stack_init();

	sd_power_ram_power_set(7, (POWER_RAM_POWER_S1POWER_On << POWER_RAM_POWER_S1POWER_Pos)
		                | (POWER_RAM_POWER_S1RETENTION_On << POWER_RAM_POWER_S1RETENTION_Pos));

	if (0 == nrf_gpio_pin_read(BSP_BUTTON_0)) {
		nrf_drv_gpiote_out_clear(BSP_LED_0);
	}

	if (3 == j) {
		nrf_drv_gpiote_out_clear(BSP_LED_2);
		j = 0;
	}

	j++;
	nrf_delay_ms(1000);
	nrf_drv_gpiote_out_set(BSP_LED_0);
	nrf_drv_gpiote_out_set(BSP_LED_2);
	sd_power_system_off();

	for(;;) {
		idle_state_handle();
	}

}

My linker file (based on the original ble_app_beacon) which I tied to merge with the linker file provided in your example.

/* Linker script to configure memory regions. */

SEARCH_DIR(.)
GROUP(-lgcc -lc -lnosys)

MEMORY
{
  FLASH (rx) : ORIGIN = 0x26000, LENGTH = 0x5a000
  RAM (rwx) :  ORIGIN = 0x200018a8, LENGTH = 0xd758
  NO_INIT (rwx) :  ORIGIN = 0x2000F000, LENGTH = 0x1000
}

SECTIONS
{
  .no_init (NOLOAD):
  {
    PROVIDE(__start_no_init_data = .);
	KEEP(*(SORT(.no_init*)))
	PROVIDE(__stop_no_init_data = .);
  } > NO_INIT
}

SECTIONS
{
  . = ALIGN(4);
  .mem_section_dummy_ram :
  {
  }
  .log_dynamic_data :
  {
    PROVIDE(__start_log_dynamic_data = .);
    KEEP(*(SORT(.log_dynamic_data*)))
    PROVIDE(__stop_log_dynamic_data = .);
  } > RAM
  .cli_sorted_cmd_ptrs :
  {
    PROVIDE(__start_cli_sorted_cmd_ptrs = .);
    KEEP(*(.cli_sorted_cmd_ptrs))
    PROVIDE(__stop_cli_sorted_cmd_ptrs = .);
  } > RAM
  .fs_data :
  {
    PROVIDE(__start_fs_data = .);
    KEEP(*(.fs_data))
    PROVIDE(__stop_fs_data = .);
  } > RAM

} INSERT AFTER .data;

SECTIONS
{
  .mem_section_dummy_rom :
  {
  }
  .sdh_soc_observers :
  {
    PROVIDE(__start_sdh_soc_observers = .);
    KEEP(*(SORT(.sdh_soc_observers*)))
    PROVIDE(__stop_sdh_soc_observers = .);
  } > FLASH
  .sdh_ble_observers :
  {
    PROVIDE(__start_sdh_ble_observers = .);
    KEEP(*(SORT(.sdh_ble_observers*)))
    PROVIDE(__stop_sdh_ble_observers = .);
  } > FLASH
  .pwr_mgmt_data :
  {
    PROVIDE(__start_pwr_mgmt_data = .);
    KEEP(*(SORT(.pwr_mgmt_data*)))
    PROVIDE(__stop_pwr_mgmt_data = .);
  } > FLASH
  .log_const_data :
  {
    PROVIDE(__start_log_const_data = .);
    KEEP(*(SORT(.log_const_data*)))
    PROVIDE(__stop_log_const_data = .);
  } > FLASH
    .nrf_balloc :
  {
    PROVIDE(__start_nrf_balloc = .);
    KEEP(*(.nrf_balloc))
    PROVIDE(__stop_nrf_balloc = .);
  } > FLASH
  .sdh_state_observers :
  {
    PROVIDE(__start_sdh_state_observers = .);
    KEEP(*(SORT(.sdh_state_observers*)))
    PROVIDE(__stop_sdh_state_observers = .);
  } > FLASH
  .sdh_stack_observers :
  {
    PROVIDE(__start_sdh_stack_observers = .);
    KEEP(*(SORT(.sdh_stack_observers*)))
    PROVIDE(__stop_sdh_stack_observers = .);
  } > FLASH
  .sdh_req_observers :
  {
    PROVIDE(__start_sdh_req_observers = .);
    KEEP(*(SORT(.sdh_req_observers*)))
    PROVIDE(__stop_sdh_req_observers = .);
  } > FLASH
    .nrf_queue :
  {
    PROVIDE(__start_nrf_queue = .);
    KEEP(*(.nrf_queue))
    PROVIDE(__stop_nrf_queue = .);
  } > FLASH
    .cli_command :
  {
    PROVIDE(__start_cli_command = .);
    KEEP(*(.cli_command))
    PROVIDE(__stop_cli_command = .);
  } > FLASH
  .crypto_data :
  {
    PROVIDE(__start_crypto_data = .);
    KEEP(*(SORT(.crypto_data*)))
    PROVIDE(__stop_crypto_data = .);
  } > FLASH

} INSERT AFTER .text

INCLUDE "nrf_common.ld"

Sorry for making you basically hold my hand but I'm fairly ignorant when it comes to the SDK and how things work / are compiled ... is there by chance an introduction / tutorial which explains the SDK structure etc. ? (I'm also at a loss when it comes to tracking down function definitions etc.)

I tried to compile your example but it kept complaining, that some files where missing - the ../../config directory does not seem to be in the .zip. I'm also guessing that your example was written with an older SDK version as system_nrf52.c seems to have changed places.

Kind regards,

lhochstetter

RE: Minimizing the power draw using System OFF and RAM retention

Bluesky — Thu, 06 Dec 2018 09:40:39 GMT

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 🙂

RE: Minimizing the power draw using System OFF and RAM retention

Håkon Alseth — Thu, 06 Dec 2018 09:33:11 GMT

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

RE: Minimizing the power draw using System OFF and RAM retention

Bluesky — Thu, 06 Dec 2018 02:25:57 GMT

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?

RE: Minimizing the power draw using System OFF and RAM retention

Håkon Alseth — Wed, 05 Dec 2018 15:47:25 GMT

Hello,

[quote user="lhochstetter"]Another question in the very same project popped up: I'm seeing 15-20mV spikes in intervals of around 45ms when advertising / when sd_app_evt_wait() is running.[/quote]

These are due to the regulator refresh mode: https://devzone.nordicsemi.com/f/nordic-q-a/20121/periodic-current-during-waiting-event

I assume you're using a 10 ohm resistor (1.5 to 2 mA) to monitor the current.

[quote user="lhochstetter"]However, RAM retention doesn't (again using above shown snippets). I'm trying to retain the entire RAM of the nRF52832, but it seems that my for loop doesn't do it's job. I tried to only set the 7th RAM tile (both sections) but to no avail.

What am I missing?[/quote]

Pointing to a specific address is not a recommended approach, as you do not know if there's anything there already, like the .stack or .heap section. See this thread and the linked threads for more information on ram retention after system off:

https://devzone.nordicsemi.com/f/nordic-q-a/36848/nrf52840-ram-retention-example-fails-with-max_test_iterations-1

Kind regards,

Håkon

RE: Minimizing the power draw using System OFF and RAM retention

lhochstetter — Tue, 04 Dec 2018 14:57:22 GMT

Hi,

waking up from Sytem OFF using following snippets works just fine, thanks alot!

static void gpio_init(void)
{
	ret_code_t err_code;

	err_code = nrf_drv_gpiote_init();
	APP_ERROR_CHECK(err_code);

	nrf_drv_gpiote_out_config_t out_config = GPIOTE_CONFIG_OUT_SIMPLE(true);
	err_code = nrf_drv_gpiote_out_init(BSP_LED_0, &out_config);

	APP_ERROR_CHECK(err_code);
	err_code = nrf_drv_gpiote_out_init(BSP_LED_2, &out_config);

	nrf_gpio_cfg_sense_input(BSP_BUTTON_0, NRF_GPIO_PIN_PULLUP, NRF_GPIO_PIN_SENSE_LOW);
}

void main()
{
	uint32_t j = ((uint32_t *) (0x2000F000))[0];

	// Initialize.
	gpio_init();
	ble_stack_init();
    for (int i = 0; i < 8; i++) {
    	sd_power_ram_power_set(i,
    		                  (POWER_RAM_POWER_S0POWER_On << POWER_RAM_POWER_S0POWER_Pos)
    		                | (POWER_RAM_POWER_S1POWER_On << POWER_RAM_POWER_S1POWER_Pos)
    		                | (POWER_RAM_POWER_S0RETENTION_On << POWER_RAM_POWER_S0RETENTION_Pos)
    		                | (POWER_RAM_POWER_S1RETENTION_On << POWER_RAM_POWER_S1RETENTION_Pos));
    }
	if (0 == nrf_gpio_pin_read(BSP_BUTTON_0)) {
		nrf_drv_gpiote_out_clear(BSP_LED_0);
	}

	if (3 == j) {
		nrf_drv_gpiote_out_clear(BSP_LED_2);
		j = 0;
	}

	j++;
	((uint32_t *) (0x2000F000))[0] = j;

	nrf_delay_ms(1000);

	nrf_drv_gpiote_out_set(BSP_LED_0);
	nrf_drv_gpiote_out_set(BSP_LED_2);

	sd_power_system_off();


	for(;;) {
		sd_app_evt_wait();
	}
}

However, RAM retention doesn't (again using above shown snippets). I'm trying to retain the entire RAM of the nRF52832, but it seems that my for loop doesn't do it's job. I tried to only set the 7th RAM tile (both sections) but to no avail.

What am I missing?

Another question in the very same project popped up: I'm seeing 15-20mV spikes in intervals of around 45ms when advertising / when sd_app_evt_wait() is running.

Could it be that some scanning related code is running in the background / softdevice in between advertisements? (I've largely adapted the ble_peripheral / ble_app_beacon example, but I'd argue that the scanning functionality isn't configured / started).

Kind regards,

lhochstetter

RE: Minimizing the power draw using System OFF and RAM retention

Håkon Alseth — Mon, 03 Dec 2018 12:50:24 GMT

Hi,

Systemoff will generate a reset when you wake up, so the simplest logic is to check your GPIOs upon init, or reading the NRF_GPIO->LATCH register:

gpio_init();
// Check the GPIO states to see which one is still active
if (nrf_gpio_pin_read(my_pin) == ACTIVE_LEVEL) {
    do_something();
}

// Alternative is to read NRF_GPIO->LATCH register.
// See http://infocenter.nordicsemi.com/topic/com.nordic.infocenter.nrf52832.ps.v1.1/gpio.html#register.LATCH
// Write '1' to bitfields in register to clear it.

[quote user="lhochstetter"]When I use this snippet the system freezes up again and the voltage rises to a couple hundred mV (without I measure <20 mV when idling). Judging by the existance of the sd_power_ram_power_*() functions I assume that you have to use those to configure RAM retention but my attempts so far failed.[/quote]

When the softdevice is enabled, you shall not write directly to the NRF_POWER register, as this will create a fault-condition. You should rather use the sd_ prefixed function call. You can write the exact same bit pattern into the sd_power_ram_power_* function as you would to the NRF_POWER->RAMON register.

Kind regards,

Håkon

RE: Minimizing the power draw using System OFF and RAM retention

lhochstetter — Fri, 30 Nov 2018 16:18:56 GMT

Hi,

thanks for the input, going to System OFF and waking up to the GPIO interrupts works!

The remaining issues are the RAM retention and the "GPIO detection" (i.e. which GPIO is responsible for the interrupt).

---

I tried to adapt the approach taken in the ble_app_pwr_profiling example, namely bsp_board_button_state_get(...) but to no avail.

I would like to also connect an ISR to the GPIO interrupt if it takes place while the system is active / not in System OFF (I guess that I'll have to do the (ISR) configuration each time the system wakes up again). Therefore I've configured the GPIOs like so:

nrf_drv_gpiote_in_config_t in_config = GPIOTE_CONFIG_IN_SENSE_HITOLO(false);
in_config.pull = NRF_GPIO_PIN_PULLUP;
err_code = nrf_drv_gpiote_in_init(BSP_BUTTON_0, &in_config, button_handler);
APP_ERROR_CHECK(err_code);
nrf_drv_gpiote_in_event_enable(BSP_BUTTON_0, true);

How do I determine which GPIO woke up the system?

---

I tried to merge my current code with the peripheral / ram_retention example:

    NRF_POWER->RAMON |= (POWER_RAMON_OFFRAM0_RAM0On << POWER_RAMON_OFFRAM0_Pos) |
                        (POWER_RAMON_OFFRAM1_RAM1On << POWER_RAMON_OFFRAM1_Pos);

When I use this snippet the system freezes up again and the voltage rises to a couple hundred mV (without I measure <20 mV when idling). Judging by the existance of the sd_power_ram_power_*() functions I assume that you have to use those to configure RAM retention but my attempts so far failed.

From what I have gathered I may have to adapt the .ld file and add something like no_init memory sections.

Am I on the right way / are there any "more elaborate" examples regarding RAM retention with the S132 softdevice present?

Kind regards,

lhochstetter

RE: Minimizing the power draw using System OFF and RAM retention

Håkon Alseth — Wed, 28 Nov 2018 10:26:54 GMT

Hi,

1 mA is too high. it should be ~1 uA in system off, given that there's no LEDs or similar that is on in sleep. Your GPIOs are latched when entering sleep mode, so it is important that you set these to a defined level, or disconnect them in firmware (setting NRF_GPIO->PIN_CNF[] field "CONNECT" to 0).

You could add system off to any example, after a given time/event has occurred (per your application requirement).

Here's an example for a active low button:

nrf_gpio_cfg_sense_input(MY_PIN, NRF_GPIO_PIN_PULLUP, NRF_GPIO_PIN_SENSE_LOW);
err_code = sd_power_system_off();
APP_ERROR_CHECK(err_code);

Kind regards,

Håkon

RE: Minimizing the power draw using System OFF and RAM retention

lhochstetter — Tue, 27 Nov 2018 12:51:03 GMT

Hi,

sorry for the belated reply. I tried your suggestion (the board did go to some sort of power saving mode, drawing ~1mA but was unresponsive afterwards).

I spent some time studying the ble_app_pwr_profiling example. In the example two functions are used to go to the System OFF mode:

nrf_pwr_mgmt_shutdown(NRF_PWR_MGMT_SHUTDOWN_GOTO_SYSOFF)

and

sd_power_system_off()

Since sd_power_system_off() is used in the ble_evt_handler() I assume that this function is used when the Softdevice is / was active. nrf_pwr_mgmt_shutdown(NRF_PWR_MGMT_SHUTDOWN_GOTO_SYSOFF) is used otherwise.

Right now I'm trying to gut the ble_app_pwr_profiling example to get a simple non-connectable beacon which reacts to button presses, advertising the button pressed and the count of button presses, and returning to System OFF afterwards.

EDIT

I'm not debugging / There is no debugger attached

/EDIT

Best,

lhochstetter

RE: Minimizing the power draw using System OFF and RAM retention

Håkon Alseth — Mon, 12 Nov 2018 13:46:38 GMT

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