Skip to content

Power: keep capabilities consistent when the PMIC is not identified - #422

Merged
lovyan03 merged 1 commit into
m5stack:developfrom
ainyan03:power_caps_identity
Oct 27, 2026
Merged

lovyan03 merged 1 commit into
m5stack:developfrom
ainyan03:power_caps_identity

Conversation

@ainyan03

Copy link
Copy Markdown
Contributor

Summary

When every PMIC ID probe fails (an AXP192 / AXP2101 board whose PMIC does not answer), the charge and output setters already refuse the unconfirmed register map, and getChargeStateCaps() returns an empty set. getChargeControlCaps() and getPowerOutputCaps() still advertised their paths, so a caller could be offered a path whose setter always returns false. They now return 0 in that state.

The cross check between getChargeState() and getChargeStateCaps() (a state the capability set does not advertise) also runs in device builds with a debug log level (CORE_DEBUG_LEVEL >= 4 or CONFIG_LOG_DEFAULT_LEVEL >= 4). On a device a mismatch is logged with ESP_LOGE and the returned state is unchanged; the PC build keeps the assertion. Device builds that define M5UNIFIED_CHECK_CHARGE_STATE_CAPS now log instead of stopping at an assertion.

Testing

  • every capability bit cleared in this state was matched against its setter (setBatteryCharge, setChargeCurrent, setChargeVoltage, setExtOutput, setUsbOutput, setVibration, setExtPortBusConfig): each refuses the unconfirmed PMIC first
  • the debug check is compiled into an ESP32-S3 build with CORE_DEBUG_LEVEL=5
  • On hardware: 40 boards start with the same detected board as develop
  • Builds: ESP-IDF 5.1 to 6.1 and Arduino-ESP32 2.x / 3.x (ESP32, S2, S3, C3, C5, C6, C61, H2, P4), SDL, fork CI passed

- When every PMIC ID probe fails, the charge and output setters already
  refuse the unconfirmed register map. getChargeControlCaps() and
  getPowerOutputCaps() now return 0 in that state, as getChargeStateCaps()
  does, so callers are not offered paths that always fail.
- The cross check between getChargeState() and getChargeStateCaps() also
  runs in device builds with a debug log level (CORE_DEBUG_LEVEL >= 4 or
  CONFIG_LOG_DEFAULT_LEVEL >= 4). On a device a mismatch is logged with
  ESP_LOGE and the returned state is unchanged; the PC build keeps the
  assertion. Device builds that define M5UNIFIED_CHECK_CHARGE_STATE_CAPS now
  log instead of stopping at an assertion, so diagnostics never stop a
  running device.
@lovyan03
lovyan03 merged commit b67ea7b into m5stack:develop Oct 27, 2026
30 checks passed
@ainyan03
ainyan03 deleted the power_caps_identity branch October 27, 2026 03:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants