dangernoodle-io / breadboard / 31760660237

97%

push

github

fix: subscribe bb_timer_disp to the task WDT by default (#1265)

- flips BB_TIMER_DISP_WDT_ENABLE's Kconfig default from n to y so the
  shared MODE_SHARED dispatcher task self-subscribes to the Task WDT at
  startup out of the box
- bb_timer_disp runs every MODE_SHARED work_fn synchronously with no
  per-callback timeout, so a single hung callback previously parked every
  periodic job on the dispatcher silently forever, with no warning and no
  reset_reason to attribute the stall to
- with the WDT subscribed, a wedged work_fn now trips the TWDT ISR, which
  logs the offending task by name -- an attributed WARNING where there was
  previously nothing at all. This is NOT a reboot and NOT self-recovery:
  every sdkconfig shipped in this repo has CONFIG_ESP_TASK_WDT_PANIC unset
  (examples/floor/sdkconfig.esp32:1404, examples/smoke/sdkconfig.esp32:1864),
  so the ISR re-arms and the dispatcher stays wedged exactly as before,
  just no longer silent. A reboot with reset_reason task_wdt only happens
  if a board owner also enables CONFIG_ESP_TASK_WDT_PANIC
- the warning is expected to stay visible even if bb_log itself is wedged.
  VERIFIED (not assumed) from the vendored IDF sources: the TWDT ISR logs
  via ESP_EARLY_LOGE -> ESP_LOG_EARLY_IMPL -> esp_rom_printf()
  (framework-espidf components/log/include/esp_log.h:251,258;
  task_wdt.c:491), a direct ROM-UART print path that bypasses bb_log's
  writer queue entirely
- the "a healthy tick cannot approach the 5s timeout" safety case rests on
  "no unbounded-HOLD blocking primitive on this path", not "no blocking
  primitive" at all -- floor's two MODE_SHARED ticks do cross one
  unbounded-WAIT mutex (components/bb_data/src/bb_data.c:178
  bb_data_render_rows -> bb_registry_lookup -> bb_lock_lock ->
  xSemaphoreTake(h, portMAX_DELAY) in platform/espidf/bb_core/bb_lock.c:156),
  safe only because the registry's critical sections are small
  memory-only linear scans with no I/O and no nested blocking, so hol... (continued)

8529 of 9048 branches covered (94.26%)

Branch coverage included in aggregate %.

14293 of 14448 relevant lines covered (98.93%)

2613.78 hits per line