Can not reach low power state when radio is declared outside of main()

[charlesmodrich-tc]

Description of defect

Inability to enter sleep mode (or at least reach expected sleep mode average current) after calling
static LoRaWANInterface lorawan(radio); when working with NRF52840-DK + SX1262MB2xAS mbed shield

even when building with Develop profile. Results in average "sleep" current of ~6.5mA. Uncommenting all code before main() (except for above line) and removing all code except sleep_for within main() yields expected sleep current (~14uA).

Target(s) affected by this defect ?

NRF52840-DK

Toolchain(s) (name and version) displaying this defect ?

Mbed Studio 1.4.0

What version of Mbed-os are you using (tag or sha) ?

6.3.0

What version(s) of tools are you using. List all that apply (E.g. mbed-cli)

Mbed CLI 2

How is this defect reproduced ?

Set up 2 NRF52840 DK's: one with PowerProfilerKit, another with SX1262MB2xAS mbed shield. Connect both to PC via microUSB (not nRF USB). Have PPK DK power LoRa shield DK via External supply, switch power on LoRaDK ON, nRF ONLY switch, VEXT->nRF switch to ON. Load up nRF Connect utility for the power profiler kit application, and enable DUT power and monitoring.

Use the default example for this sketch, but remove most of the code such that all that remains looks as below:

#include <stdio.h>

#include "lorawan/LoRaWANInterface.h"
#include "lorawan/system/lorawan_data_structures.h"
#include "events/EventQueue.h"

// Application helpers
#include "SX126X_LoRaRadio.h"
SX126X_LoRaRadio radio(D11,//MOSI
                       D12,//MISO
                       D13,//SCK
                       D7,//CS/NSS
                       A0,//RESET
                       D5,//DIO1
                       D3,//BUSY
                       A1,//FREQ_SEL
                       A2,//DEV_SEL
                       A3,//XTAL_SEL
                       D8);//ANT_SW

#include "mbed.h"

//DigitalOut led1(LED1);
using namespace events;
uint8_t tx_buffer[30];
uint8_t rx_buffer[30];
#define TX_TIMER                        20000
#define MAX_NUMBER_OF_EVENTS            10
#define CONFIRMED_MSG_RETRY_COUNTER     3
#define PC_9                            0

static EventQueue ev_queue(MAX_NUMBER_OF_EVENTS *EVENTS_EVENT_SIZE);
static void lora_event_handler(lorawan_event_t event);
static lorawan_app_callbacks_t callbacks;

static LoRaWANInterface lorawan(radio);

int main()
{       
rtos::ThisThread::sleep_for(1000);
}

change the following in mbed_app.json:

