SEGGER embOS Tickless Mode for Battery-Powered IoT in India: Sub-10 µA Sleep on STM32L4 and nRF52840

Battery-powered IoT is the fastest-growing segment of Indian embedded product design today. Smart meters under BIS IS 15959, asset trackers for fleet and logistics, agri-sensors deployed across farmland with LPWAN backhaul, and continuously worn health monitors, every one of these product categories has a common non-negotiable: 10-year battery life from a coin cell or a single primary cell, which means the idle current has to be measured in microamps, not milliamps.

Hitting single-digit microamp sleep currents on an Arm Cortex-M target is a combined hardware-plus-firmware discipline. The hardware side, picking the right low-power silicon (STM32L4, STM32U5, Nordic nRF52840, nRF5340, Silicon Labs EFR32xG22), designing the power tree, turning off unused peripherals, is well understood. The firmware side is where most Indian teams lose microamps they do not realize they are leaking: the RTOS kernel’s periodic SysTick interrupt, firing every 1 ms by default, wakes the CPU from deep sleep just to increment a tick counter and go back to sleep.

This is what tickless mode fixes, and it is what SEGGER embOS (in particular the embOS-Ultra configuration with cycle-accurate timing) implements cleanly. This post walks through why tickless matters for Indian battery-powered products, how embOS implements it, what the concrete setup looks like on two of the silicon families Indian teams actually ship on (STM32L4 and Nordic nRF52840), and how to measure whether it is actually working. The technical approach is based on SEGGER’s public application note AN01002, embOS Tickless Support. GSAS Micro Systems is India’s authorized SEGGER partner, embOS commercial source licensing is available with INR invoicing across six India offices.

What tickless means in RTOS kernel terms

A conventional RTOS kernel programs the CPU’s system timer (SysTick on Cortex-M) to fire at a fixed period, typically 1 ms, so that every millisecond the scheduler can check for expired delays, time-sliced tasks, and pending timeouts. This is fine in steady state when the CPU has work to do, but it becomes a pure energy tax when every task is sleeping on long delays and the only “work” the CPU performs on each tick is to realize there is still nothing to do and go back to sleep.

On an STM32L4R9 configured for stop mode, each spurious wake costs roughly 10-20 µJ depending on how deep the wake-up went, and at 1 kHz that adds up to an average current contribution in the tens of microamps, which for a smart meter budgeted for 10 µA total is a killer.

Tickless mode removes the wasted ticks. At idle, the kernel:

1. Determines the next task delay deadline (say, “wake me in 3847 ms”).
2. Disables SysTick (or sets it to a period much longer than the wake deadline).
3. Programs a hardware timer, typically a low-power RTC or LPTIM, to generate an interrupt at exactly the wake deadline.
4. Enters the deepest sleep mode the hardware supports.
5. On the deadline interrupt, reads elapsed time, adjusts the kernel’s tick counter accordingly, and hands control back to the scheduler, which dispatches the woken task.

The net effect: the CPU wakes exactly when work is needed, not on a periodic schedule it cannot use. On a typical Indian smart-meter or sensor workload, read a sensor every 30 seconds, transmit over LPWAN every 15 minutes, the wake rate drops from 1000 Hz to well under 1 Hz, and the average idle current drops proportionally.

embOS tickless implementation: what is different from FreeRTOS

FreeRTOS has a tickless mode as well, configurable via configUSE_TICKLESS_IDLE, and it is functional. embOS implements tickless slightly differently, with a few consequences that matter in practice for Indian product engineering:

• No user-facing “enter tickless” hook. embOS-Ultra’s tickless mode is transparent. You do not need to implement a vPortSuppressTicksAndSleep-equivalent function; the kernel manages the entire entry and exit path internally, reprogramming the timer and accounting for elapsed time automatically. This eliminates a class of subtle bugs Indian teams historically hit when their hand-written FreeRTOS tickless hook miscounted elapsed time.
• Cycle-accurate timing accounting. embOS-Ultra tracks elapsed time in hardware timer cycles rather than approximated tick counts, so a 3847 ms sleep resumes at exactly 3847 ms, not “approximately 3847 ms give or take 0.5 ms of tick drift.” This matters for Indian IoT products doing slotted LPWAN (LoRaWAN class-A, for instance) where protocol timing is strict.
• First-class support across silicon families. SEGGER maintains the timer drivers for the major low-power Cortex-M targets (STM32L/U, Nordic nRF52/nRF53, Silicon Labs EFR32, NXP Kinetis L). Indian teams porting from one silicon to another do not need to rewrite the tickless port.
• Commercial support contract. When something surprising happens, a wake that should have been 3 s turned into a 13 s wake, or a tickless exit that briefly re-enters sleep unexpectedly, an Indian team running embOS has a commercial support line directly to SEGGER (via GSAS for India). This is the quiet value of commercial RTOS licensing that does not show up on a feature-comparison table but matters intensely at 01:00 before a customer delivery.

STM32L4 tickless setup: using LPTIM1 as the wake-up timer

