XIAO nrf54l15 with a Coin Battery

[PJ_Glasso]

Hi there,

No , kidding on the watch … I get it but the point I was making is it’s real. Companies like chipilo are doing just that using a coin cell. I always stated there are CAVEATS so to be clear and stated being the XIAO board design is one of them. No code was posted, just as a general fact that would determine the overall POWER required, The Sleep current (2uA) is only base number for sales albeit it has been demonstrated/verified on here. The Silicon will do what it says. I use the CR2450 with a XIAO without issue, It’s connected to the battery pads, (no usb will ever be connected) DFU is BLE (in fact you don’t need the usb) it’s a beacon.

here is one example
https://www.nordicsemi.com/Nordic-news/2025/08/nRF54L-Series-powers-new-line-up-of-Chipolo-tracking-solutions

nRF54L Series SoCs deliver range
Nordic’s nRF54L Series SoCs feature a high link budget 2.4 GHz radio offers a maximum receive (RX) sensitivity of -96 dBm (1 Mbps Bluetooth LE) and a maximum transmit (TX) output of up to 8 dBm, and a total link budget of >104 dBm, enabling up to 90 m of Bluetooth range for the Chipolo POP, and up to 120 m of range for the LOOP and CARD devices. From the Chipolo companion app, users can also set up additional finding features like ‘Call Your Phone’ and ‘Out of Range Alerts’ (for Android).

“When we were selecting an SoC for our Chipolo POP, LOOP and CARD trackers, the most important thing was its ability to implement simultaneous support of Apple Find My, Find Hub, and Chipolo functionality on one device,” says Jure Zdovc, VP of Hardware Engineering, Chipolo. “Nordic’s nRF54L15 SoC’s 1.5 MB non-volatile memory (NVM) and 256 KB RAM provided the large memory capacity we required, while still keeping our product pricing in the range of our previous devices.

“Ultra-low power consumption is also a key competitive advantage for asset trackers. With the nRF54L Series SoCs, we are confident we can deliver highly competitive products.”

The Chipolo POP employs a CR2032 coin cell battery providing users up to 12 months battery life between replacement. The Chipolo LOOP and CARD both employ a rechargeable cell that provides up to 6 months battery life between recharge. The nRF54L Series SoC’s radio, combined with an efficient MCU, enables significantly lower power consumption for typical Bluetooth LE applications and use cases.
"
I have taken one apart, new one uses a nrf52840, old one used a cr2032 and nrf52832 pretty Steller IMO. and it just getting started with the 54 series.

HTH
GL PJ

Bottom Line …coin cells are a thing.

[cgwaltney]

power is like calories… power in = power out + heat… its all about that budget
thats why battery and power managment and analysis circuitry is very importent to makers!.. if you eat a coin cell sized pizza… you are not going to be satisfied… (PS i am wondering if my droneODM server farm is going to keep the house warm this winter… maybe i need to branch out to 3D print farms as well… lol)

[Jet-goggles]

I’m unclear on where this stands now.

I have a Xiao NRF54l15 module which is powered by a nordic power profiler II. It is supplying power through the 3V3 line on the Xiao.

The BLE advertising example seems to not work (initially it fails to build, fixing that,) it will build and flash but does not start the bluetooth advertising.

The ‘Ultra-low Power state’ example is my main concern at the moment. By applying the modifications mentioned above (updating the overlay to disable the regulators and pulling in the latest board files from the zephyr project) I am getting a power draw of ~450uA.

It is not possible to achieve the ~3uA low power mode when powering from the 3V3 rail or am I missing something from my setup?

[msfujino]

Try this.

&pdm_imu_pwr{
    /delete-property/ regulator-boot-on;
};

&rfsw_pwr{
    /delete-property/ regulator-boot-on;
};

&vbat_pwr{
    /delete-property/ regulator-boot-on;
};

[daCoder]

It seems to be the case that you can not power the xiao nrf54l15 from the 3V pin and get ~3uA current draw in all cases. @msfujino and I both saw as you did that the current draw is ~450uA at 3.0V. At higher voltages on the pin, you get the expected current draw. @msfujino discovered that the switchover point is ~3.3v.

This means the xiao nrf54l15 doesn’t look like a good candidate for non-rechargeable batteries such at the CR2032 and CR123A where the voltage is below 3.3V.

I’m sticking with the xiao nrf52840, which works with non-rechargeable batteries, for now for my matter application. I’ve ordered a few holyiot nrf54l15 modules and will give those a try.

[Jet-goggles]

@msfujino Unfortunately that didn’t do that trick.

@daCoder Yes, I did some more investigation into the issue in addition to looking at the schematic. My theory is that the ‘100% Mode’ on the TPS628438 buck is the root of the issue.

