High Deep Sleep Current Below 3.3V on XIAO MG24

Hello everyone,

I’m currently testing deep sleep on my Xiao MG24. Right now I’m measuring around 1.9 µA on the BAT pin at 3.7 V, which seems perfectly fine. Every measurement was taken using a Power Profiler Kit 2, with nothing connected to the MG24.

However, as soon as I lower the voltage to 3.2 V or below, the current consumption suddenly jumps up to around 450 µA. I’m seeing the exact same behavior when powering the board directly through the 3.3 V pin.

I’m slowly running out of ideas and would really appreciate some advice. Most examples I’ve found here in the forum seem to test only with voltages around 3.7–3.8 V. That’s obviously fine, but since the board is designed for battery operation, I would expect it to work properly down to around 3.0 V without causing issues. Otherwise, you basically lose the last 25-30% of a LiPo battery’s capacity.

Once the voltage reaches around 3.3 V, the board drains the battery quickly due to the increased current consumption.

As far as I understand, the board uses a TPS62843 DC buck converter. From the datasheet, I would expect it to simply transition into pass-through mode as the input voltage approaches the output voltage, rather than causing such a large increase in power consumption.

So my question is: am I missing something here, or can someone confirm whether this is actually normal behavior? Alternatively, is there perhaps a hardware modification that would allow proper battery operation below 3.3 V?

For testing, I used the following code provided by user Citric:

#include "ArduinoLowPower.h"

#define CS_PIN PA6
#define CLK_PIN PA0
#define MOSI_PIN PB0
#define MISO_PIN PB1

#define READ_DATA 0x03
#define WRITE_ENABLE 0x06
#define PAGE_PROGRAM 0x02
#define SECTOR_ERASE 0x20

void sendSPI(byte data) {
  for (int i = 0; i < 8; i++) {
    digitalWrite(MOSI_PIN, data & 0x80);
    data <<= 1;
    digitalWrite(CLK_PIN, HIGH);
    delayMicroseconds(1);
    digitalWrite(CLK_PIN, LOW);
    delayMicroseconds(1);
  }
}

void writeEnable() {
  digitalWrite(CS_PIN, LOW);
  sendSPI(WRITE_ENABLE);
  digitalWrite(CS_PIN, HIGH);
}

void setup()
{
  //Serial.begin(115200);
  pinMode(PA7, OUTPUT);
  digitalWrite(PA7, LOW);

  pinMode(CS_PIN, OUTPUT);
  pinMode(CLK_PIN, OUTPUT);
  pinMode(MOSI_PIN, OUTPUT);
  pinMode(MISO_PIN, INPUT);

  //SW
  pinMode(PD3, OUTPUT);//VBAT
  pinMode(PB5, OUTPUT);//RF_SW
  pinMode(PD5, OUTPUT);//IMU
  pinMode(PC8, OUTPUT);//MIC
  pinMode(PA6, OUTPUT);//FLASH
  digitalWrite(PD3, LOW); //VBAT
  digitalWrite(PB5, LOW); //RF_SW
  digitalWrite(PD5, LOW); //IMU
  digitalWrite(PC8, LOW); //MIC
  digitalWrite(PA6, HIGH);  //FLASH

  //Serial.println("Deep sleep timed wakeup");
  writeEnable();
  digitalWrite(CS_PIN, LOW);
  sendSPI(0xB9);
  digitalWrite(CS_PIN, HIGH);
}

void loop()
{
  delay(10000);  
  digitalWrite(PA7, HIGH);
  delay(500);

  //Serial.printf("Going to deep sleep for 10s at %lu\n", millis());

  // LowPower.idle(600000);        //EM1 TIM wake-up
  // LowPower.sleep(600000);       //EM2 TIM wake-up
  LowPower.deepSleep(600000);   //EM4 TIM wake-up
}

I would be very grateful for any help or suggestions.

Hi there,

So , I had similar experience, and turned out I was doing it wrong :grin:
the sudden jump in deep sleep current from 1.9 µA to ~450 µA when dropping below 3.3V is a classic symptom of reverse leakage current or an unconfigured power domain/peripherals leaking power back into the system.

Here are the most likely culprits for what is happening:

1. GPIO Pin Leakage & Peripherals Power Domains

The code shows you are explicitly setting several control pins low to turn off onboard peripherals (VBAT, RF_SW, IMU, MIC):

digitalWrite(PD3, LOW); // VBAT
digitalWrite(PB5, LOW); // RF_SW
digitalWrite(PD5, LOW); // IMU
digitalWrite(PC8, LOW); // MIC

