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

kochetovvin

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

Вложения

kab

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

Алексей.

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

=AK=

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

Алексей.

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

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

pvvx

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

=AK=

New member
С чего пропадают "нескольких 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=

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

pvvx

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

=AK=

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

pvvx

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

Алексей.

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

Алексей.

Active member
На брокер не идут данные, и на входящие посылки не реагирует, также часы и температура на экране замирает.
Вы в скетче вызываете reconnect_server, в котором client.connect, пока он не завершился ничего и не работает :)
Вы логируете только результат выполнения client.connect, а факт вызова не логируете, если перед вызовом отправить в лог "connecting..." а через таймаут словить wdt то причина или WiFi или WiFiClient или PubSubClient
 
Сверху Снизу