Tab5 without battery: C6 reset pin, C6 firmware version and power path (schematic notes, measurements to follow)

[poonjh]

Hello everyone,

We are building a small always-on device on the Tab5 (C145, no battery), powered at 9 V through the HVIN pin of the Ext.Port. Our firmware is ESP-IDF based (xiaozhi-esp32), not ESPHome. Axel's write-ups helped us a lot, so here is what we found so far. Everything below comes from reading the schematic and the source code, not from measurements. We will add measured numbers when our units arrive.

1. The C6 reset pin is GPIO15, and non-ESPHome builds may get it wrong

• On the Tab5 schematic, the C6 reset net RF_C6_RST goes through R4 to SOC_EXTRF_RST, which is ESP32-P4 GPIO15. ESPHome configs use reset_pin: GPIO15 too.
• In esp_hosted's Kconfig, ESP_HOSTED_SDIO_GPIO_RESET_SLAVE defaults to 15 only if the board preset ESP32P4_TAB5_C6_BOARD is selected, and to 54 for any other ESP32-P4.
• Our build, based on the xiaozhi-esp32 m5stack-tab5 board, did not select that preset, so the generated sdkconfig had CONFIG_ESP_HOSTED_SDIO_GPIO_RESET_SLAVE=54. The "reset slave on every host boot-up" option was on, but the pulse went to the wrong pin, so the C6 was never actually reset. We now set it to 15 explicitly.
• If you build your own ESP-IDF firmware for the Tab5, it's worth running grep GPIO_RESET_SLAVE sdkconfig.

2. C6 factory firmware and the version warning

• Axel's unit reports C6 firmware 1.4.1. The esp_hosted 2.12.x host compares major.minor versions at start-up and logs Version mismatch: Host > Co-proc ==> Upgrade co-proc to avoid RPC timeouts (compare_fw_version() in host/drivers/transport/transport_drv.c).
• Axel's 2.12.12 host has run with a 1.4.1 C6 for months. Because of reported failures after C6 updates (Enable Tab5 C6 coprocessor OTA over SDIO after one-time wired migration sslivins/arctic-controller#276, ESP32-P4 + ESP32-C6 (esp32_hosted): SDIO connection failure and ESP32-C6 bootloop after updating to hosted fw 2.12.8 esphome/esphome#16692), we are not updating the C6 either. We will judge compatibility from long soak tests instead.

3. Power path without a battery (schematic p5)

HVIN (Ext.Port pin 2) → D7 → FU4 1 A polyfuse → MP4560 buck (5.04 V)
  → MAX40200 ideal diode (1 A abs. max) → SYS_5VBUS   ← USB-C joins through a second MAX40200
  → LPW5209 load switches → screen, P4, C6, speaker, camera and the EXT 5V output

As far as we can read it, every 5 V load shares that one 1 A ideal diode. Under peak load (full brightness, loud audio, camera, external sensors), a brownout seems more likely than damage. This may be related to the brownout Axel saw right after an OTA, but we haven't verified that.

4. What we will measure and post here

• Whether the unit powers on by itself from HVIN 9 V: on first plug-in, and after a cut of 10 s and 10 min (no battery, button not pressed).
• Input power with a USB-PD meter: idle, full brightness with loud audio and the camera on, and during a whole OTA. Also the EXT 5V voltage under load.
• 20 consecutive soft reboots and OTAs: whether the screen comes back, how long the C6 link takes to come up, and any brownouts.
• The C6 firmware version, ESP32-P4 chip revision and panel type (ST7121 / ST7123) of each unit, together with what the back sticker says.
• RTC drift after the unit has been unplugged for a few hours and for a day.

If you already have any of these numbers, especially power draw or HVIN behaviour, we'd be glad to compare.

Thanks to Axel for sharing the project and its incident notes.

[Axellum]

Thanks a lot for these notes, Jiuhai. I'm really glad if my write-ups could help you.

Your questions already made me correct two things in my docs (#367 and #370). I'll use your feedback and your measurements to keep improving them, in case they can help others too.