Deep sleep power consumption ~6 mA on NUCLEO_L476RG (deep sleep ~6 µA on original mbed OS)

[xillion]

Hi all,

I have recently switched from the official Mbed OS (where deep sleep measured as low as ~6 µA) to the community fork (mbed‑os‑CE) on a NUCLEO_L476RG board.

However, when I run the same code on CE, deep sleep current only drops to about 6 mA—rather than the expected microamp-level. I’ve confirmed the original Mbed OS achieves ≈6 µA deep sleep.

Here’s a minimal repro:

#include "LowPowerTicker.h"
#include "mbed.h"
#include <cinttypes>
#include "ResetReason.h"
DigitalIn   my_sw(BUTTON1);
DigitalOut  myled(LED1,0);

LowPowerTicker   ticker;
EventFlags       wakeupEvents;
#define LPT_WAKEUP_EVENT1  0x00
#define LPT_WAKEUP_EVENT2  0x01
#define LPT_WAKEUP_EVENT3  0x02

Thread threadFirst(osPriorityNormal, 1024);
Thread threadSecond(osPriorityNormal, 1024);

void sw_irq(void);
void threadFirstWorker();
void threadSecondWorker();

int main()
{
    threadFirst.start(threadFirstWorker);
    threadSecond.start(threadSecondWorker);
    ticker.attach(&sw_irq, 10s); // 10 seconds
    
    while (true) {
        sleep_manager_can_deep_sleep();
        wakeupEvents.wait_all(LPT_WAKEUP_EVENT1);

        for(int i=0; i<10; i++) {
            myled = 1;
            ThisThread::sleep_for(10ms);
            myled = 0;
            ThisThread::sleep_for(500ms);
        }
    }

}


void threadFirstWorker(){
    wakeupEvents.wait_all(LPT_WAKEUP_EVENT2);
            for(int i=0; i<10; i++) {
            myled = 1;
            ThisThread::sleep_for(500ms);
            myled = 0;
            ThisThread::sleep_for(1000ms);
        }
}

void threadSecondWorker(){
    wakeupEvents.wait_all(LPT_WAKEUP_EVENT3);
            for(int i=0; i<10; i++) {
            myled = 1;
            ThisThread::sleep_for(1000ms);
            myled = 0;
            ThisThread::sleep_for(1000ms);
        }
}

void sw_irq(void)
{
    static uint8_t count = 0;
    wakeupEvents.set((count++)%3);
    ticker.attach(&sw_irq, 20s);
}

And my mbed_app.json:
{ "target_overrides": { "*": { "target.console-uart": false, "target.retarget-console": false, "platform.stdio-buffered-serial": 0, "platform.callback-nontrivial": false, "target.tickless-from-us-ticker": false, "target.lse_available": 1, "target.lpticker_lptim_clock": 64, "target.macros_add": ["MBED_TICKLESS"], "target.device_has_add": ["DEVICE_LPTICKER"] } } }
Environment:
mbed‑os‑CE (latest master branch)
mbed‑os 6.17
NUCLEO_L476RG
Original Mbed OS (exact same code/config) deep sleep ≈6 µA
CE: deep sleep ≈6 mA

I’ve applied sleep_manager_can_deep_sleep() before wait, use LowPowerTicker, and disabled console UART. I’ve also tried enabling sleep tracing (MBED_SLEEP_TRACING_ENABLED) but haven’t identified any active deep-sleep locks yet.

Could someone help me identify:

1. What could be holding the board out of deep sleep in the CE fork?
   

2. Any additional debug steps (e.g., CPU stats, sleep tracer) or missing configuration flags that CE might require?
   

3. Suggestions on how to measure or confirm deep sleep transitions (e.g., lock trace, mbed_stats_cpu, hardware measurement tips)?
   

Thank you in advance!

[JohnK1987]

Hello @xillion and thank you for your message.
Some important things are missing in your environment list I think.

• Which build profile do you have set when you do the measurement? Again regular Mbed has ussually set Release profile as default with their tools (Mbed Studio, Keil Studio Cloud) because of more effective result of binary (max optimization). However in MbedCE it is up to you which build profile do you set. So if you have set Debug build profile the Sleep will be disabled - https://os.mbed.com/docs/mbed-os/v6.16/program-setup/build-profiles-and-rules.html.
• Which tool do you use with the regular Mbed? Most ARM tools (Mbed Studio, Keil Studio Cloud and so on) are using ARM Compiler 6 in default. However Mbed is using GCC only because license of AC6 is not free of charge without ARM Mbed tools!

We need to compare an apple with apple so be sure you compile with GCC (ideally with same version) and also with same build profile on both platforms (ARM Mbed / MbedCE).

Or am I wrong? @multiplemonomials

BTW this macro is default for whole STM32L4 family.

"target.macros_add": ["MBED_TICKLESS"],

BR, Jan

[xillion]

@JohnK1987 Thanks for your reply!

Yes, you’re right - I forgot to provide information about the build profile. In both cases I used the Release profile and GCC 13.3.1 as the default compiler. I’m aware that the Debug profile disables the sleep functionality.

In regular Mbed, I use Mbed Studio/mbed cli 1, and during the migration I switched the compiler to gcc.

The same compiler I use for Mbed CE

[multiplemonomials]

Hmm, to be honest, I have not had much experience with deep sleep debugging. Your minimal example is much appreciated however!

Basic question but do we know if the chip is entering deep sleep at all? Like if you lock deep sleep and run the example vs don't lock deep sleep, is there any change in the current consumption?

[wdx04]

Hello @xillion,

I tested your code with exactly the same configuration on my NUCLEO-L476RG board and measured the power consumption using a multimeter(a new one arrived today).
I have cut off the ST-LINK part and removed the power LED from my NUCLEO-L476RG board.
The power consumption of the board is only 24μA when the MCU is in deep sleep, and can go up to 3.5mA in run mode.

l476.mp4

[JohnK1987]

For this purpose is JP6 (IDD) jumper on the board where you can measure what a current the MCU draw.

[wdx04]

For this purpose is JP6 (IDD) jumper on the board where you can measure what a current the MCU draw.

Tested on JP6(IDD), the power consumption is only 2.1-2.2μA when the LED is not flashing.

[xillion]

I apologize for misleading all of you. It took me a few days to figure out why.

What I did wrong:
I connected both boards to a PC (Ubuntu 22.04) one I flashed through mbed studio and the other stm32cubeprogrammer (for mbed-ce).
I measured the consumption on the LDD pins. After each flashing I pressed the reset button. The project in both cases was built in “release” mode.
But on the board that was flashed through mbed studio the consumption in deep sleep mode did not exceed 3µA, and the other one was about 6mA. As it turned out later, the connected st-link debugger was to blame. It somehow sucked energy from the board.
When I tested on my custom boards(flashing over DFU) in both cases everything worked as it should and consumption did not exceed 7µA. This is what prompted me to dig further. To prevent the debugger from sucking power you just need to reconnect the USB cable.

[multiplemonomials]

Oh dang, that's an annoying issue! But I'm glad you were able to figure it out, and I'm glad to hear that Mbed CE doesn't have worse deep sleep performance!