Light / Deep Sleep Current Comparison of XIAO_MG24 and XIAO_nRF52840

I compared the sleep current between the newly released MG24 and the nRF52840, which is well known for its low current consumption. I hope this will be helpful.

Measurements were taken by applying 3.8V to the battery pad on the back of the device and using ppk2. Sleep current is very sensitive to temperature, so I kept the room temperature at 25°C as much as possible.
The BSP was “Seeed nRF52 Borads 1.1.8” and “Silicon Labs 2.2.0”, and I only did as much as I could with ArduinoIDE.

The results show that the MG24 is slightly smaller in DeepSleep current, but overall the nRF52840 is by far the superior device.
The results may change with adjustments specific to each device. Please let me know if you have any information.

1 Like

Hi there,

Probably one of the more important threads to read here on this it is Very interesting to See these results and I am equally interested in the “Wake-UP” from sleep states these are resets to Wake or Timer the latter right. SO what mechanisms for wake-Up are available?

I couldn’t find a External Pin Method INFO for it. only timer?
As always Thanks for the results to this most important area of concern. I do like the M33 cores and All that efficiency but not if it doesn’t MEET or EXCEED the nRF52840 current levels would I dare to recommend it.
They should have at least made that a benchmark in Function and Performance, I find it Ironic that the BATTERY reading and Interrupts as well as the sleep and BOOT mode info were “mis informed”
:lying_face:

GL :slight_smile: PJ :v:

Thank you for your continued investigation of this Device and it’s nuances :laughing:

There is an example of an external pin wake-up on the Examples, which worked well.
It is hard to find the wake-up requirements in the datasheet because there are multiple low power levels.

1 Like

On the nrf52840 I only could do External Pin wake-up . Now with the MG24 I can use timer based wake-up. And I agree the nrf52840 is overall better

Hi there,

So , I was able to get it working TIMER SLEEP and EXTernal wake up but not like the other Xiao’s at all.
"LowPower.attachInterruptWakeup(WAKEUP_PIN, nullptr, FALLING); "
Has got to be the lamest technique I have ever seen…

#include <Arduino.h>
#include <ArduinoLowPower.h>

#define WAKEUP_PIN PC0       // 
#define LED_PIN LED_BUILTIN  // Onboard LED (active LOW on MG24)
#define SLEEP_TIMEOUT 30000  // 30 seconds

unsigned long startTimeoutTime = 0;

void wakeUp() {
  // This function is called on wake-up.
  // (In deep sleep, the board resets so this handler isn’t used.)
}

void setup() {
  Serial.begin(115200);
  while (!Serial) {
    ; // Wait for serial connection
  }
  Serial.println("MG24 is awake!");

  // Configure LED pin: LOW turns it ON (awake), HIGH turns it OFF (sleep)
  pinMode(LED_PIN, OUTPUT);
  digitalWrite(LED_PIN, LOW);  // LED ON when awake

  // Configure the wake-up pin with internal pull-up.
  pinMode(WAKEUP_PIN, INPUT_PULLUP);

  // Attach an interrupt wake-up on FALLING edge.
  //LowPower.attachInterruptWakeup(digitalPinToInterrupt(WAKEUP_PIN), wakeUp, FALLING); // this works only once. never sleeps again. But is great for others.
  LowPower.attachInterruptWakeup(WAKEUP_PIN, nullptr, FALLING);
  Serial.println("Starting up. Will sleep after 30 seconds unless the wake-up pin is pulled LOW.");
  startTimeoutTime = millis();
}

void loop() {
  if (millis() - startTimeoutTime >= SLEEP_TIMEOUT) {
    Serial.println("30 seconds elapsed. Preparing to enter deep sleep...");

    // Turn LED OFF (active LOW so HIGH turns it off)
    digitalWrite(LED_PIN, HIGH);

    Serial.flush();
    delay(100);

    // Enter deep sleep.
    LowPower.deepSleep();
    // LowPower.deepSleep(30000); this killed it with the external pin wakeup enabled also for some reason?
    // When the board wakes, it will reset and run setup() again.
  }
}

It never drops the serial port connection (like the Nrf52840 when asleep), so I’m skeptical of it. You can only use PC0, The timed wakeup ,after a few uploads changing pins , timers etc… , Bricked it, WON’t accept any more uploades. WHAT A BAG OF ROCKS… this MCU is junk IMO. It’s just sleeping and waking up instantly but won’t upload anymore. Thsi MCU is for blinking LED’s ONLY IMO. LOL

