STM32WLE5 (RAK3172) unable to reduce power consumption below 150uA in sleep (stop) mode with STM32CubeIDE

End Devices (Nodes) Hardware
1

I have created this simple project for the RAK3172 based on the STM32CubeIDE LoRaWAN end node skeleton (myIoTopenTech/TiposDeDispositivos/TTNMAD_SOUND/STM32CUBEIDE/ttnmad_noise at master · IoTopenTech/myIoTopenTech · GitHub).

The program works properly joining to The Things Network using OTAA and sending a dummy payload every 20 seconds… but in the interval between transmisions, the power consumption is about 150uA… I would expect something closer to 15 uA (that is what I get on the same hardware with a similar program developep using MbedOS).

I am using the RAK3272S breakout board, so there is nothing connected to the STM32WLE5, and the st-link is disconnected during power consumption measurements (all not used pins are configured as analog inputs and debug is disabled).

Has anybody got power consumptions in the order of 10uA?

renditionDownload

Kind regards from Madrid

1 Like
2

How does that match the fair access policy of TTN?

3

Dear @kersing It’s only a testing program…
The final node (if I suceed in solving this issue) will measure sound noise and send the average every hour.

4

Dear Officer, I was just trying out how fast my car could go …

When we start adding exceptions to the FUP, we end up without one, or more accurately, any TTN.

Maybe there is something in the code that’s different from your mBed program?

1 Like
5

So when you set the send interval to the planned one hour interval, was the sleep current circa 150uA over the whole hour ?

6

Silly me for working with TTN since 2015 and never noticing the rule that states you don’t have observe the fair access policy when you are just testing…

Have you checked the mbed initialisation code for controller pins not being used? The state unused pins are in can make quite a difference when sleeping in low power mode. Another thing to check, are both code bases using the same low power mode? And are all peripherals shut down?

2 Likes
7

When I start to deal with power I used to keep things simple at first, then adding features one by one.

Here below my mbed deep sleep test we made when created this PR for murata device.
you may notice there is the radio instance declared because we detected this one was consuming power even if not used (this may test bad init)

The is also compatible with LoRa-E5 and RAK3172 according selection of the correct target of course

#include "mbed.h"
#include <chrono>
using namespace std::chrono_literals;

#define CRLF "\r\n"

#if COMPONENT_SX1276
#include "SX1276_LoRaRadio.h"
SX1276_LoRaRadio radio(MBED_CONF_SX1276_LORA_DRIVER_SPI_MOSI,
                       MBED_CONF_SX1276_LORA_DRIVER_SPI_MISO,
                       MBED_CONF_SX1276_LORA_DRIVER_SPI_SCLK,
                       MBED_CONF_SX1276_LORA_DRIVER_SPI_CS,
                       MBED_CONF_SX1276_LORA_DRIVER_RESET,
                       MBED_CONF_SX1276_LORA_DRIVER_DIO0,
                       MBED_CONF_SX1276_LORA_DRIVER_DIO1,
                       MBED_CONF_SX1276_LORA_DRIVER_DIO2,
                       MBED_CONF_SX1276_LORA_DRIVER_DIO3,
                       MBED_CONF_SX1276_LORA_DRIVER_DIO4,
                       MBED_CONF_SX1276_LORA_DRIVER_DIO5,
                       MBED_CONF_SX1276_LORA_DRIVER_RF_SWITCH_CTL1,
                       MBED_CONF_SX1276_LORA_DRIVER_RF_SWITCH_CTL2,
                       MBED_CONF_SX1276_LORA_DRIVER_TXCTL,
                       MBED_CONF_SX1276_LORA_DRIVER_RXCTL,
                       MBED_CONF_SX1276_LORA_DRIVER_ANT_SWITCH,
                       MBED_CONF_SX1276_LORA_DRIVER_PWR_AMP_CTL,
                       MBED_CONF_SX1276_LORA_DRIVER_TCXO);
#elif (TARGET_STM32WL)
#include "STM32WL_LoRaRadio.h"
STM32WL_LoRaRadio radio;
#endif

DigitalOut  led1(LED1, 1);
DigitalOut  led2(LED2, 1);

EventQueue queue;

void led1_off() { led1 = 1; }
void led2_off() { led2 = 1; }
void led1_on()  { led1 = 0; }
void led2_on()  { led2 = 0; }

void led2_on_off() 
{
    led2 = 0;
    queue.call_in( 200ms, led2_off);
    queue.break_dispatch();
}

int main()
{
    mbed_file_handle(STDIN_FILENO)->enable_input(false);

    printf("--------------------------" CRLF);
    printf("-- MBED Deep Sleep Test --" CRLF);
    printf("--------------------------" CRLF);
    printf("--------------------------" CRLF);

    for (int i=0; i<5 ; i++) {
        printf(".ON.");
        led1_on();
        thread_sleep_for(100);
        printf(".OFF.");
        led1_off();
        thread_sleep_for(250);
    }
    printf(CRLF);

    queue.call_every(5s, led2_on_off);
    while (true) {
        queue.dispatch_forever();
        led1_on();
        printf("Event Wake" CRLF);
        thread_sleep_for(100);
        led1_off();
    }
}

Worth trying this one at first, also note that without schematics it’s difficult to help because it could be related to your hardware design.

As I said, I like to keep things simple, so I’m not using cube ide, too much pain for me to find where to change things to change code behavior

2 Likes
8

Dear @LoRaTracker
Yes, with longer idle times there is also an average consumption of 150-200uA
imagen

9

Thank you very much @Charles

Yes, with Mbed I’ve been able to reach below-10uA consumptions, but now I need DMA and that is not easy with Mbed, so I switched to STM32CubeIDE, and I agree it’s a pain to understand the code.

The hardware I’m using is the RAK3272 breakout board (just a RAK3172 with the SWD and power pins).

Kind regards

1 Like
10

So with that setup, what is the power consumption in sleep mode, with a bit of code that only implements sleep mode and no LoRa device connected ?

1 Like
11

Finally some progress…
Tying the RX pin of USART2 to GND reduces de power consumption to 1.5uA.
177712695-e3395fcb-dd06-438a-ae37-bf4b743d6821
Otherwise, even configuring the USART2 for only transmissions, takes 150uA (probably noise in RX pin is awakening the microcontroller).
image

Enabling the internal pull-down in that pin has the same consumption reduction effect.
image

5 Likes
12

So that means you not only need to initialize unused pins but used (input) pins as well. Nice catch.

1 Like
13

Same results (low power consumption) configuring UART pins with pull-ups, as stated in UM2642
imagen

1 Like