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.

[hallard]

I have had a break-through and am now getting down to 7uA!

Wow impressed, I think you're very close. It's the first time I see that changing SPI pins before sleep has an effect on sleep mode consumption (I mean with this module I remember the need on doing that with custom boards with RFM95). I had same thing for CS Line. Did you tried to put it in HI-Z mode instead?

The grumpyoldpizza does not change state of these pins before sleep and it works,, correct?

By the way if there is another device on SPI bus it may affect it not but it's out of the scope of this issue of course.

[evandavey]

I think GrumpyOldPizza does change these pins, and so does I-CUBE-LRWAN (see e.g. Drivers/BSP/SX1262DVK1CAS/sx1262dvk1cas.c).

static void SX1262DVK1CAS_RADIO_SPI_IoDeInit(void)
{
  GPIO_InitTypeDef GPIO_InitStruct;

  /* Peripheral clock disable */
  /* no need to call SPI1_CLK_DISABLE() because going in LowPower it gets disabled automatically */

  /* DeInitialize Peripheral GPIOs */
  /* Instead of using HAL_GPIO_DeInit() which set ANALOG mode
     it's preferred to set in OUTPUT_PP mode, with the pins set to 0 */

  GPIO_InitStruct.Mode = GPIO_MODE_OUTPUT_PP;
  GPIO_InitStruct.Pull = GPIO_PULLDOWN;
  GPIO_InitStruct.Pin = RADIO_SPI_MOSI_GPIO_PIN;
  HAL_GPIO_Init(RADIO_SPI_MOSI_GPIO_PORT, &GPIO_InitStruct);
  GPIO_InitStruct.Pin = RADIO_SPI_MISO_GPIO_PIN;
  HAL_GPIO_Init(RADIO_SPI_MISO_GPIO_PORT, &GPIO_InitStruct);
  GPIO_InitStruct.Pin = RADIO_SPI_SCK_GPIO_PIN;
  HAL_GPIO_Init(RADIO_SPI_SCK_GPIO_PORT, &GPIO_InitStruct);

  HAL_GPIO_WritePin(RADIO_SPI_MOSI_GPIO_PORT, RADIO_SPI_MOSI_GPIO_PIN, GPIO_PIN_RESET);
  HAL_GPIO_WritePin(RADIO_SPI_MISO_GPIO_PORT, RADIO_SPI_MISO_GPIO_PIN, GPIO_PIN_RESET);
  HAL_GPIO_WritePin(RADIO_SPI_SCK_GPIO_PORT, RADIO_SPI_SCK_GPIO_PIN, GPIO_PIN_RESET);
}

static void SX1262DVK1CAS_RADIO_SPI_IoInit(SPI_HandleTypeDef *spiHandle)
{
  GPIO_InitTypeDef GPIO_InitStruct;
  /* USER CODE BEGIN SPI1_MspInit 0 */

  /* USER CODE END SPI1_MspInit 0 */
  /* Enable Peripheral clock */
  RADIO_SPI_SCK_GPIO_CLK_ENABLE();
  RADIO_SPI_MOSI_GPIO_CLK_ENABLE();
  RADIO_SPI_MISO_GPIO_CLK_ENABLE();

  /**SPI1 GPIO Configuration
  PA5     ------> SPI1_SCK
  PA6     ------> SPI1_MISO
  PA7     ------> SPI1_MOSI
    */
  GPIO_InitStruct.Mode = GPIO_MODE_AF_PP;
  GPIO_InitStruct.Pull = GPIO_PULLDOWN;
  GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_VERY_HIGH;

  GPIO_InitStruct.Alternate = RADIO_SPI_MOSI_GPIO_AF;
  GPIO_InitStruct.Pin = RADIO_SPI_MOSI_GPIO_PIN;
  HAL_GPIO_Init(RADIO_SPI_MOSI_GPIO_PORT, &GPIO_InitStruct);
  GPIO_InitStruct.Alternate = RADIO_SPI_MISO_GPIO_AF;
  GPIO_InitStruct.Pin = RADIO_SPI_MISO_GPIO_PIN;
  HAL_GPIO_Init(RADIO_SPI_MISO_GPIO_PORT, &GPIO_InitStruct);
  GPIO_InitStruct.Alternate = RADIO_SPI_SCK_GPIO_AF;
  GPIO_InitStruct.Pin = RADIO_SPI_SCK_GPIO_PIN;
  HAL_GPIO_Init(RADIO_SPI_SCK_GPIO_PORT, &GPIO_InitStruct);
}