However, when the main MCU power rail drops below 3.3V (e.g., to 3.2V or 3.0V), if any of these peripherals or pull-up resistors are still tied to a steady line or sitting at a slightly different potential, a current path opens up through the MCU’s internal ESD protection diodes.

  • The Test: Try explicitly setting all unused GPIOs to an analog high-impedance state (INPUT or INPUT_PULLDOWN / INPUT_PULLUP depending on the line) right before entering LowPower.deepSleep(). If a pin is held OUTPUT LOW but a peripheral is trying to pull it high (or vice-versa), it will bleed current.

2. The Flash Memory Chip (SPI)

In the setup, the code manually handles the SPI Flash:

writeEnable();
digitalWrite(CS_PIN, LOW);
sendSPI(0xB9); // Deep Power Down Command
digitalWrite(CS_PIN, HIGH);

While sending 0xB9 puts the Flash into Deep Power Down, the SPI pins themselves (CS, CLK, MOSI, MISO) remain configured as standard outputs/inputs. When the supply voltage drops, the voltage levels on PA6 (FLASH CS, held HIGH) or other pins might cross the logic threshold or input leakage specifications of the Flash chip, causing it to exit its low-power state or leak current internally.

3. The Buck Converter Behavior (TPS62843)

You mentioned expecting the TPS62843 to seamlessly transition into 100% duty cycle (pass-through) mode. While it does support this, entering pass-through mode changes its switching behavior:

  • If the battery voltage drops to 3.2V, the buck converter can no longer regulate to 3.3V and hits its dropout voltage limit.
  • In some circuit configurations, if there is an underlying tracking error, or if the converter begins to cycle rapidly trying to maintain regulation right at the threshold, it can cause an unexpected spike in quiescent current.
  • However, 450 µA is incredibly high for just the regulator’s dropout overhead, strongly implying the regulator is successfully passing the voltage through, but the lower voltage is causing a downstream chip (like the MG24 MCU itself or a peripheral) to misbehave or brown out into an undefined, high-current state.

Suggested Next Steps to Isolate the Issue:

  1. Isolate the MCU Pins: Modify the code right before LowPower.deepSleep(600000); to reconfigure the SPI pins (CS_PIN, CLK_PIN, MOSI_PIN) to INPUT or disable them entirely. If the SPI pins are floating or actively driving against a different voltage potential on the Flash chip, it will leak.
  2. Check Browser/Core Voltage Configuration: Ensure the MG24’s internal DC-DC converter or LDO configurations (managed by the Silicon Labs Gecko SDK underneath the Arduino layer) aren’t conflicting with the external supply dropping below 3.3V.
  3. Test in EM4 with Pins Fully Tri-stated: Try entering EM4 sleep without initializing any peripherals or pins in setup() at all to see if the voltage-drop current spike still occurs. If it doesn’t, it’s definitely a GPIO/peripheral leakage issue. (step 3 is how I figured it out)

I wold also double check the power domains you have used for different sensors connected to the device. Double check your GND, signals.

HTH
GL :slight_smile: PJ :v:

1 Like

This post covers the topic and issues.

1 Like

Mind Blown! (More Characters to Follow)

That is exactly my issue, thanks for pointing that out! This seems like a significant PCB design flaw, I can hardly imagine this behavior being intentional.

Unfortunately, the issue persists even when powering the board directly via the 3.3V pin. To achieve the low-power current of 1.95 µA specified in the datasheet, the board apparently has to be supplied through the VBUS pin with more than 3.4 V. Any lower voltage, or supplying power directly through the 3.3V pin, results in a sleep current of more than 450 µA.

That unfortunately makes the board unsuitable for my use case. I really wish this limitation had been documented in the specs.

1 Like

have you written to code to reset the pins before deep sleep? does this have any effect?

The power management from usb is not a boost/buck converter.. unput from usb is assumend to be 5v… i dont think it was ever designed to boost voltage only reduce… you can see how pushing 3v3 thru this circuitry would be counter productive… did you try powering from the 3v3 pin or the battery pads?

You are going to have to have a higher voltage to “push” the current thru… like a water tower presherized a city system

Sad to say that was the realisation I had, LiPo = Good, Coin Cell = Bad.

I ended up using the MGM240, more expensive but runs at 4uA on battery - plus multiple RF certifications.

Then a “battery fuel gauge” can be included, as well as low voltage cutoff.