How to Configure a Microcontroller for Always-On Wearable Devices

As battery-powered wearables continue to gain popularity, wearable device manufacturers are continually adding greater functionality to their products to stay competitive. This is especially true for fitness watches that consumers use frequently. These devices are always on, and users are constantly looking for new features and enhanced capabilities.

However, adding more powerful features usually requires switching to a more powerful microcontroller to control and supervise the watch's functions. The downside of this is that it reduces battery life and requires more frequent battery charging, which affects the user experience.

This article discusses the unique microcontroller requirements for always-on wearables. It first explains how to configure a microcontroller for always-on wearables, including low-power modes and autonomous peripherals. It then introduces a 16-bit microcontroller from Texas Instruments and a 32-bit microcontroller from Maxim Integrated and explains how to leverage the key features of these microcontrollers to facilitate wearable designs.

Unique Microcontroller Demands for Always-On Wearables

For wearable devices, long battery life between charges may be the most important feature to the end user. An online review may praise the accuracy and features of a wearable product, but the difference between a disappointing one-star review and a satisfying five-star review may be the time between charges.

Besides the inconvenience of frequent charging, poor battery life has other serious consequences. Lithium rechargeable batteries lose overall capacity with frequent charging, making it more difficult to keep the battery in good condition for long periods of time.

Additionally, while the connectors used for charging are generally robust, they can only be plugged in and out at a limited speed, so each charge causes wear and tear.

Wearable electronics have different power requirements than other consumer devices because they are always on, which requires the microcontroller to be powered at all times. Often, wearable electronics also have Bluetooth Low Energy (BLE) connectivity, which must always be ready and able to communicate with a paired mobile device. Note that wireless connectivity for wearables will be discussed in Part 3 of this series.

However, while a wearable device can sync its data with a mobile device when connectivity is available, it must also be able to operate independently for hours or days without a mobile connection, depending on the intended use.

The main purpose of wearable devices such as smart watches, in addition to telling the time, is to continuously monitor and record input from external sensors connected to serial ports such as I2C and SPI. These may include: dedicated accelerometers for pedometer step counting, GPS radios for location tracking and navigation functions, and heart rate monitors. While most of these sensors can be turned on and off individually by the user, a good engineer should design the system to account for the worst case scenario of all sensors being turned on.

The data collected from these sensors must be continuously logged. In many Internet of Things (IoT) or consumer mobile devices, the logged sensor data is typically stored in non-volatile memory such as flash or EEPROM. However, writing to flash or EEPROM consumes considerable current, quickly draining the small battery in the wearable device. A better solution is to store the sensor data in SRAM.

Writing to SRAM consumes much less current than writing to non-volatile memory. Since the microcontroller is always powered, the SRAM sensor data is kept safe and secure unless the wearable device is powered off or the battery is drained by the user without charging it. The stored sensor data is wirelessly transmitted and stored in the mobile device, so even if power is lost, the sensor data is not lost.

One important means of minimizing the power consumption of a microcontroller is autonomous peripherals. The degree of autonomy varies by microcontroller family. Another common means of saving power is to disable power to unused peripherals by setting or clearing a bit in a power register without affecting the rest of the microcontroller.

Low-power modes for microcontrollers in wearable devices

Now that you understand the unique demands that always-on wearables place on microcontrollers, you must determine what the low-power modes should do, including what is useful and what is not.

Of course, the lowest power mode for a wearable is the off state. Most wearables are powered on and off by holding down a software-controlled momentary button for a specified time, which prevents accidental power sequencing. This approach is superior to mechanical switches, which are not only cost-effective but can be accidentally triggered. However, engineers should assume that users will rarely turn off their devices, so wearables should be designed under two seemingly contradictory assumptions: the device will never be turned off, but it will occasionally be turned off.

Typically, a power management chip controls the charging of the battery and sequences the power on and off of the microcontroller and sensors. Power management is also discussed in Part 2 of this series. When the power management chip shuts down the wearable device, the main power to the microcontroller is disconnected, except for the independent power supply for the real-time clock (RTC). This requires the microcontroller to be able to operate with the external power supplies to the CPU, RAM, and most peripherals disabled, with only the RTC running.