I noticed that hal_deepsleep() is declared weak in TARGET_STM/sleep.c so have attempted to implement a custom deinit and init function (like above) before/after sleep but weirdly this doesn't behave as expected and I see very high current or no impact. But this might be the most promising place to put it as it doesn't require extending the driver.

[evandavey]

@hallard

Can you please confirm your test measurement setup? I am seeing an average of about 620uA on a SeeedStudio LoRa E5 Mini using your code from https://github.com/ARMmbed/mbed-os-example-lorawan/issues/227#issuecomment-885491038 and mbed-os-example-lorawan as the starter project.

I am using the target files from https://github.com/ARMmbed/stm32customtargets with the LORA_E5_MINI target.

I am measuring power using a Nordic PPK2 powering the board at 3.3V via the 3.3V pin and GND. Nothing else is connected.

I am compiling using GCC_ARM (GNU ARM 9-2019-q4-major) and with the Release profile.

Interestingly, I get an MBED error code when compiling using the Develop profile.

++ MbedOS Error Info ++
Error Status: 0x80FF0144 Code: 324 Module: 255
Error Message: Assertion failed: error_value == HAL_OK
Location: 0x80022DD
File: ./mbed-os/connectivity/drivers/lora/TARGET_STM32WL/STM32WL_LoRaRadio.cpp+770
Error Value: 0x0
For more info, visit: https://mbed.com/s/error?error=0x80FF0144&tgt=LORA_E5_MINI
-- MbedOS Error Info --

[hallard]

I confirm code mentioned (basic no full sample LoRawan not tested yet) consumption. Take care LoRa E5 mini have all usb stuff on board including usb serial chip connected to uart. depending on type and if this chip powered or not it could draw some current same as on board regulator where you apply 3.3v on it output

[evandavey]

I had a look at the schematic and I think the USB circuitry is only powered when 5V is present. The assert above has me thinking the radio isn't getting into sleep mode due to some error. What mbed-os commit are you using? Are you compiling with GCC_ARM?

I have some spare LoRa E5 modules so I might dead-bug connect them just to rule out USB. Looks like I just need 10uF, 4.7uF, 100n caps on VCC to replicate your board.

[evandavey]

I made a dead-bug board. I have broken out VCC,GND,SWCLK, SWDIO, NRST. VCC and GND have a 1u and 100nF capacitor on as short leads as possible. Nothing else is broken out or connected. Using the LORA E5 MINI as the target, I am still getting the same results as the actual mini. I haven't connected the UART or a LED so I can't actually prove the code is running aside from that it programs and current matches.

@hallard - perhaps you could send me your compiled binary and I can test that?

[hallard]

So even with only LoRa-E5 nothing else except caps (no regulator of course) you still have the issue? I can try back and give the compiled code but not today as I got so much other things to finish before.

[evandavey]

@hallard - no worries, whenever you can. Yes, just the LoRa-E5 powered by the Nordic PPK2 @ 3.3V.

[hallard]

Ok took some time here, used latest master from https://github.com/ARMmbed/mbed-os https://github.com/ARMmbed/stm32customtargets

then use this code (as release of course)

mbed_app.json

{
    "requires": ["bare-metal", "events", "lora", "mbedtls", "stm32wl-lora-driver"],
    "target_overrides": {
        "*": {
            "target.printf_lib": "std"
        }
    }
}

custom_targets.json

{
    "LORA_E5": {
        "inherits": [
            "MCU_STM32WLE5xC"
        ],
        "device_name": "STM32WLE5JCIx"
    },
    "LORA_E5_BREAKOUT": {
        "inherits": [
            "LORA_E5"
        ],
        "macros_add": [
            "LED1=PB_5", 
            "LED2=PB_10",
            "BUTTON1=PB_13"
        ]
    }
}

Connected as follow

