Skip to content
GraphLabProduct studiesCheck project fit
Product studyGraphLab Boot / Pro

Charging status while application cores sleep

A product may need to show useful charging information without running Linux and the full application workload. This study explores monitoring authoritative battery and charger signals from the real-time side, keeping an approved charging view visible, and allowing an A-core start only after project-defined power conditions are satisfied.

Rugged mobile HMI in a charging dock showing an immediate battery status screen while its main application remains asleep.

Intended outcome

Keep charging visible without waking the complete system

The real-time side would maintain a bounded charging experience while the application cores remain off or in a supported sleep state. Visible states could include charger connected, charging, charged, battery too low to start, temperature restriction, or attention required.

A start-permission policy could combine battery-management data, supply stability, thresholds, hysteresis, and fault state before requesting an A-core wake or releasing an agreed boot gate. The responsible battery-management and power hardware would remain authoritative for protection.

Proposed behavior

A project-defined operating sequence

  1. Enter charge mode

    The platform keeps only the power, battery-monitoring, real-time, and display resources required for the approved charging experience.

  2. Observe battery state

    The real-time firmware reads validated state-of-charge, voltage, temperature, charger, supply, and fault signals from the project-defined sources.

  3. Present charging status

    GraphLab Core renders the accepted state and updates only when qualified battery or charger information changes.

  4. Qualify start permission

    Thresholds, hysteresis, debounce, supply stability, and fault policy determine whether an application-core start may be requested.

  5. Wake and hand over

    After the A-cores and Linux application are ready, the display switches from the charging view according to the normal readiness contract.

Architecture

Responsibilities stay explicit

Battery authority

The battery-management system, charger, fuel gauge, and PMIC remain responsible for measurement, charging control, and hardware protection.

Real-time supervisor

The real-time firmware validates available signals, applies the agreed display and start-permission policy, and handles missing or stale data.

Display and wake policy

GraphLab Core presents the bounded charging UI and requests or permits an A-core start only through mechanisms supported by the target platform.

Project inputs

Integration points to define and validate

  • Battery-management system, fuel-gauge, charger, and PMIC interfaces available to the real-time domain.
  • Authoritative state-of-charge, voltage, current, temperature, supply, and fault signals with freshness rules.
  • Start threshold, hysteresis, debounce, timeout, charger-present, and external-supply policies.
  • A-core power, reset, boot, suspend, wake, and service-override mechanisms supported by the SoC and BSP.
  • Low-power budget for the real-time core, display controller, panel, backlight, and monitoring peripherals.
  • Brownout, charger removal, battery fault, sensor loss, restart, and repeated charge-cycle testing.
  • Linux reconciliation with the current battery and charger state after wake-up.

Assess the concept

Could this fit your platform?

Share the target SoC, display path, BSP, Linux UI stack, and the state or failure you need to make visible.

Check project fit