SPIFFS.begin(true) auto-formats on mount failure, but the auto-format
itself can fail if the partition contains residual data from a previous
firmware (e.g. stock LilyGo, Meshtastic, or MeshCore with a different
partition layout). When that happens the firmware previously printed
"SPIFFS format FAILED!" and continued in a broken state with no
persistence.
Now on auto-format failure:
1. Find the SPIFFS partition via esp_partition_find_first()
2. Erase it completely with esp_partition_erase_range()
3. Call SPIFFS.format() + SPIFFS.begin(false) with up to 3 retries
Added #include <esp_partition.h> under ESP32 guard.
The existing first-boot display feedback ("Formatting storage...
First boot - please wait") is unchanged -- it fires on the initial
mount failure. The new partition erase code only triggers if the
auto-format also fails.
Hibernate (deep sleep) leaves the BQ25896 charger IC powered, drawing
~30-60uA quiescent from BAT. This adds a second option on the shutdown
page -- "power off" -- that writes the BATFET_DIS bit in BQ25896 REG09
to fully disconnect the battery from VSYS. Leakage drops to ~12-23uA
(IC internal only). Wake requires USB-C plug-in.
Shutdown page now shows two options with a cursor (up/down to toggle):
> hibernate: long press/Enter (T-Deck Pro)
power off: long press/Enter
> hibernate: long press (T5S3 / other)
power off: long press
Selecting "hibernate" triggers immediately (unchanged behaviour).
Selecting "power off" shows a confirmation prompt:
power off device?
usb-c to wake
Enter:yes q:no
Power-off display suppresses the header (node name, clock, battery)
and shows only "powering off..." and "plug in USB-C to turn on".
The 's' key shortcut to settings is gated on the shutdown page so it
passes through to the hibernate/power-off selection toggle instead.
Both the TCA8418 handler (loop) and the broader handler
(handleKeyboardInput) are gated via isHomeOnShutdownPage().
PRESS_LABEL macro: removed dead UI_HAS_JOYSTICK branch (no Meck
device has a joystick), collapsed to a single #define "long press".
Joystick input polling block in loop() also removed (dead code behind
#if UI_HAS_JOYSTICK, never compiled for any Meck build).
BQ25896 I2C sequence follows TI recommendation (E2E forum, Jeff/TI):
1. Read REG09
2. Write BATFET_DLY=1 (bit 3) -- delays disconnect so I2C completes
3. Write BATFET_DIS=1 | BATFET_DLY=1 (bits 5+3) -- last I2C write
The write happens after display turnOff but before board powerOff, so
I2C pull-ups on VDD3V3 are still alive. Board enters deep sleep, then
BATFET opens after tSM_DLY (~10-15s). Skipping the delay risks leaving
the BQ25896 I2C engine in an undefined state that can prevent wake on
USB-C plug-in (device soft-brick requiring battery disconnect).
REG09 bit map (confirmed from Linux kernel bq25890_charger.c):
Bit 7: FORCE_ICO
Bit 6: TMR2X_EN
Bit 5: BATFET_DIS (0x20) -- disconnect battery
Bit 4: JEITA_VSET
Bit 3: BATFET_DLY (0x08) -- delay before disconnect
Bit 2: BATFET_RST_EN (0x04) -- QON wake (not wired on T-Deck Pro)
Bit 1: PUMPX_UP
Bit 0: PUMPX_DN
Schematic confirms QON (pin 12) has R4 10K pull-up to REGN with no
user-accessible button -- USB-C is the only wake path from ship mode.
Guarded by #ifdef I2C_ADDR_BQ25896 so it compiles on all platforms
but only activates on boards with the charger (T-Deck Pro, T5S3).
Files changed:
UITask.h -- _full_poweroff, setFullPowerOff(), isHomeOnShutdownPage()
UITask.cpp -- shutdown page UI, input handling, BATFET write,
PRESS_LABEL cleanup, joystick removal
main.cpp -- 's' key gated on shutdown page (both handlers)
UITask shutdown (already occurs/unchanged):
1. BLE disabled (_serial->disable()).
2. WiFi disconnected + WIFI_OFF.
3. 4G modem shutdown().
4. GPS power cut (PIN_GPS_EN LOW).
5. LoRa radio powerOff() (standby mode).
6. Display turnOff().
TDeckBoard::powerOff() (new):
7. btStop() -- BLE controller stop.
8. Peripheral power OFF (PIN_PERF_POWERON LOW) -- keyboard, BQ27220, sensors.
9. LoRa module power OFF (P_LORA_EN LOW) -- cuts power entirely.
10. Hold LoRa NSS high (prevents SX1262 drawing current from floating CS).
11. esp_deep_sleep_start() -- CPU halts, ~10-40uA.
Wake (reset button or USB power-on):
12. ESP32-S3 cold boots.
13. TDeckBoard::begin() runs: peripheral power ON, I2C init, LoRa power ON, NSS hold released.
14. App starts fresh -- prefs/contacts/messages load from flash.
No LoRa wake during hibernate -- the device is truly off. Only a hardware
reset (reset button) or USB power-on wakes the device.
Incorporates hardware-specific learnings from caveman99's Meshtastic
T-Echo Card support PR (meshtastic/firmware#10267), cross-referenced
against LilyGo's official t_echo_card_config.h pinmap.
Battery (critical):
- Add BATTERY_MEASUREMENT_CONTROL pin P0.31 — gates the resistive
voltage divider feeding AIN0. Without toggling this pin, battery
ADC reads are invalid (floating divider input).
- TechoCardBoard::getBatteryVoltage() now drives P0.31 HIGH before
SAADC read and LOW after to avoid parasitic drain.
Display (critical):
- Add OLED_DISPLAY_OFFSET = 24 for the SSD1315 72×40 panel. The
physical display is mapped at GDDRAM pages 3–7 (rows 24–63);
SETDISPLAYOFFSET and SETMULTIPLEX commands are sent after
display.begin() in target.cpp to shift the visible window.
Power rail (high priority):
- RT9080 3V3 LDO now gets a clean HIGH→LOW→HIGH reset cycle with
100ms dwell in board.begin(), preventing brown-out when LoRa TX
fires at +22 dBm after a soft reset.
The markChannelReadFromBLE() calls in the CMD_SYNC_NEXT_MESSAGE handler were marking channels and DMs as read the moment the BLE companion app synced them from the offline queue. Since the app drains the entire queue automatically on connect, this had the effect of clearing all unread indicators on the device as soon as BLE connected — before the user had actually read anything in either the app or on the device.
The MeshCore BLE protocol has no "user opened this channel" command from the app side; CMD_SYNC_NEXT_MESSAGE is an automatic bulk pull, so "synced to app" ≠ "read by user." Removed the channel and DM mark-read calls so unread counts only clear when the user navigates to that channel on the device itself. The msgRead() progress counter (syncing X messages) is unaffected.