Powering with

and tadaaaaaa 1.5uA

Please note the 3mA peaks (mainly some OS wake) an if I put them into the selection I have average of 7.5uA

Hope this helps

[evandavey]

@hallard - thank you. Very odd, our different results and almost identifcal setups. I have installed MBED Studio and will try compiling with that tomorrow (very late here) and see if that changes anything.

[hallard]

Here the compiled file if you want to give a try mbed-os-deepsleep-test.bin.zip

[evandavey]

Some progress. On the bare E5 board, your binary and a version I compiled using MBED studio matches your results! However, unplugging the debugger, current jumps to about 100uA - are you seeing the same result?

I also started a new blank project outside MBED studio and compiled with GCC_ARM and this also matches so not sure what was happening before.

Same code uploaded to the E5 Mini is 620uA. It's possible this is the USB, but I am still suspicious it's related to GPIOs or that assert error.

[hallard]

Some progress. On the bare E5 board, your binary and a version I compiled using MBED studio matches your results! However, unplugging the debugger, current jumps to about 100uA - are you seeing the same result?

humm not sure I tested removing debugger while running but sure that running it while no debugger connected on start was also 1.5uA

Same code uploaded to the E5 Mini is 620uA. It's possible this is the USB, but I am still suspicious it's related to GPIOs or that assert error.

usb has only 3 wires connected, gnd tx and rx correct? and both connected directly to E5 rx, tx ? But may be you are right I’m using ch340 usb/serial may be Ftdi one or cp21xx has an issue with that need to try that

[evandavey]

Removing debugger or running with no debugger connected on start gives me 100uA but I will double-check the latter (which is the concern - I don't care about 100uA from the debugger if we can get 2uA in normal deep sleep). Debugger is not active btw, just connected to SWCLK and SWDIO and plugged in to USB - might check what happens to these pins on the scope.

They use a CP2102N for USB/UART and connect rx,tx and rst. But this should only be powered if 5V present. I have also asked Seeed if they have instructions on how to measure current.

[evandavey]

No debugger on start-up does give me 7uA average after-all, so looking promising. I will try to hook up an antenna for a full-test and hope that meanwhile Seeed report back on the E5 mini.

[hallard]

7uA Average is same than my measure :-)

[evandavey]

Yeah, I know :) Need to implement a full test to be sure, then we know at least one chip works. Would be great to get the others working too, Type ABZ, Type 1SJ, STM32L0 + RFM95.

[evandavey]

Seeed recommended removing the 5V->3.3V regulator (U2) and the two resistors connecting tx/rx (R3/R4) to the CP2102N. With just the regulator removed, I am now seeing 7uA average (~2uA min) so I will attempt a full LoRa test now with this board.

[hallard]

Humm means that you had leak current going from your 3.3v rail going thru the regulator. Remind me one message earlier in this thread 😋

[evandavey]

And success! 2uA in sleep following an uplink. It does beg the question what is different about this target versus the others - newer radio driver that handles the GPIOs?

[hallard]

STM32WL does not have an external radio chip such as SX12.. the radio is directly integrated into the STMWL32 chip. But this does not solve issue for murata device indeed.

[evandavey]

And yep, does look like a leak through the regulator on that board, nice pick-up 👍

[evandavey]

Murata + I have had similar issues with the Draguino which is STM32L0 + external RFM95W. And the OP who was having issues with an external board as well. But at least some real-world proof that LoRa on MBED is feasible with at least one chip.

[hallard]

And yep, does look like a leak through the regulator on that board, nice pick-up 👍

Yeah as rule 1 in low power is “everything connected may be source of leak current”, and this is so true for every connected chip even if they are not powered. Regulators are for output current/voltage depending on it’s design applying input (3.3v) to it’s output may at worse fry it, leak current or may be just nothing.

[hallard]

Murata + I have had similar issues with the Draguino which is STM32L0 + external RFM95W. And the OP who was having issues with an external board as well. But at least some real-world proof that LoRa on MBED is feasible with at least one chip.

Yeah but I’m on another project where I need murata to be to 2uA like with grumpyoldpizza framework so if team could solve this low power issue would be fine

[evandavey]

