Read noise на wb-mqtt-serial и bootloop

Добрый день!
При запуске wb-mqtt-serial вижу много собщений read noise:

read noise:
read noise:  00
read noise:  01
read noise:  ff
read noise:  1f
read noise:  1d
read noise:  04
read noise:  0c
read noise:  00
read noise:  11
read noise:  9d
read noise:  d1
read noise:  00
read noise:  12
read noise:  4e
read noise:  3f
read noise:  00
read noise:  14

Кроме этого контроллер уходит в бутлуп. Приходит в нормальное состояние после отключения питания. Watchdog програмно отключен по этой статье.

Никогда такого раньше не видел, куда копать, что проверить?

Добрый день.
Шум на линии легко проверить - достаточно ее отключить и посмотреть - остается ли. И, кстати, такое может быть если где-то на шине замкнуты провода от разных шин, от порта ttyRS485-1 и 2.

При этом в Debug что-то пишет? А если отключить физически все кроме питания и сети - продолжает перезагружаться?
Если да - то надо посмотреть в Debug консоль - ну и поменяем контроллер.

Тот контроллер на объекте, проверить пока не могу.
В офисе замкнули A1-A2, B1-B2 между собой. Контроллер немного поработал в таком режиме и стал перезагружаться. HW 6.6.0.

Сейчас попробую воспроизвести. В офисном “подопытном” что-то (устройства) было настроено в serial?

Да, вот такой конфиг. И почти все устройства подключены.
wb-mqtt-serial.conf (8.2 КБ)

Воспроизвожу… Все ж подозреваю что и на объекте что-то похоже… Симптом очень уж характерный.

Да, такие же мысли. Все-таки контроллеры серийные, и ПО мы ставим тоже одинаковое, а конфигурация линии всегда разная, чаще из-за монтажа проблемы.

Возможно, после замыкания линии нужно перезапустить wb-mqtt-serial.
Версия 1.63.0, запускаю с флагом -d.

Добвольно старая версия.
На новых, 2.x не воспроизводится, скорее из-за того что в случае ответа от устройства оно некорое время не опрашивается.

Обновился до 2.7, ушел в перезагрузку.

То есть с wb-mqtt-serial 2.7 - контроллере 6.6 тоже перезапускается при соединении портов?

Да, причем даже быстрее. Просто замыкаю две линии и контроллер сразу уходит в ребут. 2 раза проверил.

Странно… Не воспроизводится, только вот такое сыплется:

июн 11 13:15:28 wirenboard-ACAX3M6K wb-mqtt-serial[11212]: WARNING: [modbus] failed to read 1 holding(s) @ 0 of device modbus:42: Serial protocol error: malformed response: invalid crc
июн 11 13:15:28 wirenboard-ACAX3M6K wb-mqtt-serial[11212]: WARNING: [modbus] failed to read 1 coil(s) @ 0 of device modbus:98: Serial protocol error: malformed response: invalid crc
июн 11 13:15:29 wirenboard-ACAX3M6K wb-mqtt-serial[11212]: WARNING: [modbus] failed to read 4 holding(s) @ 0 of device modbus:189: Serial protocol error: malformed response: invalid crc
июн 11 13:15:29 wirenboard-ACAX3M6K wb-mqtt-serial[11212]: INFO: [serial device] device modbus:189 is disconnected
июн 11 13:15:29 wirenboard-ACAX3M6K wb-mqtt-serial[11212]: INFO: [serial device] device modbus:42 is disconnected

wb-mqtt-serial=2.7.1
А на остановленном wb-mqtt-serial - тоже?

Отключил девайсы, оставил замктнутые цепи, подождал - работает.
Подключил девайсы, оставил цепи замкнутыми, подождал - работает.
Перезапускаю wb-mqtt-serial - ребут.

Сейчас проверю.

При остановленном wb-mqtt-serial не зависает, зависает секунд через 5 после старта.
wb-mqtt-serial.log (35.4 КБ)
В этот раз запускал без -d.

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

1 лайк

Супер. Поедем на объект исправлять шину.
А что может привести к ребуту? Причем именно в момент запуска шины. Специфичные помехи?

Нет, еще сам не разобрался, но судя по всему serial попадает в цикл (может, переполняет буфер?). Но точно не аппаратная проблема, если запустить по minicom на портах - все работает хорошо.
Собственно, тут привлеку программиста, надо понять.