HTH
GL :slight_smile: PJ :v:

A FEW Hours Later :dizzy_face:

Yea, DON’t do it this way…Everything was working sort of until I tried the example and used the nullptr, instead of the Wake_up function call (that was empty anyway) Seems the chip doesn’t handle the reset properly when it’s LAME code. FAZOUL.
In summary, using nullptr isn’t inherently “bad,” but you need to ensure that it’s acceptable for your use case and supported by the library. If the library expects a function pointer for proper wake-up behavior, replacing nullptr with a valid callback (even an empty one) is the right approach. Someone needs to tell them at SIL.
:-1:

@msfujino - Again thanks for the excellent information!

I have been doing some testing here (on MG24) and get

  • ~16mA when running (EM0).
  • ~334uA when Idling (EM1).
  • ~254uA when Sleeping (not sure on this sleep (if EM2) - as is just using a vtaskdelay!). Seems quite high, as with Simplicity Studio I get ~15uA in EM2.
  • ~4uA when Deep Sleeping (EM4) with either timed or GPIO wake.

Sleep current seems a little high,

  1. What volt power supply is connected where?
  2. Are peripherals such as FLASH, IMU, MIC, VBAT, RFSW, etc. turned off?
  3. What is the room temperature?
  1. 3V3 (MCU, USB disconnected).
  2. Yes, Not installed, Not installed, VBat-Should be?, Yes.
  3. 35C in Australia today!

I was getting ~1uA without GPIO wake (Pin retention set) so may recheck that.

Just checked VBAT_CTL and it is low…

The following is for turning off peripherals.

// on board peripherals pins
#define IMU_EN   PD5   // (19)
#define MIC_EN   PC8   // (22)
#define VBAT_EN  PD3   // (25)
#define RFSW_EN  PB5   // (27)

  // on board peripherals
  pinMode(IMU_EN, OUTPUT);
  pinMode(MIC_EN, OUTPUT);
  pinMode(VBAT_EN, OUTPUT);
  pinMode(RFSW_EN, OUTPUT);
  digitalWrite(IMU_EN, LOW);   // IMU Power OFF
  digitalWrite(MIC_EN, LOW);   // MIC Power OFF
  digitalWrite(VBAT_EN, LOW);  // VBAT Power OFF
  digitalWrite(RFSW_EN, LOW);  // RFSW Power OFF

I think the leakage current of the Schottky diode PSBD2FD40 is very sensitive to temperature and may be more than 5uA at 35°C.

If 3.3V is applied to the 3V3 pin, the leakage current of the Schottky diode would not occur, so it would be about 1uA.

1 Like

This is a pretty serious problem, sorry everyone, I’m late. I understand that the XIAO MG24, the XIAO, is the only XIAO with a serial port chip at the moment, so at the beginning of the product’s definition it shouldn’t be like other XIAOs where you can’t upload a programme due to software anomalies in the serial port emulation. So there is no BOOT button designed, and unlike other XIAOs, there is no BOOT recovery method. But obviously, we are not thoughtful enough, ignoring the XIAO sleep mode needs to be restored in this case, then for this case, we need to give you the basic method of waking up the serial port, later I will update to the wiki. here to respond to the untimely response to the inconvenience caused by the development of all of us to express my apologies.

2 Likes

See also the link below.

@Citric - Thanks for the information.
I find the XIAO_MG24 to be excellent and works very well within Arduino and Simplicity Studio for creating most types of applications including Zigbee applications (Simplicity Studio). File upload is very fast and debugging works very well. All without any soldering via the included SWD!
I have tested both chip and whip antennae and the ranges are excellent! BLE range is also very good.
While there have been complaints about the lack of an interrupt on the IMU I find it rather pointless. The IMU is only a 6 DOF and connected via I2C, so not really useful in either a low power or high accuracy environment.
If I want an IMU I’ll use a 9 DOF part, with SPI and INTs!
I seldom need a MIC anyway so will stick with the no-Sense version for now.
Any information on possible power reduction in running states (EM2) would be most welcome!
Overall an excellent product. Thanks Seeed Team!

I realised I posted in the wrong thread haha.

Thanks for liking it too, I’ll feed your thoughts back to our product manager.

Hi there,

Well that’s great You are having success, However it does mis the mark regardless, It’s not a replacement for the Nrf52840 sense, which was one of the goals of this device. I know you are new here and Your IMU argument is “pointless”. The power consumption as advertised for the different states is NOT what is tested. You may want to Try a Sense version. It hasn’t had any improvement in the LIB’s for it. Also I notice none of your code was for the Sense version so again your point is moot.