Certainly something with the init/deinit of pins, and the TCXO control, so at least we've discovered that. I wish they would separate out the MBED specific stuff from the driver stuff so that the driver logic could be kept up-to-date with the Semtech (or other) reference implementation. Kind of what they are moving to with HAL layer in https://github.com/Lora-net/sx126x_driver but looks like a lot of work to implement that with the current MBED way of doing things.

[hallard]

Yeah and lorawan stack in current implementation is 1.0.2 so behind LoRa Mac node current version 1.0.4 and 1.1.0 hope they will be able to update the stack

[hallard]

@evandavey I've done some testing with old Murata board (STM32L0 + SX1276), deep sleep without declaring Radio instance works at 2/3uA as expected, but as soon as I declare the radio instance (even not using it) I'm not low powering

Quick investigation shows that there is no control of txco off in radio.sleep() but it's present on loramac-node implementation.

loramac-node radio sleep/standby implementation

void SX1276SetSleep( void )
{
    TimerStop( &RxTimeoutTimer );
    TimerStop( &TxTimeoutTimer );
    TimerStop( &RxTimeoutSyncWord );

    SX1276SetOpMode( RF_OPMODE_SLEEP );

    // Disable TCXO radio is in SLEEP mode
    SX1276SetBoardTcxo( false );

    SX1276.Settings.State = RF_IDLE;
}

void SX1276SetStby( void )
{
    TimerStop( &RxTimeoutTimer );
    TimerStop( &TxTimeoutTimer );
    TimerStop( &RxTimeoutSyncWord );

    SX1276SetOpMode( RF_OPMODE_STANDBY );
    SX1276.Settings.State = RF_IDLE;
}

mbed radio sleep implementation

void SX1276_LoRaRadio::sleep()
{
    // stop timers
    tx_timeout_timer.detach();

    // put module in sleep mode
    set_operation_mode(RF_OPMODE_SLEEP);
}

void SX1276_LoRaRadio::standby(void)
{
    tx_timeout_timer.detach();

    set_operation_mode(RF_OPMODE_STANDBY);
    _rf_settings.state = RF_IDLE;
}

I managed tcxo in driver like loramac-node implementation but I did not succeeded to go below 400uA. loramac-node has also de init antenna stuff here and gpio de init also but only for DIO pins and SPI CS pin here that can be interesting

If anyone has an idea of why we can't go below, we take it.

[evandavey]

@hallard - thanks, that agrees with my analysis and the key seems to be the init/deinit code which I could never get working. I've also built a board to test out the AcSIP ST50H http://www.acsip.com.tw/index.php?action=products-detail&fid1=19&fid2=&fid3=&id=151 which should hopefully function the same as the E5 module. Had some board design issues so fixing them up now for testing hopefully in a few weeks.

[hallard]

@evandavey I tried to change the SX1272 driver (for murata) with GPIO reconfiguration on the fly You can check changes on this branch if you want to give a try but It did not changed anything on my side, driving me crazy.

Mainly I put the GPIO to type digitalInOut so I can change them in the set_low_power_mode according same pins as grumpyoldpizza. So very little changes but does not works.

/**
 * Sets the module in low power mode by disconnecting
 * TX and RX submodules, turning off power amplifier etc.
 */
