Обсуждение ESP32 периодически зависает

[kochetovvin]

ESP32 периодически зависает, всегда по разному, раз в пару часов, или пару раз в день.
От разных блоков питания пробовал, сделал LC фильтр на питание, через хороший ИБП, лежит пока на столе с одним датчиком 18в20 на метровом проводе. Все равно зависает. Может дело все таки в "говнокоде"?
Мой первый проект, скетч собирал с миру по нитке. Вставил вчера вечером ресет по ватчтоду, теперь видно по логу MQTT, что за ночь перезапускалась два раза.
Кому не влом, пожалуйста посмотрите где накосячил.

 

[kab]

ESP32 периодически зависает, всегда по разному, раз в пару часов, или пару раз в день.
От разных блоков питания пробовал, сделал LC фильтр на питание, через хороший ИБП, лежит пока на столе с одним датчиком 18в20 на метровом проводе. Все равно зависает. Может дело все таки в "говнокоде"?
Мой первый проект, скетч собирал с миру по нитке. Вставил вчера вечером ресет по ватчтоду, теперь видно по логу MQTT, что за ночь перезапускалась два раза.
Кому не влом, пожалуйста посмотрите где накосячил.

Самое простое, с проверки чего несложно начать - сделайте вывод в лог значения свободной памяти и последите - не уменьшается ли она со временем до нуля.

 

[kochetovvin]

знать бы как, погуглю, попробую

 

[kab]

знать бы как, погуглю, попробую

В этом форуме были такие темы (правда по ESP8266 ), поищите через "поиск"

 

[Алексей.]

Самое простое, с проверки чего несложно начать - сделайте вывод в лог значения свободной памяти и последите - не уменьшается ли она со временем до нуля.

У меня отладочная плата esp32 devkit работала сутками от питания микро-усб подключенным к ПК под нагрузочным тестом, получал данные из udp и отправлял в spi, тестировал на предмет выпадения пакетов. Зависания не встречал, а вот последовательный порт на ПК иногда пропадал по непонятным причинам. Модуль продолжал работать, а оживить юсб-уарт можно было только выдергиванием.
Сначала нужно определиться куда отправлять лог, чтоб сам лог не стал причиной падения/зависания

 

[=AK=]

У последовательный порт на ПК иногда пропадал по непонятным причинам. Модуль продолжал работать, а оживить юсб-уарт можно было только выдергиванием.

В микрософтовском USB драйвере класса CDC есть несколько багов. В частности, есть и такой: при пропадании нескольких SOF порт перестает работать, но сбросить и заново инициализировать его программно невозможно, потому что он остается висеть в реестре. Помогает только передергивание шнура. Это была одна из основных причин, почему мы перестали использовать CDC и перешли на WinUSB, только тогда все стало работать более-менее надежно.

 

[Алексей.]

В микрософтовском USB драйвере класса CDC есть несколько багов.

Микросовтовского у меня нет , пропадает usb-uart на CP2102 в esp32-devkit, ещё чаще пропадает на CH340 в NodeMCU v3 и можно сказать ни разу на пропадал на простом usb-uart на пролифике.

Вставил вчера вечером ресет по ватчтоду, теперь видно по логу MQTT, что за ночь перезапускалась два раза.

А может он и не зависал вовсе, при длительном выполнении операций на сокете, Вы рискуете попасть как раз на вотчдог-таймер, например выполняете на сокете, который не перевели в неблокирующий режим, установление соединения с удаленным хостом, по различным причинам вызов connrct может выполняться длительное время и сработает тот самый вотчдог-таймер.

 

[=AK=]

Микросовтовского у меня нет

А, значит вы под Линуксом или под Маком? Они, получается, так же глючат, как Вынь...

 

[pvvx]

В микрософтовском USB драйвере класса CDC есть несколько багов. В частности, есть и такой: при пропадании нескольких SOF порт перестает работать, но сбросить и заново инициализировать его программно невозможно, потому что он остается висеть в реестре. Помогает только передергивание шнура. Это была одна из основных причин, почему мы перестали использовать CDC и перешли на WinUSB, только тогда все стало работать более-менее надежно.

С чего пропадают "нескольких SOF" ?

 

[=AK=]

С чего пропадают "нескольких SOF" ?

Например, от помех, а может, еще от чего. Они когда пропадают то не докладывают от чего. Согласно спецификации USB может пропадать до 5 SOF подряд. На практике наблюдается пропадание и 8, и даже 10 SOF подряд, надо только подождать подольше.

 

[pvvx]

