lorawan_start() with CONFIG_LORAWAN_NVM_SETTINGS=y does not put radio to sleep

[lff5]

Problem

When CONFIG_LORAWAN_NVM_SETTINGS=y, lorawan_start() calls lorawan_nvm_data_restore() which configures the radio (causing supply current to be 0.5 mA instead of ~2.7 uA for our board). The current consumption goes down after first join packet. I would expect the peripherals to be guaranteed to sleep after first init.

Following screenshot shows stack trace where radio is configured (which actually causes the current to go up). Paused debugger consumes 10,4 mA on my board, it stays on 10.6 mA after this radio configuration.

Workaround

As a workaround I am calling Radio.Sleep() right after lorawan_start(). Current without debugger ~2.7 uA, with paused debugger 10.4 mA.

Environment

Using NRF Connect SDK 2.6.1 on nRF52832 + SX1261 custom board. M2 mac with Ventura 13.3.

Steps to reproduce the behaviour:

open class_a sample project, add CONFIG_PM_DEVICE=y add 10 sec delay before lorawan_join() function to see the initing effect more clearly. Build and run. Current consumption should be few uA during 10sec delay for nRF devices. This is normal - expected behaviour.

Add following configs: CONFIG_LORAWAN_NVM_SETTINGS=y CONFIG_FLASH=y CONFIG_FLASH_PAGE_LAYOUT=y CONFIG_FLASH_MAP=y CONFIG_NVS=y CONFIG_SETTINGS=y Build and run. Current consumption should be higher during 10sec delay (after lorawan_start() and before lorawan_join()). The current should drop with first join packet, since it puts the radio into sleep mode.

[github-actions[bot]]

Hi @lff5! We appreciate you submitting your first issue for our open-source project. 🌟

Even though I'm a bot, I can assure you that the whole community is genuinely grateful for your time and effort. 🤖💙

[aescolar]

This issue seems to relate to Nordic's Connect SDK. If the issue is present in Zephyr please provide the information requested in the bug template so the it can be reproduced in upstream Zephyr without NCS. Otherwise please file the issue downstream instead.

[lff5]

I believe its still zephyrs issue, not NCS. My code is slightly modified example from zephyr/samples/subsys/lorawan/class_a.

Steps to reproduce

Launch lorawan/class_a example

Add following to CMakeLists.txt target_include_directories(app PRIVATE $ENV{ZEPHYR_BASE}/../modules/lib/loramac-node/src/radio)

Add following to prj.conf

# for low power
CONFIG_PM_DEVICE=y
CONFIG_RTT_CONSOLE=y
CONFIG_SERIAL=n
CONFIG_UART_CONSOLE=n

# for lora NVM settings
CONFIG_LORAWAN_NVM_SETTINGS=y
CONFIG_FLASH=y
CONFIG_FLASH_PAGE_LAYOUT=y
CONFIG_FLASH_MAP=y
CONFIG_NVS=y
CONFIG_SETTINGS=y

Add radio include into main.c #include <radio.h>

Add following code around lorawan_start() in main.c

        // sleep before initing radio
        k_sleep(K_SECONDS(4));

    ret = lorawan_start();
    if (ret < 0) {
        LOG_ERR("lorawan_start failed: %d", ret);
        return 0;
    }

        // sleep after initing radio to see increased currents
    k_sleep(K_SECONDS(6));

    Radio.Sleep();

        // sleep after Radio.Sleep() to prove it has an effect, current dropped.
    k_sleep(K_SECONDS(10));

build and flash.

Expected Behavior

4 seconds of some uninitialised current before lorawan_start() 6 seconds of low current since lora radio is inited 10 sec of same current since radio is inited

Actual behavior

4 seconds of some uninitialised current before lorawan_start() - 216 uA (on nRF52DK + SX1261MB2xAS DK). 6 seconds of some current (lorawan initialized, but radio not put to sleep properly) - stable 224 uA 10 sec of lower current than the previous (now radio is truly forced to sleep) - stable 216 uA

Note. On custom board i can get currents down to 2.7 uA, with DK I didn't have time to to get currents low (near 2.7 uA), but i still see a clear and reproducible jump in current consumption.

Now setting CONFIG_LORAWAN_NVM_SETTINGS=n and we have expected behavior.

Here are the board overlay files I used: board_overlay.zip

[lff5]

See https://github.com/Lora-net/LoRaMac-node/issues/1594. It seems to be LoRaMACs issue, but the repo is stale, so maybe fixing it on zephyr's side?