void SX1276_LoRaRadio::set_low_power_mode(bool status)
{

    if (radio_is_active != status) {
        radio_is_active = status;

        if (status == true) {

            _chip_select.input();

            if (_rf_ctrls.rf_switch_ctl1 != NC) {
                _rf_switch_ctl1.input();
            }

            if (_rf_ctrls.rf_switch_ctl2 != NC) {
                _rf_switch_ctl2.input();
            }

            if (_rf_ctrls.pwr_amp_ctl != NC) {
                _pwr_amp_ctl.input();
            }

            if (_rf_ctrls.txctl != NC) {
                _txctl.input();
            }

            if (_rf_ctrls.rxctl != NC) {
                _rxctl.input();
            }

            if (_rf_ctrls.ant_switch != NC) {
                _ant_switch.input();
            }

            if (_rf_ctrls.tcxo != NC) {
                _tcxo.input();
            }

        } else {

            _chip_select.output();
            _chip_select = 1;

            if (_rf_ctrls.pwr_amp_ctl != NC) {
                _pwr_amp_ctl.output();
                _pwr_amp_ctl = 0;
            }

            if (_rf_ctrls.rf_switch_ctl1 != NC) {
                _rf_switch_ctl1.output();
                _rf_switch_ctl1 = 0;
            }

            if (_rf_ctrls.rf_switch_ctl2 != NC) {
                _rf_switch_ctl2.output();
                _rf_switch_ctl2 = 0;
            }

            if (_rf_ctrls.txctl != NC) {
                _txctl.output();
                _txctl = 0;
            }

            if (_rf_ctrls.rxctl != NC) {
                _rxctl.output();
                _rxctl = 0;
            }

            if (_rf_ctrls.ant_switch != NC) {
                _ant_switch.output();
                _ant_switch = 0;
            }

            if (_rf_ctrls.tcxo != NC) {
                _tcxo.output();
                _tcxo = 1;
                ThisThread::sleep_for(5);
            }
        }

    }
}

[evandavey]

@hallard - have you pushed up changes in that repo? Not seeing your commits. From when I was testing, I was seeing some power impact deintiing the SPI pins but could never work out how to reinit them. I was trying calling the STM32 HAL calls rather than using MBED initially just to see if that would work. So copy/pasting the relevant init/deint sections from the STM32 Cube LoRaWAN libraries.

[hallard]

This was un unpushed commit sorry, now it's done, but I did not touched SPI pins for now, may be next step de init SPI.

[evandavey]

@hallard - I have just built up a couple of Seeed LoRa E5 based boards and have done a real-world test. Over about 620m from node to gateway (RSSI ~-125-135, SNR: -13-14.5 but urban area with no line of sight and node indoors) so that's looking promising. Sampling (UART based) sensors including using mbed trace and sending via TTN. Seeing ~50uA in sleep but it's installed in a 3rd party carrier board so could be leakage there and 50uA 'good enough for Australia' (as Dave from the EEVBlog would say). Still trying to read VBAT using the ADC but otherwise seems good. Waiting on some AcSIP ST50H chips so I can test those too using the same platform.

[hallard]

@evandavey you still want to sleep at 3uA on Murata with mbed 6? Looks like we looked at the wrong place with GPIO, I don't know how my partner found this one but looks like misconfiguration of DIO registers :-) just try this branch fix and let me know https://github.com/hallard/mbed-os/tree/LORA_SX1276_LP_Fix

[hallard]

@evandavey you still want to sleep at 3uA on Murata with mbed 6? Looks like we looked at the wrong place with GPIO, I don't know how my partner found this one but looks like misconfiguration of DIO registers :-) just try this branch fix and let me know https://github.com/hallard/mbed-os/tree/LORA_SX1276_LP_Fix

[IoTopenTech]

And success! 2uA in sleep following an uplink. It does beg the question what is different about this target versus the others - newer radio driver that handles the GPIOs?

Dear @evandavey I'm not able to reduce power consumption below 1.5mA with a RAK3172 (STM32WLE5C), similar to E5, using mbed-os-example-lorawan

Please, could you share how to configure Mbed to get 2uA. Kind regards

By the way, regarding reading de Vbat, I have done it using this code:

uint16_t vref_cal; double vdd_calibed; double vref_calibed; vref_cal = *(__IO uint16_t *)((uint32_t)0x1fff75aa); vref_calibed = 3.3f * (double)vref_cal / 4096.0f; AnalogIn bat(ADC_VREF); vdd_calibed = vref_calibed / bat.read();

[evandavey]