The standard embOS tickless implementation on STM32L4 uses LPTIM1 as the tickless wake-up timer, chosen because LPTIM1 runs from the LSE (external 32.768 kHz crystal) and stays alive in STOP mode on STM32L4. The concrete setup:

• Configure LPTIM1 to run from LSE (32.768 kHz), prescaler 1, autoreload 65535.
• In the embOS OS configuration, point the kernel’s tickless driver at LPTIM1 and pass it the LSE frequency.
• Enable STM32L4 STOP 1 or STOP 2 mode in PWR->CR1 as the deep-sleep target.
• Configure the MCU’s SLEEPDEEP bit so that WFI enters STOP instead of plain SLEEP.
• Ensure the LSE domain is enabled and ready before the first tickless entry (this is a common Indian bring-up bug, the LSE takes ~2 s to stabilize from cold boot, and a tickless idle entered before that point results in the CPU entering STOP with no wake-up source programmed).

Once correctly set up, the STM32L4R9 in STOP 2 with LSE active idles at roughly 1.2 µA (datasheet typical), and your embOS tick no longer adds to that number.

Nordic nRF52840 tickless setup: using RTC0 alongside SoftDevice

Nordic nRF52840 tickless is slightly more involved because of the SoftDevice BLE stack, which already has its own use of the low-power timers. The correct approach:

• If SoftDevice is NOT used (non-BLE firmware): use RTC0 directly as the embOS tickless timer. RTC0 runs from the 32.768 kHz LFCLK and stays alive in System ON low power mode.
• If SoftDevice IS used: the SoftDevice reserves RTC0 exclusively. embOS tickless must use RTC2 instead, and the coordination between SoftDevice’s LFCLK usage and embOS’s RTC2 usage requires that you let SoftDevice initialize LFCLK first.
• In both cases, enter System ON low power (System OFF is too deep, it resets the chip on wake), not the deepest System OFF mode.

Correctly configured, an nRF52840 in System ON with RAM retention idles at roughly 1.9 µA (again datasheet typical), with BLE advertising events adding a measurable burst every advertising interval but otherwise leaving the CPU in its deepest alive state.

Measuring whether tickless actually works: the Joulescope test

Every Indian team building a battery-powered IoT product should own a Joulescope or equivalent high-dynamic-range current analyzer. You cannot hit 10 µA if you cannot measure 10 µA, and a standard bench DMM cannot do it, the dynamic range from tens of milliamps (BLE transmit burst, LPWAN uplink burst) down to single microamps (sleep idle) is beyond a typical handheld meter.

The Joulescope test: program your product with the tickless-enabled firmware, connect the Joulescope between the battery and the product, and capture a 5-minute idle window. You are looking for:

1. Average current during the window (should be under your budget, typically 5-10 µA for a smart meter or tracker).
2. Idle baseline between wake events (should match the silicon datasheet for your chosen deep-sleep mode plus ~0.1 µA for LSE or LFCLK).
3. Wake frequency (should match your application’s actual work schedule, every 30 s for a sensor read, every 900 s for an LPWAN transmit, nothing in between).

If you see wake events at 1 kHz in the capture, tickless is not working, either the kernel is not entering tickless mode, or something outside the kernel (a peripheral DMA, a pending interrupt, a watchdog) is waking the CPU. The Joulescope capture is the fastest diagnosis tool; SystemView is the second-fastest for seeing what the scheduler was actually doing when the unexpected wake happened.

When to pick embOS over FreeRTOS for an Indian battery-powered product

FreeRTOS is free and functional. For hobbyist projects, non-critical products, and teams that cannot justify commercial licensing, FreeRTOS is the right choice. For Indian commercial products where battery life, reliability, and time-to-market all matter, the embOS case is:

• Tickless just works. No configUSE_TICKLESS_IDLE tuning, no hand-written vPortSuppressTicksAndSleep, no subtle elapsed-time bugs.
• Cycle-accurate timing. Important for slotted LPWAN protocols, scheduled sensor reads, and anything that has to wake at a precise moment.
• Commercial support. When you are three weeks from a customer delivery and something breaks, the difference between community forums and a direct commercial support line is measured in customer relationships.
• Source code licensing. embOS ships as source under a per-product commercial license available in India through GSAS. Your team can read and modify the kernel if needed.
• Consistent integration across silicon families. The same embOS API on STM32, nRF52, i.MX RT, Renesas RA, and the others. No per-silicon tickless rewrite.

The practical purchase path for Indian product teams is: license embOS for the specific CPU family you are shipping on, buy a J-Link PLUS or J-Link PRO for development and SystemView debugging, and move to Flasher for the production line.

Further reading

• SEGGER AN01002, embOS Tickless Support, the canonical reference with API details
• embOS product page at segger.com
• SystemView V4, latency analysis for RTOS projects
• Buying the right J-Link for battery product debug
• SEGGER at GSAS
• J-Link PLUS Compact product page, the typical battery IoT bench debugger