UART for Embedded Device Debugging: Best Practices for Low-Power Devices

While USB has taken over the role for most peripherals, UART is still alive and kicking in the world of embedded systems - used to debug everything from GPS modules to Raspberry Pi and Arduino boards.

But as we push the limits of ultra-low-power designs, developers often ask: Is UART a silent battery killer? The short answer: No, it doesn’t have to be. Like any good tool, it all comes down to how you implement it. Let’s break it down.

Keep an eye on TX/RX leakage current

A simple way to prevent unnecessary power drain is by addressing any leakage current from the TX and RX channels. While high leakage isn’t very common, it’s always better to check and address potential issues early on to avoid unexpected power drain later.

Write and run code with a low-power mindset

Think of UART like your debug Swiss Army knife - super handy during development, but you wouldn’t carry it around open in your pocket all the time. A smart move is to use a #define in your code to toggle UART on for debugging and off when your device hits production. It’s a simple trick, but it can save you from real-world nightmares.

Imagine this: you and your team are laser-focused on minimizing power consumption. You’re running continuous current measurements and seeing great progress. During development, you leave UART enabled for debugging, accepting the temporary power hit. But then, someone accidentally merges that code into the main branch—UART still enabled—and it gets flashed over the air onto millions of devices. Suddenly, your once-efficient design is draining batteries like an arcade machine, and you’ve got a fleet of unhappy customers.

The fix? Set up a continuous integration system with current consumption benchmarks. That way, you catch issues like this before they become costly mistakes. Think of it as an automated safety net, keeping those extra amps in check before your code reaches production.

Make sure to turn everything OFF

Enabling UART can activate multiple parts of your software, including various MCU blocks and clocks. MCUs are often designed with everything turned on by default for ease of development. However, it’s crucial to disable unnecessary components before the MCU enters sleep mode. If UART clocks remain enabled, they may prevent the MCU from reaching its deepest sleep state, leading to higher power consumption. Review your clock tree and make sure all components linked to UART are properly turned off when not needed.

Otii experiment in action

Let’s compare two firmware versions running on the same device, the Seeed Studio XIAO nRF52840 from Seeed Technology. We’ve prepared a sample script that initializes the module, sets up the flash memory, runs a short LED blinking sequence, and then puts the module into its lowest power mode. One version has UART enabled, while the other runs without UART. Using Qoitech’s Otii Ace Pro, we measured the current consumption to analyze and compare the power consumption of both versions at different voltage levels.

In Figure 1, you see the device actively sending UART messages, while Figure 2 shows the MCU in sleep mode. The blue line indicates that UART is enabled, while the orange line shows it is disabled. The difference highlights the impact UART can have on power consumption.

Figure 1: Active SeeedStudio XIAO nRF52840 device with UART communication | Enabled (blue graph) | Disabled (orange graph). (Image source: Qoitech)

Figure 2: XIAO nRF52840 device in Lower Power mode (selected part of the graph) with UART communication | Enabled (blue graph) | Disabled (orange graph). (Image source: Qoitech)

In active mode, the average current consumption increased from 460 μA to 1.34 mA (as shown in Figure 1). In sleep mode, the current consumption goes from 2.27 μA to 2.19 μA (Figure 2). While this may seem to be an insignificant difference, long sleep periods typical in IoT devices make this increase significant for battery life. Clearly, the firmware is optimized for when UART is disabled.

Estimating the Battery Lifetime using Otii

To illustrate the impact on battery life, we used the Battery Life Estimator in the Otii Desktop App. We assumed one active period per hour, where the device wakes up, runs the blink sequence, and then sleeps for nearly 3600 seconds.

In Figure 3, UART is disabled, and in Figure 4, UART is enabled, showing the significant difference in battery life depending on whether UART is used or not.

Figure 3: Battery life estimation with disabled UART communication. (Image source: Qoitech)

Figure 4: Battery life estimation with enabled UART communication. (Image source: Qoitech)

The difference is quite huge! The estimated battery life drops from 5.9 years to just 11.6 days when UART is left enabled.

The key takeaway is to ensure everything related to UART is turned off before the MCU enters sleep mode. Integrating this into your continuous integration process using the Otii Product Suite will help prevent accidental releases with UART enabled, which could drastically reduce your device’s battery life.