Skip to main content

AN04: nPZero G1S software design guidelines for host MCU firmware

Introduction​

The nPZero G1S is designed to act as a system-level power controller, autonomously managing sensors and power-cycling the host MCU to minimize average power consumption. Unlike traditional low-power designs—where the MCU manages its own sleep states—the nPZero G1S physically removes power from the MCU using its integrated host switch and wakes it only when required (for example, when a trigger condition is met).

As a result, host MCU software must be written with the assumption that:

  • The MCU is fully reset on every wake-up.
  • All volatile state is lost when the MCU is powered down.
  • The MCU's active time directly dominates average system power consumption.

These guidelines highlight key architectural principles that help ensure correct and energy-efficient operation.

Fundamental reset and power-cycle model​

Host operation diagrams​

The diagrams below shows an example of a typical MCU wakeup sequence:

Host MCU wake-up flowchart

Host MCU wake-up sequence diagram

MCU reset on every wake-up​

When the nPZero G1S wakes the host MCU, it does so by re-enabling the host power switch, which causes a full power-on reset of the MCU.

From the MCU’s perspective:

  • Execution always begins from the reset vector.
  • Startup code and main() (or equivalent) run identically each time.
  • There is no distinction between “cold boot” and “wake-up from sleep” unless implemented explicitly by the firmware.
warning

Firmware must treat every boot as a fresh start and must not depend on retained RAM state.

Loss of RAM and execution context​

Because the MCU is power-gated, all SRAM contents are lost whenever the nPZero transitions the system into Idle or Polling operation with the host powered off 1.

This includes:

  • Application state variables
  • Task state (RTOS or bare-metal)
  • Cached configuration or calibration data

Design implication; all persistent information must be:

  • Re-derived at boot:
    • Fetched from the nPZero (if stored in its internal SRAM), or
    • Stored in non-volatile memory (Flash, EEPROM, etc.).

Boot-time software architecture​

Deterministic, fast boot sequence​

Because the MCU may be woken frequently and for short tasks, firmware should follow a deterministic minimal boot flow:

  1. MCU reset and startup initialization
  2. I2C bus initialization (host ↔ nPZero)
  3. Identify wake-up context (see Section 4)
  4. Perform required application work
  5. Reconfigure the nPZero if necessary
  6. Hand control back to the nPZero and shut down

Avoid long-running initialization​

Expensive operations at boot—such as:

  • Full sensor re-initialization
  • Memory clearing beyond what is required
  • Long driver discovery loops

directly increase MCU active time, eroding the power savings achieved by the nPZero.

Guideline: Only initialize what is strictly required for the current wake-up reason.

Wake-up reason handling and conditional configuration​

Distinguishing nPZero reset vs. normal wake-up​

The nPZero G1S itself can experience a reset (e.g., supply brown-out or first power-up). In that case, its internal state—including sensor configuration stored in its 128-byte SRAM—is lost.

Conversely, during normal operation:

  • The nPZero retains configuration and timing state
  • Only the MCU and peripherals are power-cycled

Design implication: Host firmware should determine whether:

  • The nPZero has retained its configuration, or
  • The nPZero requires full reconfiguration.

This can be implemented by:

  • Reading the nPZero status registers (STA1 and STA2)
  • Using a known “configuration valid” marker stored in the nPZero SRAM

Conditional nPZero configuration​

Writing a full configuration to the nPZero (sensor setup, timers, thresholds) costs time and power due to I2C activity.

Recommended pattern:

  • On MCU boot:
    • Check whether the nPZero is already configured
    • Only re-write configuration if required
  • Skip redundant configuration during normal wake-ups

This approach reduces MCU active time and I2C bus usage, improving overall energy efficiency.

Active time minimization and power optimization​

Active time dominates average power​

The nPZero G1S reduces system idle current to the nanoampere range and polling current to the microampere range. In comparison, even ultra-low-power MCUs consume orders of magnitude more current while active

Key principle: Average power ≈ MCU current × MCU active time.

Thus, firmware design should aggressively minimize:

  • CPU cycles
  • Peripheral usage
  • I/O activity

Practical techniques​

  • Perform only short, event-driven tasks during each wake-up
  • Defer periodic sensing and threshold checks to the nPZero whenever possible
  • Avoid logging, debugging prints, or delays in production builds
  • Hand control back to the nPZero immediately after completing the task

These practices align with the nPZero's intended use as an autonomous sensor manager that removes the need for an always-on MCU.

Summary of key guidelines​

  • Assume full MCU reset on every wake-up
  • Never rely on SRAM persistence
  • Design a fast, deterministic boot path
  • Conditionally configure the nPZero based on wake-up context
  • Keep MCU active time as short as possible
  • Let the nPZero handle timing, polling, and triggers

By following these principles, the host MCU firmware can fully leverage the nPZero G1S's architecture and achieve the intended system-level power reduction of sensor-based embedded designs.