А может он и не зависал вовсе, при длительном выполнении операций на сокете, Вы рискуете попасть как раз на вотчдог-таймер, например выполняете на сокете, который не перевели в неблокирующий режим, установление соединения с удаленным хостом, по различным причинам вызов connrct может выполняться длительное время и сработает тот самый вотчдог-таймер.

Какой WDT на RTOS в отдельном потоке (ESP-32)?

 

[pvvx]

Например, от помех, а может, еще от чего. Они когда пропадают то не докладывают от чего. Согласно спецификации USB может пропадать до 5 SOF подряд. На практике наблюдается пропадание и 8, и даже 10 SOF подряд, надо только подождать подольше.

Из общей картины выходит, что дрова на FTDI являются более лучшими, т.к. они более отлаженные. Но и среди них есть кривые версии. На все остальные чипы USB-COM дела хуже. До синих экранов в винде... Часто по причине переходов в спящий режим и ошибок в обработке аппаратных прерываний. Тут надо ещё учесть, что windows 95 вообще не имеет внутренней поддержки USB на уровне ядра системы...

 

[=AK=]

Из общей картины выходит, что дрова на FTDI являются более лучшими,

SiLabs вроде тоже ничего. И еще есть CDC дрова Thesycon, которые ставятся вместо мелкомягких и работают очень хорошо - по крайней мере то, что успели протестировать на бесплатной, но ограниченной по времени, тестовой версии, там багов не обнаружено. Но цена у них конская.

 

[pvvx]

У большинства программ существует глюк, когда COM порт открыт, а USB устройство отключили и включили заново. Даже при повторном закрытии и открытии COM порта связи с устройством нет. Это сказывается на всех перечисленных тут микросхемах USB-COM, но не на FTDI. Причину не устанавливал, т.к. это зависит от верхнего уровня реализации самих программ, а не дров. И это чистая статистика по практике, когда комп используется для работы с пачками разных устройств на USB-COM.
А вот отваливаний на ходу не наблюдается ни где, кроме случаев когда комп или устройство USB переключается в спящий режим. В таких случаях до синего экрана вероятность в 10% у многих китайских чипах и дров к ним... Меняете дрова и это пропадает.

 

[=AK=]

У большинства программ существует глюк, когда COM порт открыт, а USB устройство отключили и включили заново. Даже при повторном закрытии и открытии COM порта связи с устройством нет. Это сказывается на всех перечисленных тут микросхемах USB-COM, но не на FTDI. Причину не устанавливал, т.к. это зависит от верхнего уровня реализации самих программ, а не дров.

У нас прикладуха написана на С-шарпе. Пока сидели на CDC, то никакие танцы с бубном не помогали. В том числе не помогали программные вочдоги со стороны мелкоконтроллера, с аппаратным сбросом USB и пере-инициализацией USB стека. Пришли к мнению, что это баг в дровах CDC. С дровами WinUSB никаких проблем нет, все пашет.

 

[pvvx]

Для TC это не актуально. Большинство программ мониторов не отваливает COM на ходу.
Если это происходит, то 95% в том, что беда с питанием у USB устройства.
Желательно вырубить переход в спящий режим компа или устройства с USB-COM для набора лога...

 

[Алексей.]

Какой WDT на RTOS в отдельном потоке (ESP-32)?

В отдельном таске на сокете, который не перевел в nonblocking режим, вызываю recv и через некоторое время в уарте вижу ругань от WDT, вот так.

 

[kochetovvin]

А может он и не зависал вовсе

На брокер не идут данные, и на входящие посылки не реагирует, также часы и температура на экране замирает.

 

[Алексей.]

У большинства программ существует глюк, когда COM порт открыт, а USB устройство отключили и включили заново. Даже при повторном закрытии и открытии COM порта связи с устройством нет.

Это не глюк, приложение не детектирует отключение устройства и своевременно не закрывает порт, после нового подключения, если повезет, наше устройство уже оказывается на новом порту.
Монитором назвать такое приложение сложно, не понятно по какой причине эти так называемые "мониторы" позволяют вводить только название ком-порта например COM3, а не дают возможность определять порт по описанию драйвера например "Silicon Labs CP210x USB to UART Bridge" или матчить по FriendlyName

 

[Алексей.]

На брокер не идут данные, и на входящие посылки не реагирует, также часы и температура на экране замирает.

Вы в скетче вызываете reconnect_server, в котором client.connect, пока он не завершился ничего и не работает
Вы логируете только результат выполнения client.connect, а факт вызова не логируете, если перед вызовом отправить в лог "connecting..." а через таймаут словить wdt то причина или WiFi или WiFiClient или PubSubClient