"target_overrides": { "*": { "platform.stdio-convert-newlines": true, "platform.stdio-baud-rate": 115200, "platform.default-serial-baud-rate": 115200, "lora.over-the-air-activation": true, "lora.duty-cycle-on": false, "lora.phy": "US915", "lora.device-eui": "{ 0x00, 0x80, 0xA0, 0xD0, 0x09, 0xEA, 0x82, 0x37 }", "lora.application-eui": "{ 0x70, 0xB3, 0xD5, 0x7E, 0xD0, 0x03, 0xE4, 0x02 }", "lora.application-key": "{ 0xEE, 0xB6, 0x72, 0x7D, 0xEB, 0x52, 0x08, 0x1C, 0x2E, 0x32, 0xC4, 0x3B, 0xB8, 0x96, 0x86, 0x6D }", "target.components_add": ["SX126X"], "lora.app-port": 2, "lora.fsb-mask": "{0xFF00, 0x0000, 0x0000, 0x0000, 0x0002}" },

"macros": ["MBEDTLS_USER_CONFIG_FILE=\"mbedtls_lora_config.h\"", "MBED_TICKLESS=1"]

Now, compile, upload and compare the average currents when static LoRaWANInterface lorawan(radio); is commented, and uncommented. For me, results for commented are ~14uA average sleep current over 52ms period, while uncommented shows an average sleep current of approximately 6.5mA over 52ms period.

[ciarmcom]

Thank you for raising this detailed GitHub issue. I am now notifying our internal issue triagers.
Internal Jira reference: https://jira.arm.com/browse/IOTOSM-3922

[evandavey]

@charlesmodrich-tc I have similar issues in #222. Did you find a solution? For tcxo control, I am exploring modifying the set_operation_mode call in the driver i.e. set to 0 when RF_OPMODE_SLEEP otherwise 1. But that still leaves a high residual ~300uA.

[charlesmodrich-tc]

Unfortunately no, I wasn't able to find a solution. Ultimately I was forced to move away from Mbed OS for this reason since I wasn't able to get the low current performance all of my devices would require.

…

-- Charles Modrich | Senior Hardware Engineer TeraCode | 405 Cochituate Road | Suite 205 | Framingham MA 01701 M: 847-951-7543 | F: 781-207-0724 http://www.teracode.com | LinkedIn <https://www.linkedin.com/in/charlesmodrich/>

On Sat, Jun 26, 2021 at 4:58 AM Evan Davey ***@***.***> wrote: @charlesmodrich-tc <https://github.com/charlesmodrich-tc> I have similar issues in #222 <#222>. Did you find a solution? For tcxo control, I am exploring modifying the set_operation_mode call in the driver i.e. set to 0 when RF_OPMODE_SLEEP otherwise 1. But that still leaves I high residual. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#227 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ARXQAUS7K7DS4CDEOWWATCDTUWQDTANCNFSM435LKRXQ> .

[evandavey]

@charlesmodrich-tc - very frustrating.

[charlesmodrich-tc]

It really is! I spent a lot of time and hope on this before giving up.

[evandavey]

Yes, have been in the same boat! Having to revert back to the manufacturer SDKs is its own path of pain given all the messy #defines to support multiple targets and tight coupling of business logic to SDK logic. It's a shame support resources for MBED seem to have dropped off recently and it is stuck being half a corporate project and half an open source project with neither seeming to have particularly strong momentum.

[evandavey]

@charlesmodrich-tc - I have been doing some more debugging, this time on a Murata ISJ dev board (link). This is a STM32L072 + SX126X radio. With the Murata supplied AT firmware, I measure this board at the expected 2uA, so I know this is the baseline. I am using a new example from scratch, but using the master branch of mbed-os (as I needed to make some non power related changes to the SX126X driver).

With the code below, I am able to achieve an average of 50uA. Interestingly, if I power up the board (which puts the radio to sleep), then re-upload the code with the radio.sleep() line commented out, current falls to 11uA, which is very similar to the 14uA you measured. I think this is related to GPIO/peripheral configuration in sleep but I haven't been able to figure out why, or where I am losing 9uA relative to the AT firmware.

mbed_app.json

{
  "requires": [
    "bare-metal",
    "events",
    "storage",
    "spif-driver",
    "lora",
    "mbedtls",
    "sx1276-lora-driver",
    "SX126X-lora-driver"
  ],
  "target_overrides": {
    "*": {
      "target.macros_add": ["MBED_TICKLESS"],
      "target.lpticker_lptim": 0
    },
    "MURATA_TYPE1SJ_EVB": {
      "SX126X-lora-driver.freq-support": "MATCHING_FREQ_915",
      "SX126X-lora-driver.device-variant": "SX1262"
    }
  }
}

main.cpp

#include "mbed.h"
#include "events/EventQueue.h"
#include "radio.h"
#include "SX126X_LoRaRadio.h"

#define MAX_NUMBER_OF_EVENTS 20

static EventQueue ev_queue(MAX_NUMBER_OF_EVENTS *EVENTS_EVENT_SIZE);

SX126X_LoRaRadio radio(LORA_SPI_MOSI,
                       LORA_SPI_MISO,
                       LORA_SPI_SCLK,
                       LORA_SPI_CS,
                       LORA_RESET,
                       LORA_DIO1,
                       LORA_BUSY,
                       LORA_FREQ_SELECT,
                       LORA_DEVICE_SELECT,
                       LORA_CRYSTAL_SELECT,
                       LORA_ANT_SWITCH);

int main(void)
{

    radio.sleep();
    ev_queue.dispatch_forever();
}

[jeromecoutant]

  "target.lpticker_lptim": 0

This is not tested, not validated, so not recommended...
Keep the default configuration

[evandavey]

@jeromecoutant - this line saves about 30uA . At the moment my objective is to just get current down to 2uA with nothing running, then start adding back functionality to be able to do a full LoRaWAN test so I'll admit I've been trying things such as that line without fulling understanding the impact. The 2uA firmware is written in https://www.st.com/en/embedded-software/i-cube-lrwan.html but I find the structure such a headache to deal with.

[hallard]

That's interesting because I wanted to post a comment this night but went to bed before. In the meantime conversation has new comments.
I'm currently switching to mbed for my lorawan E5 and RAK3172 board because it's really nice simple with lot of features and this lorawan example works.
But my next step is to go to low power testing and seing this makes me feel inconfortable because the goal of LoRaWAN device is to be low lower. I'm going to 1.5uA with old murata one on custom code without mbed so 11uA or 50uA is not an option on my side.
Would be interesting to have @jeromecoutant, or @MarceloSalazar on this point, in the meantime I will give some tries on my boards.