1. Тема дня

Hardware watchdog, task watchdog, heartbeat, progress counters, reset reason, panic/core dump, fault snapshot, recovery. Главная мысль: watchdog кормят только тогда, когда вся система действительно здорова.

2. Зачем это нужно в проектах

Риски: EC25 завис, MQTT reconnect loop, input_task не обновляет фазы, I2C завис, UART/DMA parser не успевает, задача не отдаёт CPU, логирование блокирует, OTA зависает.

3. Теория

Виды watchdog:

text
Hardware watchdog - reset при отсутствии refresh. STM32 IWDG.
Window watchdog - refresh только в допустимом окне. STM32 WWDG.
Task/software watchdog - RTOS-level, например ESP-IDF TWDT.

Idle task работает - не значит, что modem/input/mqtt/i2c/transport здоровы. Правильно:

text
critical tasks -> heartbeat/progress -> health_supervisor
health_supervisor -> refresh watchdog only if healthy

Heartbeat = задача проснулась. Progress = задача сделала полезное действие: parsed AT response, processed input sample, sent/dropped event with accounting. Health state:

c
typedef enum { HEALTH_OK, HEALTH_WARN, HEALTH_STALE, HEALTH_FAULT } health_status_t;
typedef struct {
    const char *name;
    int64_t last_heartbeat_us;
    int64_t last_progress_us;
    uint32_t heartbeat_count;
    uint32_t progress_count;
    uint32_t fault_count;
    health_status_t status;
    uint32_t last_error_code;
} health_item_t;

Watchdog не заменяет recovery. Для EC25 сначала retry/reconnect/PDP reset/modem reset, потом system fault. Для I2C - timeout, bus recovery, reinit, device offline. После reset нужен fault snapshot с reset reason, unhealthy mask, last task, last error, heap, timestamps progress.

4. Типичные ошибки

  1. Кормить watchdog из timer interrupt.
  2. Кормить hardware watchdog из каждой задачи.
  3. Делать слишком короткий timeout.
  4. Не сохранять reset reason.
  5. Reboot вместо локальной recovery.
  6. Не учитывать debug/breakpoints.
  7. Не тестировать watchdog в HIL.

5. Практическое задание

Создай WATCHDOG_HEALTH_POLICY.md:

markdown
# Watchdog and health policy
Main rule:
Hardware watchdog is refreshed only by health_supervisor
and only if all critical subsystems are healthy.
Forbidden:
- refresh from timer interrupt;
- refresh from random tasks;
- refresh before checking progress;
- use watchdog as first recovery step;
- ignore reset reason after boot.

Health IDs:

c
typedef enum {
    HEALTH_INPUT = 0,
    HEALTH_PHASE,
    HEALTH_MODEM,
    HEALTH_MQTT,
    HEALTH_I2C,
    HEALTH_UART_DMA,
    HEALTH_LOGGER,
    HEALTH_COUNT
} health_id_t;

CLI health должен показывать progress age, heartbeat count, fault count и watchdog refresh status.

6. Что почитать или попробовать дальше

ESP-IDF Watchdogs, ESP-IDF Fatal Errors/Core Dump, STM32 IWDG/WWDG, DBGMCU debug freeze watchdog.

modem_task регулярно просыпается, но 30 s не обработала ни одной операции; состояние ONLINE требует progress. Какой вывод корректен?

Задание

EC25 потерял сеть, input_task продолжает корректно работать. Предложите recovery ladder и минимум fault snapshot. Где принимается решение о hardware watchdog refresh?

Критерии самопроверки: Разделите external outage и firmware stall; ограничьте retry и укажите единого supervisor плюс диагностический контекст.

Показать ответ автора

Сначала bounded retry/reconnect, затем PDP/modem reinitialization/reset по policy; при недоступной внешней сети возможен явный degraded mode. Snapshot: reset/fault reason, subsystem, last error, progress ages, boot/firmware identity, recent events. Hardware watchdog refresh решает один health supervisor по здоровью критичных функций, а не каждая task независимо.