tfaour
d32236d832
RST/power-on trigger: checks esp_reset_reason() at the very top of boot. ESP32-C6 can't electrically distinguish the RST/EN button from a genuine power-on (both report ESP_RST_POWERON -- confirmed against ESP-IDF's own docs, ESP_RST_EXT is explicitly "not applicable"), so POWERON is treated as "user wants to reconfigure" and routes straight to provisioning. Safe because the device's only normal restart path is ESP_RST_DEEPSLEEP (its own scheduled wake), and crash-type resets (brownout/watchdog/panic) report their own distinct reasons, not POWERON -- so a flaky power supply or transient crash won't get bounced into provisioning, only an actual power cycle or RST press will (which plausibly means the frame is being moved/redeployed anyway). Auto-fallback: a new NVS-persisted consecutive-failure counter (frame_config_record_server_failure/reset_server_failures) tracks wakes where the tools server was unreachable. After CONFIG_FRAME_REPROVISION_AFTER_FAILURES in a row (default 12, ~1hr at the retry interval), the device clears its stored WiFi config and esp_restart()s rather than calling wifi_provisioning_start() directly -- doing that inline would mean initializing the display driver a second time in the same session (frame_client_run already did once), the same class of double-init bug hit earlier with WiFi. The next boot's frame_config_load() naturally reports "not provisioned" and routes through the existing, already-tested provisioning path with a single fresh epd_init(). Solves the "I moved the server to a new address" case without needing USB access. Both frame_config_save() (fresh provisioning) and any successful server contact reset the failure counter.