Feeding the 5V rail with anything from 3.4V to 5V results in the expected ~3uA. As soon as that drops to 3.3V or lower, it immediately jumps up to ~450uA.

The unfortunate problem is that there seems to be some backfeeding from the output to the input (seems internal to the buck?) which means that if you apply 3.3V to the VSYS_3V3, the VBUS goes to ~3.25V which causes the buck to enter the ‘100% Mode’; hence the current drain.

[msfujino]

Looking at the circuit diagram, it seems current is being supplied from the output through the parasitic diode of the high-side MOSFET, causing the converter to operate.
Since the output is 3.0V, it enters 100% mode. To raise the output voltage, the high-side MOSFET is continuously driven, consuming about 400μA of drive current. Once the output reaches 3.3V, both the high-side and low-side MOSFETs start switching normally, reducing the consumption current.
This is my guess, but I think it’s pretty much the same as yours.

[rcn]

Does anyone have experience powering up a XIAO nRF54L15 with a 3.7V LiPo battery through the battery pads on the back?

I’m doing some basic tests with a firmware that works correctly when powering through USB, but it doesn’t seem to boot when connected to the battery alone. If I connect the battery and then I power up the board through USB, then, if I unplug the USB cable it will stay powered on by the battery, even through resets.

Any hints?

[msfujino]

Try writing CONFIG_SERIAL=n in prj.conf.

[rcn]

Ok, that worked, thanks! I’m a bit puzzled, though. What’s the rationale for it?

[msfujino]

If the PC isn’t connected to the USB, wouldn’t the LOG_INF, LOG_ERR, or printk() written inside the code fail to output data and stop working?

[rcn]

I’d expect not. As long as the UART is configured, what does it matter if the pins are physically connected to another machine or not?

[PJ_Glasso]

Hi there,

and Welcome here…

So You’re seeing a classic “back-powering the UART bridge” problem. With CONFIG_SERIAL/CONFIG_UART_CONSOLE on, the MCU brings up UARTE and actively drives TX at boot. If the USB-UART chip (on the XIAO that’s the on-board debug/bridge) is unpowered on battery, your TX line back-feeds it through ESD diodes. Result: brownout-ish behavior or no boot until you plug in USB-C.

Make RTT your default console everywhere (works on battery, no external power needed), and keep a second profile that enables UART for bench time.
Use this prj.conf (battery-safe, Default)

# Console/logging over RTT (safe on battery)
CONFIG_SERIAL=n
CONFIG_UART_CONSOLE=n

CONFIG_USE_SEGGER_RTT=y
CONFIG_RTT_CONSOLE=y
CONFIG_LOG=y
CONFIG_LOG_BACKEND_RTT=y
CONFIG_LOG_DEFAULT_LEVEL=3

Build (default) :

west build -p always -d build_batt ^
  -b xiao_nrf54l15/nrf54l15/cpuapp . ^
  -DBOARD_ROOT="C:/ncs/Seeed/platform-seeedboards/zephyr"

prj_uart.conf (bench profile with USB plugged in)

# Include the battery-safe base first if you like layering; or copy prj.conf and flip these:
CONFIG_SERIAL=y
CONFIG_UART_CONSOLE=y

# Optional: leave RTT on too (can be handy)
CONFIG_USE_SEGGER_RTT=y
CONFIG_RTT_CONSOLE=y
CONFIG_LOG_BACKEND_RTT=y
CONFIG_LOG_BACKEND_UART=y

Build with uart profile:

west build -p always -d build_uart ^
  -b xiao_nrf54l15/nrf54l15/cpuapp . ^
  -DBOARD_ROOT="C:/ncs/Seeed/platform-seeedboards/zephyr" ^
  -DOVERLAY_CONFIG="prj_uart.conf"

This gives you one image that always boots on battery (RTT), and another that speaks UART when USB is present. Same source, just flip the config.

HTH
GL PJ

for you right now

• Switch your default to RTT (CONFIG_SERIAL=n, CONFIG_RTT_CONSOLE=y). That will boot on battery every time.
• Keep a second config (prj_uart.conf) that turns UART console back on for bench work when USB-C is plugged.

This keeps behavior identical across all projects and avoids chasing per-board quirks.

[msfujino]

Hi rcn,
Please check the circuit diagram.
The SAMD11 is used as a USB-UART bridge, and this device is only powered via USB. Therefore, when USB is not connected, the nRF54l15 attempts to communicate with the SAMD11, which is not receiving power.

[rcn]

Ah NOW it makes sense! Thanks a lot for the explanation and the proposed fix.

[Toastee0]

This fixed the exact issue I had yesterday testing using the xiao Powerbread to power a xiao nrf54l15 via the bat connector.