X728 V2.5 — two power-on events required after software shutdown (AON / button)

This post documents a reproducible behavior on the X728 V2.5 and the test methodology that isolates it to the X728 MCU. My hope is that other V2.5 users can confirm or refute, and that anyone with insight into the MCU's power-on logic can comment.

Symptom. After a software shutdown of the Raspberry Pi (via shutdown -h now, or the equivalent x728off/xSoft.sh route), the X728 requires two power-on events to boot the Pi rather than one. This applies to both input paths:

Button: the first press appears to start the Pi briefly — capacity LEDs come up, the rail engages momentarily — then the X728 withdraws power. A second press boots normally. Timing between the two presses is not a factor; a fast second press works as well as a delayed one.

AC re-application (batteries installed): unplug and replug the PSU after shutdown — does not boot. A second unplug/replug cycle does boot. Cycles 1, 3, 5, 7 fail; cycles 2, 4, 6 succeed, in a clean period-2 alternation across many trials.

The Pi boots reliably on a single press / single AC application only when the X728 MCU has been fully de-energized between shutdown and the next power-on. That occurs in one case in normal use: with no batteries installed and the PSU removed for several seconds — the MCU loses power, resets, and the next power application is a clean cold start. With batteries installed, AC removal does not de-energize the MCU (the board keeps running on battery), and the two-events-per-boot behavior persists indefinitely.

Variables eliminated. This is the configuration used:

   Raspberry Pi 4B, Raspberry Pi OS Trixie, kernel 6.6+, libgpiod 2.2.x

   X728 V2.5, X728-C1 case, two Panasonic NCR18650B cells (tested both installed and removed)

   AON jumper shorted, CHG EN jumper shorted (no measurable effect on the alternation either way)

   dtoverlay=gpio-poweroff,gpiopin=26,timeout_ms=6000 in /boot/firmware/config.txt

   xPWR.sh corrected for libgpiod 2.x to hold GPIO12 high via a backgrounded gpioset

   xSoft.sh removed from the shutdown path; sudo shutdown -h now used directly, so no Geekworm script is involved in the actual shutdown

gpioinfo -c 0 26 confirms output consumer="power_ctrl" — GPIO26 is owned by the kernel overlay and driven correctly through the halt. gpioinfo -c 0 12 confirms consumer="gpioset" while running. This rules out: malformed GPIO26 handling in userspace (the kernel now owns the line); the previous Trixie/libgpiod release-on-exit bug; GPIO12 not being held (it is); jumper interaction (tested both configurations); battery presence as a root cause (the symptom occurs with batteries out too — the battery only determines whether AC removal is sufficient to reset the MCU); shutdown-script bugs (the symptom occurs with shutdown -h now invoked directly).

Working hypothesis. The X728 MCU latches a state at software shutdown that requires either a full MCU power-down or two subsequent power-on events to clear. The first power-on event appears to advance the latch without completing a boot; the second produces a normal start. A genuine MCU power-cycle (batteries out + PSU removed) resets the latch unconditionally. This is consistent with the behavior reported by other V2.5 users in the X728 and X728-script wiki comment threads ("first power application just wakes the green battery capacity LEDs, a second is needed to boot"), and with the X728 wiki note that after shutdown the Raspberry Pi will not restart automatically unless the power supply is replugged — but with batteries installed, "replug" is not, from the MCU's perspective, a power cycle of the MCU itself.

Questions for other users and for Geekworm.

Is two-events-per-boot after software shutdown the expected behavior of the V2.5 MCU, or a defect? Per-board confirmation from other V2.5 users would help establish which.

If expected: is there a documented mechanism to fully reset the MCU's post-shutdown state without removing batteries — for example, a hold-button-during-power-application sequence, an I2C command, or a configuration jumper that changes the latching behavior?

If a defect: has it been addressed in a newer hardware revision, and is there a firmware update path for existing V2.5 boards?

The practical implication for anyone considering V2.5 for an unattended remote deployment: AON works in the specific scenario of "AC outage during operation, AC restored later" only if the battery has fully discharged in the interim (or is not installed). AON does not work after a clean software shutdown with batteries present — where, unfortunately, this is the configuration most users will actually deploy.