Sleep modes (System ON) example for nRF52833 with nRF Connect SDK 2.3.0

[ViktorVarjas]

Dear Support Team,

I recently started evaluating a nRF52833 DK board with the nRF Connect SDK 2.3.0. Could you please point me to a working example demonstrating how to configure and use the different sleep modes? I'm interested in the implementation of the various System ON modes described in the data sheet:

Thank you very much in advance and all the best,

Viktor

[Einar Thorsrud]

Hi,

Most nRF Connect SDK examples will enter system on Idle with full RAM retention and one RTC by default when in idle. You will need to disable logging first though, as if not the UART will be active, causing a high current consumption. For the majority of applications this is the sensible idle mode, and you will always need to keep the RTC active.

There are no examples that demonstrate the different RAM retention levels. However, if you want to, you can take a simple example (like hello world), disable logging, and change the linker configuration to use less RAM and update the RAM power control registers as explained in the product specification. There is no example for that either, but there is a related example demonstrating how to set up RAM retention in system OFF mode in the nRF5x System Off demo you can use as a reference.

[ViktorVarjas]

Hi Einar!

Thank you for the answer!

After disabling UART I see consumption corresponding to ON_RAMON_GPIOTE. (7.3uA)

My question would be how to configure the first 2 sleep modes: ON_RAMOFF_EVENT and ON_RAMON_EVENT.

The goal that I would like to reach is to find the lowest energy mode which has a short latency when switching to ACTIVE mode again. It can with or without RAM retention. The only only important parameters are:

- low latency (below 100 ms)

- low current

- RTC running

- GPIO interrupt handling active

Thank you in advance,

Viktor

[ViktorVarjas]

Hi Einar,

Thank you for the guidance, now I managed to achieve ~3uA with full RAM retention! I will just sum up here the steps that were needed to get there:

1, disable logging in the prj.conf file:

CONFIG_LOG=n
CONFIG_SERIAL=n

2, configuring gpio port event:

Interrupt configuration must be done with GPIO_INT_LEVEL_* flags instead of the GPIO_INT_EDGE_* flags. This was not trivial to find out...

#define IRQ_ACC_NODE	DT_ALIAS(accirq0)
const struct gpio_dt_spec sIRQ_pin = GPIO_DT_SPEC_GET_OR(IRQ_ACC_NODE, gpios, {0});

// configuring interrupt
gpio_pin_configure_dt(&sIRQ_pin, GPIO_INPUT);
gpio_pin_interrupt_configure_dt(&sIRQ_pin, GPIO_INT_LEVEL_ACTIVE);

All the best,

Viktor

[ViktorVarjas]

Actually, it doesn't seem to work fine... there is a very strange behaviour of the development kit, for which I will create a ticket soon and won't detail it here. The main thing is that after repowering the kit from a working state, it doesn't work anymore!

The code hangs at this call without return error, just running on full gas continuously:

gpio_pin_interrupt_configure_dt(&sIRQ_pin, GPIO_INT_LEVEL_ACTIVE);

This only happens when the pin is about to be configured in port event mode, when EDGE flags are chosen there is no issue.

Is there any project config that I'm missing here?

Thank you in advance,

Viktor

[Einar Thorsrud]

Hi Viktor,

gpio_pin_interrupt_configure_dt() should never block, and I cannot think of any configurations that should be relevant. for  Are you able to find anything by debugging? (If you have a separate case for this issue it may be better to continue just there tough, to avoid confusion).

Einar

[ViktorVarjas]

Hi Einar,

Somehow it still seems to block! I noticed that it is blocking when the pin is ACTIVE at the point of running the gpio_pin_interrupt_configure_dt() function. When I unplug the pin (back to INACTIVE) the execution continues...

All the best,

Viktor

[Einar Thorsrud]

Hi Viktor,

I am sorry for the late reply. I see from the other thread that the last issue is resolved.

Einar

[ViktorVarjas]

Hi Einar!

Yes, that thread is resolved, but the interrupt config function is still blocking when the pin is in the same level where the interrupt is to be configured...

But I found a workaround for my use-case.

All the best,

Viktor