В общем понял я, что ESP.wdtEnable(1000) не работает.
Но работает ESP.wdtDisable(). После этого, где-то секунд через 6-8 срабатывает аппаратный wdt.
Управление в Arduino WDT не работает.
Таймеров WDT задействовано три: сам WDT, счетчик системного времени с защелками (аппаратный 64 битный с шагом 1 us для
TSF WiFi), обычный софтовый таймер... Проверяются условие выполнения за период некоторых процедур...
Что собственно хочется - если устройство подвиснет, то сработал wdt.
Нереально. Вы не первый, кто этого хочет, но не решил.
Примеры аналогичных тем по поиску найдете с десяток...
Для себя я переписал все процедуры WDT в Web-свалке... Но проблема у ESP8266 не в WDT, а в зависоне после его софт-перезагрузки...
Ставьте внешний MCU, который будет устанавливать не менее 4-х пинов для правильной загрузки, отключать питание ESP8266 (в крайнем случае дергать RESET с установкой пинов в правильный режим), контролировать плавные включения питания (BOR у ESP тоже дурит), как-то вылавливать сбой-отваливание station WiFi (программно имеет всего один метод это понять - пинг внешнего сервера, и ни какие софт-сбросы ESP8266 не помогают), ну и осуществлять главную необходимую функцию - WDT. Тогда "
хочется - если устройство подвиснет, то сработал wdt." может и получится.
Без внешних костылей у ESP с WDT всё плохо...
У ESP и так всего пару проблем, которые теперь только и обсуждают, но решения их нет:
1) Нормальный старт (правильные установки пинов для старта загрузкой с Flash)
2) Отваливание station при приеме “неподходящих для ESP
” пакетов по WiFi c большим уровнем сигнала, при этом всё ПО говорит, что она подключена, а чип или занят глушением эфира или иногда, очень редко, слетает в протектед.
3) Невозможность соединений SSL на современных требованиях (где размер ключа более 128 бит)
Ну и мелкие глюки, как раз связанные с вашей темой – не всегда работает soft reset функция. Два варианта – или сразу, вместо перезагрузки виснет навеки, или ESP стартует не в том режиме. Например, в режим "программирования" и так в нем и живет, пока не сбросят. При этом команда перехода в deep-sleep на несколько ms, используемая вместо 2-х имеющихся soft reset функций в SDK, перебрасывает ESP значительно более стабильнее, если сделаны правильные соединения и подтяжки. Но имеет другой баг – при рестарте не всегда ESP понимает, что был перезапуск по deep-sleep, т.к. в последних командах процедуры выхода в deep-sleep имеется ошибка – проц улетает в область отключенной Flash по команде ret и исполняет команды пустой шины с шумовыми значениями, и часто, до срабатывания внутреннего устройства отключения (видимо оно тактируется низкочастотным RC генератором RTC), успевает нарваться на протектед и записать это в память RTC вместо deep-sleep…
Espressif эти все баги не чинит уже более года и похоже не собирается...
Это к тому, с чем вам придется столкнуться ради излечения WDT у ESP8266.