[esp8266] Lower WDT_FEED_INTERVAL_MS to 100 ms

Restore tighter feed cadence on ESP8266 to match the smaller WDT
budgets on this platform. ESP8266 soft WDT is ~1.6 s and HW WDT is
~6 s; a single long iteration (mDNS reply, wifi scan, OTA verify,
lwIP TCP retransmit) can easily push the loop past a few hundred ms.
The 300 ms shared default left only ~1.3 s of soft-WDT headroom; 100 ms
restores ~16x margin to the soft WDT (matching pre-#15846 behavior in
spirit) without per-iteration arch_feed_wdt() cost.

Reports of Hardware WDT - Level1Int crashes on ESP8266 line up with
this margin being too tight under the new main-loop cadence.
This commit is contained in:
J. Nick Koston
2026-05-01 12:25:37 -05:00
parent 58cb7effd4
commit cf01be6250
+13 -5
View File
@@ -233,11 +233,10 @@ class Application {
/// loops and scheduler items still feed after every op, so any op exceeding
/// this threshold triggers a real feed naturally.
/// Safety margins vs. platform watchdog timeouts:
/// - ESP32 task WDT (user-configurable): ~5x <-- auto-scaled below
/// - ESP8266 soft WDT (~1.6 s): ~5x <-- floor case; any future change
/// must keep comfortable margin here
/// - ESP8266 HW WDT (~6 s): ~20x
/// - BK72xx HW WDT (10 s): ~5x <-- platform override below
/// - ESP32 task WDT (user-configurable): ~5x <-- auto-scaled below
/// - ESP8266 soft WDT (~1.6 s): ~16x <-- 100 ms feed (see USE_ESP8266 below)
/// - ESP8266 HW WDT (~6 s): ~60x
/// - BK72xx HW WDT (10 s): ~5x <-- platform override below
#ifdef USE_BK72XX
// BDK busy-waits 200us per WDT reload (sctrl_dpll_delay200us). LibreTiny
// sets HW WDT to 10s; 2000ms keeps ~5x margin. See wdt_ctrl WCMD_RELOAD_PERIOD:
@@ -257,6 +256,15 @@ class Application {
static_assert(CONFIG_ESP_TASK_WDT_TIMEOUT_S >= 5,
"CONFIG_ESP_TASK_WDT_TIMEOUT_S must be at least 5s for a safe WDT feed interval");
static constexpr uint32_t WDT_FEED_INTERVAL_MS = (CONFIG_ESP_TASK_WDT_TIMEOUT_S * 1000U) / 5U;
#elif defined(USE_ESP8266)
// ESP8266 needs a tighter feed cadence than the other targets: the soft WDT
// is ~1.6 s and the HW WDT ~6 s, but a single long iteration (mDNS reply,
// wifi scan, OTA verify, lwIP TCP retransmit storm) can push the loop past
// a few hundred ms without giving the SDK a chance to feed. 100 ms keeps a
// ~16x margin to the soft WDT and ~60x to the HW WDT while still avoiding
// the per-iteration arch_feed_wdt() cost (this is the rate limit; component
// loops and scheduler items still feed after every op).
static constexpr uint32_t WDT_FEED_INTERVAL_MS = 100;
#else
static constexpr uint32_t WDT_FEED_INTERVAL_MS = 300;
#endif