@IoTopenTech - no special configuration should be needed for the E5/STM32WLE5C using the latest mbed/drivers other than making sure you are not building a debug build. Have you tried the bare minimum code used by Charles above (using https://github.com/ARMmbed/stm32customtargets for the target)?

https://github.com/ARMmbed/mbed-os-example-lorawan/issues/227#issuecomment-889130873

I had some leakage from other components (power regulator) that could also be your issue. Thanks for the VBAT code - this is very similar to what I ended up using:

uint16_t ekidna_hal_vbat_mv(void)
{

    // Read the internal voltage calibration
    float vref_cal = 3.3 * ((*((uint16_t *)VREFINT_CAL_ADDR)) / 4096.0);
    // Read the internal voltage reference
    float vref = adc_vref.read_voltage();
    // Read the raw vbat voltage
    float vbat = adc_vbat.read_voltage();
    // Adjust vbat using calibrated VREF and the protection diode voltage drop.
    vbat = (vbat * (vref_cal / vref) * 3) + VBAT_ADJUST;
    // Return adjusted vbat in milli-volts
    return vbat * 1000;
}

[evandavey]

@hallard - thanks for the Murata info. Will try this when I get a chance.

[IoTopenTech]

Thank you very much @evandavey Problem solved. It was probably a soldering issue.

Now I am getting 2.5uA after uplink.

[hallard]

And success! 2uA in sleep following an uplink. It does beg the question what is different about this target versus the others - newer radio driver that handles the GPIOs?

As we though initially with @evandavey it was a matter of GPIO but did not tried to reconfigure GPIO on SX1276 side, magic to do was on SX1276_LoRaRadio.cpp done by @mickael868

        /* FIXME taken from set_modem, it reduces the power consumption
         *from 300µA to 1.5µA */
        write_to_register(REG_DIOMAPPING1, 0x00); // sets DIO0-DI03 in default mode
        write_to_register(REG_DIOMAPPING2, 0x30); // bits 4-5 are turned on i.e.,

[evandavey]

@hallard - will dig up an old Murata ABZ based board to test and report back. The Type 1SJ uses a SX126X radio so exploring how to do the equivalent.

[carriegong]

Any news on this. Working on a project and seeing large sleep current for a similar board.

[evandavey]

@carriegong - which board/radio in particular?

[carriegong]

@evandavey Custom Murata ABZ. I do not tick lora_fsm from start. Until some user input... But on sleep without ticking lora_fsm it seems to draw 3.4mA oddly. Can't seem to find what. Disabled all GPIO/ all inits.. and still the same. Seems like something else in radio needs to be off.

[evandavey]

@carriegong - not sure what you mean by ticking lora_fsm? But a few things to check/try:

1. Try the @hallard build above https://github.com/hallard/mbed-os/tree/LORA_SX1276_LP_Fix
2. Ensure you are building for Release not Debug
3. Try calling

   mbed_file_handle(STDIN_FILENO)->enable_input(false);

4. Try a bare minimum example (where radio is declared, then the queue is dispatched and nothing else - see examples above).
5. Try disconnecting a debugger if you have one connected

[carriegong]

@evandavey Like this lora_fsm I am using stm32 code. not mbedOS

[evandavey]

@carriegong - the info here is mostly mbed specific so not sure how much help it will be as results vary significantly by framework due to implementation differences (which can be very hard to compare/audit). Have you tried https://github.com/GrumpyOldPizza/ArduinoCore-stm32l0? (see https://github.com/ARMmbed/mbed-os-example-lorawan/issues/227#issuecomment-885499468) or even the Loramac reference implementation https://github.com/Lora-net/LoRaMac-node?

[JenertsA]

@evandavey would you be so kind sharing full LoRa test code I am starting out with LoRa on MbedOs and the only okay example is the official example.

Currently I am able to produce bare-bones low-power test but can't figure out the full picture. I am particularly interested in code used for this test:

And success! 2uA in sleep following an uplink. It does beg the question what is different about this target versus the others - newer radio driver that handles the GPIOs?

[evandavey]

@JenertsA - I will try to dig out the exact code I used, but it was pretty much the example in this repo but built for an E5/STM32WLE5C (using https://github.com/ARMmbed/stm32customtargets). What is the exact target/gateway combo you are trying?

[JenertsA]

@evandavey I am using a custom RAK3172 board and RAK3172 target from previously mentioned smt32customtargets. the end goal is to make a device that reads I2C sensors and sends data ower LoRaWAN to TTN. For the most part, I just need to spend some time digging through the example code to understand how the all mbedOs lorawan thing works. A bit steep learning curve coming here from 8bit MCUs with simple C++ without many files and APIs around it.