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.

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
- Enter charge mode
The platform keeps only the power, battery-monitoring, real-time, and display resources required for the approved charging experience.
- Observe battery state
The real-time firmware reads validated state-of-charge, voltage, temperature, charger, supply, and fault signals from the project-defined sources.
- Present charging status
GraphLab Core renders the accepted state and updates only when qualified battery or charger information changes.
- Qualify start permission
Thresholds, hysteresis, debounce, supply stability, and fault policy determine whether an application-core start may be requested.
- 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
The battery-management system, charger, fuel gauge, and PMIC remain responsible for measurement, charging control, and hardware protection.
The real-time firmware validates available signals, applies the agreed display and start-permission policy, and handles missing or stale data.
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.


