After a setting that reboots (theme, rotation, language, remote mode...) the
P4 came back with the panel dark, and only a second reboot brought it back.
esp_restart() on the ESP32-P4 is a CPU reset: esp_system_reset_modules_on_exit()
resets DMA, UARTs, SDMMC and crypto, but not the MIPI-DSI host or its DPI path.
The display driver then initialises over a host still half-configured from the
previous session and the panel stays dark. A full chip reset always recovers it.
So every software restart now becomes a full system reset: a shutdown handler,
installed first thing in app_main so it runs last, arms the RTC watchdog with
RESET_SYSTEM. Being a shutdown handler it covers rebootDevice(), OTA, the
console and factory reset without touching any of them. Same fix as
camillia-mt's T-Display P4 port.
Those restarts now arrive as ESP_RST_WDT, so an RTC_NOINIT marker records that
the restart was deliberate, and the crash-report prompt and Settings -> About
read the reset reason through bootResetReason(), which reports ESP_RST_SW for
them. Otherwise a lingering coredump would re-prompt "restarted after a crash"
on every settings reboot.
Not built here (no ESP-IDF toolchain in this environment); needs a P4 build and
an on-device check.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FbY4FsGuX2fNDpNttB6a7R
camillia-mt's working T-Display P4 GPS wakes the L76K through the XL9535
before opening UART1 on RX 22 / TX 23, starts at 9600 and probes other
rates until valid NMEA arrives. Wake and pins already match here; the
difference was the rate. The P4 used the core MicroNMEALocationProvider
locked to one rate (115200), so a receiver at any other rate gave an
open but silent UART.
Build the P4's provider as WadaNmeaLocationProvider with UART probing
(already on main via PR #517, used by the T-Deck Pro), starting at 9600:
it walks 9600/19200/38400/57600/115200 until a checksummed sentence
arrives and saves the working rate.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Current T-Display P4 V1 units ship the C6 with esp-hosted firmware
(2.12.3), and main's P4 build only spoke ESP-AT, so Wi-Fi could not come
up on them at all. This is a one-time import of the esp-hosted backend
- TDP4_C6_HOSTED build switch (default hosted; WADA_P4_LEGACY_AT=1 keeps
the ESP-AT path for older units), with the ESP-AT socket/WiFi facades
and the single-listener TCP router guarded to the legacy build.
- tdisplay_p4: build.sh hosted patches and fullclean handling,
idf_component.yml esp-hosted pin, sdkconfig, main.cpp hosted bring-up
and SNTP, c6_at updates, and the C6 reset hook in target.cpp.
- P4 Wi-Fi scan wait in UITask.
- TDISPLAY_P4_C6_FIRMWARE_PLAN.md.
Not imported from that commit: UI-scale default, GPS log lines, UI
build-upload-monitor.sh: run build.sh's own fullclean for the P4 (idf.py
fullclean rejects the patched managed components).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Mine, from the fuel-gauge change earlier today.
bq27220ReadU16() returned 0 on an I2C failure, which is indistinguishable from a
real reading of zero. The voltage reader had always defended against that by
range-checking (2500-4600 mV) and keeping the last good value, but the new
state-of-charge reader accepted anything <= 100 — so every lost transaction was
taken as a genuine 0%, and the display alternated between 0 and the real figure
as reads succeeded and failed.
The gauge shares this I2C bus with the XL9535 expander, the RTC and the touch
controller, so an occasional lost transaction is normal rather than exceptional.
Encoding that as a valid measurement was the mistake.
The transport now returns false when the gauge does not answer, and both readers
keep their previous good value on a failure. Once the gauge has answered once,
the percentage never falls back to the voltage curve either, so the number cannot
jump between two different scales.
Reported by Kaj on hardware. P4 builds.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@D-Melhede saw a P4 claim 71% and then die, with Meck-P4 reading 11% on the same
pack; a full charge never quite reached 100%; and "calibrate 100% here" made it
permanently worse. @wb6zsu watched it read 51%, then 100% the instant USB went in.
All of that is one cause. The P4 carries a BQ27220 fuel gauge, which coulomb-counts
against its learned pack profile and therefore knows the actual state of charge, but
we only ever read its Voltage() register and pushed that through the generic
3.30-4.20 V linear curve. Terminal voltage is charger-driven, so it pins at 100% the
moment USB is connected however empty the pack is, sits under 100% on a rested full
pack, and calibrating "full" while charging captures a charger rail as the reference
and bakes the error in for good. The old comment conceded the limit in as many words:
"the real cell % isn't observable here". On this board it is.
Now reads StateOfCharge() and uses it directly, falling back to the voltage curve
only when the gauge does not answer or reports out of range, so a dead gauge is no
worse than today rather than a made-up number.
The register is REG 0x2C, taken from LilyGo's own SensorLib (GaugeBQ27220.hpp
"StateOfCharge; // % - REG2C") rather than from memory, since guessing a register
here would produce confident nonsense.
Does NOT address the charging/LED half of that report: whether the pack charges
correctly and what drives the red/green LED is the BQ25896 charger, which we still
do not talk to. Tracked separately in the issue.
P4 builds; T-Deck and V4 unaffected (the gauge path is board-gated).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Michael A. Cojocari