The seeed team themselves acknowledges the oversight on the lack of a functional Interrupt. I don’t know how much coding experience you have but Polling an IMU vs. Interrupt in time critical applications is highly desirable. Grab a good coding book and read it, Polling is programming 101, Interrupts are where the magic happens ask any experienced programmer. It requires some coding prowess Especially for a wearable device.

HTH
GL :slight_smile: PJ :v:

I’ll take PLIO over Simply Studio any day. Especially for the debugging :+1:

I wasn’t aware the MG24 was supposed to “replace” the NRF version? I thought it was more of a “supplement” to the XIAO range?

I use the MG24 for Zigbee (and Zigbee/BLE Multiprotocol) development. I don’t use Arduino or PlatformIO for my development. My customers require I use ISO accredited development tools. Simplicity Studio is a framework level “assistant” that I use mainly for project creation, but can also support building, flashing and debugging code.

Regarding the polling of the IMU - I agree it’s not optimal but neither is the I2C interface. I also don’t use the “sense” version as I don’t need it. If I did use an IMU it certainly wouldn’t be the (polled) LSM6DS3 over I2C!

I selected the XIAO_MG24 as it’s a very low cost device useful for prototyping hardware and (Zigbee) software. I have been testing the product on a number of Zigbee devices for a couple of months now and they work really well. Having the RF selection option is nice as I have been able to get excellent range testing done with UFL antennae and 19.5dBm!

The XIAO_MG24 is also great for developers to have the ability to flash and communicate serially in situ without user intervention! I can program and debug several devices under development without having to lug programmers around. For example I can connect 10 devices and have a flash batch file for each device based on their adapter serial number. Brilliant!

Obviously that’s not useful or necessary in an end product design and we have our own radio modules for that, but it is very useful in large system development.

I’m sure the XIAO_NRF (Sense) is very good. I just don’t use it!

1 Like

Hi there,

Ok that is fair enough SPI we agree, LOL. I do a similar Batch thing but use the Rom Mac and internal serial number to get a Unique part ID.
Yes, The Xiao Nrf52 Series is getting LONG in the tooth, It’s ok. I’m sure the sales will tell the story in the end.
Both matter and Zigbee are on the rise.

The radio draws about 40 mA when transmitting at 19.5 dBm. even at 1000mAH and being generous you get 30 days at most. considering no sensors , which is unrealistic for an IOT device MCU. :v:

Fair to say your customers just aren’t aware then, that the MG24 is a low‐cost, prototyping platform. It hasn’t been designed, qualified, or certified for safety-critical applications (e.g., meeting IEC 61508, ISO 26262, or similar standards).or that IAR Embedded Workbench, Keil MDK, SEGGER Embedded Studio, ARM Development Studio, and various static analysis tools are among the industry‑MOST recognized tools that support accredited development processes. At the SEI (in Pittsburgh)we dealt with this often,
I never saw Simple Studio on the list, ISO9001 probably Oh’ the framework, I have been through the process twice both times successful one for Software and one for a medical device, surgical field (SSG- Spinal Stiffness Gauge) but anyway … Even so, VB and PLIO use underlying industry‑recognized tools into a certified process when possible. If you’re developing in a regulated environment, you’ll often integrate these. Even if you’re using the nRF Connect SDK in VS Code, understanding that the underlying toolchain (GCC for ARM, CMake, etc.) is part of a larger ecosystem that can be integrated into ISO‑compliant processes and has. So It’s only part of the whole picture. but that’s for another thread.

" The Nrf52840 Xiao is the TOP selling Co. product YTD " ERIC , CEO :wink:

For a graphics card co. SIL has a lot to prove…Time will tell :lying_face: :money_mouth_face:

GL :slight_smile: PJ :v:

Simplicity Studio, along with its SDK, has a steep learning curve too compared to simpler frameworks (e.g., Arduino). New users may find the configuration, especially for Zigbee/Thread stacks, to be more complex.
Toolchain and Vendor Lock-in, or features like Zigbee or Thread, the configuration system can be intricate. This might require a deeper understanding of the numerous build-time options to get the system running exactly as needed.
I would like to know what you do for the available bootloader options (and update mechanisms) might not be as flexible or as widely supported by the community compared to some open alternatives (like MCUboot). This can add challenges if you plan to implement custom DFU/OTA update schemes. Do you use DFU & OTA over BLE ?

EDIT: closed is fine, it’s tapped out…They can Start another thread more specifically related. :+1: