Low-Power Sleep and Wake-on-Event for Parked EVs

The problem

A parked EV's controllers must draw very little from the 12 V or traction battery, yet still wake for a key press, a scheduled check or a theft alert. Choosing the right low-power mode and wake sources, and measuring the real current, is a core embedded skill.

Objectives

• Measure the board's supply current in run, Sleep, Stop and Standby modes.
• Wake from Stop on keypad and button EXTI interrupts and from an RTC alarm.
• Restore clocks and peripherals correctly after waking.
• Run a short battery check and motion check on each periodic wake.
• Report the energy saved by the chosen strategy.

What you need

This project uses the kit's lithium cell. Respect polarity, never short the terminals, and don't leave the cell charging unattended.

Key concepts

Sleep mode

The CPU clock stops (WFI) but peripherals keep running; any interrupt wakes it. Small savings, instant wake.

Stop mode

All 1.8 V domain clocks stop and RAM is kept; wake comes from any EXTI line, including the RTC alarm on EXTI line 17. On waking the system runs from HSI, so the clock must be reconfigured.

Standby mode

The lowest-power mode; RAM is lost and waking (WKUP pin PA0, RTC alarm, reset) is like a reset. Data must be kept in backup registers.

Duty cycling

Waking briefly at intervals to do work and then sleeping again. Average current is the time-weighted mix of awake and asleep currents.

Board-level current

The MCU is only part of the load; LEDs, regulators, the LCD and sensors also draw current, so peripherals must be switched off or isolated with the DIP switches for real savings.

Step-by-step guide

1. 1

   Define the parked-mode behaviour

   Write the requirements: when parked, wake on a keypad key, wake every minute (every few seconds in demo mode) to check the battery and motion, and raise a theft alert if motion is detected. Decide which data must survive sleep and which mode suits each case. Note that the RTC on this kit may be the STM32's internal RTC or an external chip; check the kit manual, because the internal RTC alarm can wake the MCU directly from Stop and Standby.

   Checkpoint: A requirements list and a state diagram: Run, Parked-Sleep, Wake-Check, Alert.

2. 2

   Set up current measurement

   Connect the USB power meter or multimeter in series with the board's supply. Record current with the default firmware, then with each block isolated by its DIP switch, to know how much the LCD backlight, LEDs, sensors and the BMS section draw. The board-level figure will be much higher than the MCU datasheet value. Use the same supply voltage for every measurement.

   Checkpoint: A table of supply current with each block connected and isolated.

3. 3

   Configure the wake sources

   In CubeMX enable the RTC with LSE and an alarm interrupt (EXTI line 17 is linked to the RTC alarm on this family), configure the keypad column lines as EXTI inputs with rows driven low before sleeping so any key pulls a column and wakes the MCU, and enable I2C for the MPU6050. Set the DIP switches for the keypad, RTC, MPU6050, LCD, LEDs and buzzer.

   Checkpoint: In run mode, a key press and an RTC alarm each trigger their interrupt callback.

4. 4

   Implement Sleep mode

   Stop the HAL tick (HAL_SuspendTick), enter Sleep with HAL_PWR_EnterSLEEPMode(PWR_MAINREGULATOR_ON, PWR_SLEEPENTRY_WFI), and resume the tick after waking. Measure current. Sleep saves CPU power but peripheral clocks keep running. Disable interrupts you do not want to wake the core, such as unused timers, otherwise Sleep ends almost immediately. Check which interrupts are still enabled after CubeMX initialisation and confirm with a GPIO toggle that the core really stays asleep between key presses. Compare the result with run mode in the same configuration.

   Checkpoint: Current in Sleep is recorded and the board wakes instantly on a key press.

5. 5

   Implement Stop mode and clock recovery

   Before Stop, turn off the LCD backlight and LEDs, put the MPU6050 into a low-power or cycle mode, and set the RTC alarm. Enter Stop with HAL_PWR_EnterSTOPMode(PWR_LOWPOWERREGULATOR_ON, PWR_STOPENTRY_WFI). After waking, call SystemClock_Config again because the MCU restarts on HSI, then re-initialise anything that depends on the clock, such as UART baud rates. Set unused GPIOs to analog mode before Stop to reduce leakage.

   Checkpoint: The board wakes from Stop on a key and on the alarm, and UART output after wake is correct, proving clocks were restored.

6. 6

   Do work on each periodic wake

   On an alarm wake, read the MPU6050 and compare the acceleration vector with the one stored before parking; read the battery-related values available to this MCU (or skip if they are on the BMS unit, and document it); store results; set the next alarm and return to Stop. Keep the awake time as short as possible and measure it with a GPIO toggle.

   Checkpoint: Awake time per check is measured in milliseconds and the board returns to Stop each time.

7. 7

   Add the theft alert

   If the acceleration vector changes beyond a threshold between checks, wake fully: sound the buzzer, flash the red LED and show an alert on the LCD until the correct PIN is entered on the keypad. If the MPU6050 interrupt pin is routed to the MCU on your board, also try its motion-detect interrupt as a wake source; otherwise rely on periodic checks and say so.

   Checkpoint: Moving the parked board triggers the alert on the next check, and the PIN clears it.

8. 8

   Try Standby mode

   For the deepest sleep, store the parked state in RTC backup registers, enable the WKUP pin or RTC alarm wake, and enter Standby with HAL_PWR_EnterSTANDBYMode. On wake, the firmware starts from reset: check the standby flag (PWR_FLAG_SB) and restore state from backup registers. Measure Standby current and the wake-up time from alarm to the first useful work, which is longer than from Stop because the firmware restarts. Compare whether the lower sleep current outweighs the extra energy of a full start-up at your check interval.

   Checkpoint: The board wakes from Standby on the alarm, reports the wake reason and restores its parked state.

9. 9

   Calculate energy and compare strategies

   Using measured currents and awake times, compute average current for: always running, Sleep only, Stop with periodic wakes and Standby with periodic wakes, at several check intervals. Estimate how long a given battery capacity would last for each, stating that board-level peripherals dominate. Use average current = (awake current × awake time + sleep current × sleep time) divided by the period. Validate the calculation by measuring average current directly over several cycles with the meter's averaging function, if it has one, and explain any difference.

   Checkpoint: A comparison table and a plot of average current against check interval.

10. 10

    Document the results

    Write up the modes, wake sources, clock recovery, measured currents, energy calculation and limitations of a development board for low-power work. Include the peripheral current table, the code changes needed before and after each mode, the wake source test matrix and the energy comparison. Recommend a strategy for a parked EV controller based on your numbers, and list what a production board would change, such as power-gating sensors and the LCD.

    Checkpoint: A report with the state diagram, measurement table and energy comparison.

Testing & validation

• Every wake source tested in each mode it is meant to work in.
• Clock recovery verified by correct UART output and timer periods after waking from Stop.
• Current measured in each mode with the same peripheral configuration.
• The theft alert triggers on movement and not when the board is left still.

Expected results

A parked-mode power manager with keypad, RTC and motion wake, verified clock recovery and a measured comparison of the energy used by each low-power strategy.

Take it further

• Send a theft alert over a Bluetooth module (HC-05 add-on) on wake.
• Coordinate sleep with the Smart BMS unit so both MCUs sleep and wake together.
• Add a CAN wake-up concept using the CAN RX pin as an EXTI source.

Viva and review questions