It is necessary to have the microcontroller RTC running to maintain the correct time when the wearable device is powered off, so the microcontroller should have a separate power pin to continuously power the RTC. The RTC is clocked by a low-frequency 32.768 kHz oscillator that consumes only a few nA of current. If a smartwatch loses its timekeeping function when powered off, it would be unsatisfactory to the user, so any low-power mode that disables the RTC is not suitable for wearable devices.

The CPU and any unused peripherals can be disabled to conserve power. The contents of RAM must always be preserved, making any low-power mode that disables the entire RAM array unsuitable for wearable devices.

Configuring the Microcontroller

Among the microcontrollers optimized for wearable devices, the Texas Instruments MSP430FR2676TPTR 16 MHz microcontroller with ferroelectric random access memory (FRAM) (Figure 1) is one of the best. It is a member of the Texas Instruments MSP430FR2676 16-bit MSP430™ CapTIvate™ capacitive touch sensing microcontroller and includes a low-power peripheral that can detect touch through thick glass. The glass used in wearable devices must be thick and durable to withstand the rigors of normal use, so CapTIvate technology is well suited for wearable devices with touch screens.

Figure 1: The Texas Instruments MSP430FR2676TPTR ultra-low-power 16-bit FRAM microcontroller has many peripherals and requires only a few external components to control a simple wearable device. (Image source: Texas Instruments)

The MSP430FR2676TPTR has 64 KB of Texas Instruments FRAM program memory, which provides higher read/write performance at lower power than flash microcontrollers. The device has 8 KB of SRAM and a full set of peripherals, including I2C, SPI, and UART, for connecting sensors. A 32 x 32 hardware multiplier accelerates multiplication operations and reduces power consumption.

The RTC on the MSP430FR2676TPTR can be configured to wake up the microcontroller at intervals ranging from microseconds to hours. This can be used to wake up the CPU to perform tasks such as periodically processing sensor data and sending the data wirelessly to a mobile device.

The oscillator and clock system of the MSP430FR2676TPTR is designed to reduce system cost and achieve low-power operation. The microcontroller supports four internally generated clock sources and two external high-precision clock sources. Depending on the selected low-power mode and firmware configuration, these oscillators and clocks can be enabled and disabled under firmware control. To run peripherals, the MSP430FR2676TPTR provides two clocks: a high-speed subsystem master clock (SMCLK) that runs as fast as the system clock frequency and a low-speed 40 kHz auxiliary clock (ACLK).

In addition to the active mode (CPU and everything else enabled), the MSP430FR2676TPTR supports configurable complex low-power modes. Any on-chip peripheral that is active in an MSP430-specific low-power mode can be shut down by firmware, thus supporting customized low-power configurations. The following low-power modes (LPMx) are available for wearable devices using the MSP430FR2676TPTR:

LPM0 allows all units except the CPU to run. This mode is useful when autonomous peripherals need to be active and run at full speed without CPU intervention.

LPM3 disables the CPU, high-speed oscillator, and SMCLK. All enabled peripherals can run on the power-saving 40 kHz ACLK. This mode is useful when the wearable device is idle and no buttons are pressed. Serial peripherals such as I2C and SPI can run autonomously to collect sensor data, while direct memory access (DMA) transfers the data to RAM. The RTC can wake up the device to perform any required tasks.

LPM4 turns off everything except the RTC. SRAM is turned off. This mode is useful in situations where the user turns off the wearable device.

The MSP430FR2676TPTR operates from 1.8 to 3.6 V, making it suitable for use with 3.6 V lithium batteries. With the RTC running and minimal peripherals, the microcontroller can draw less than 5 μA. With the main oscillator running, the MSP430FR2676TPTR consumes 135 μA/MHz (typical).

To enable higher performance in wearable devices, Maxim Integrated introduced the MAX32660GWE 32-bit microcontroller (Figure 2). The device is based on the Arm® Cortex®-M4 core with a floating-point unit (FPU). The MAX32660 has 256 KB of flash memory and 96 KB of SRAM. The SRAM is divided into four sectors. Any sector can be configured to be: enabled for read/write operations; or enter a light sleep state to disable read/write operations while retaining the content to save power; or completely disabled to shut down the power to the sector.