Ошибки в системном журнале при обновлении устройств

Периферийные устройства
1

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

вот такое для всех обновляемых устройств было:

Summary

image
image1383×1038 150 KB

console_log.txt (78.2 KB)

приложен диагностический архив, доступен только сотрудникам поддержки
(654.0 KB)

3

Здравствуйте! Я автоматический помощник технической поддержки Wiren Board.
Я проанализировал ваш вопрос и постарался найти возможное решение:

Судя по скриншоту и описанию, речь идёт об обновлении модулей по RS‑485 (скорее всего линии с WB-M* устройствами) через веб‑интерфейс / инструмент wb-mcu-fw-updater. В логах видно:

  • предупреждение Device (70, /dev/ttyRS485-2) has too old bootloader to save user data!
  • затем стек вызовов с ошибкой wb_modbus.minimalmodbus.NoResponseError: No communication with the instrument (no answer) и далее FlashingError.

Что это значит

  1. Сообщение про “too old bootloader to save user data”
    Это не критическая ошибка, а предупреждение: у старых ревизий модулей загрузчик не умеет сохранять пользовательские регистры при прошивке.
    В результате при обновлении такая прошивка:

    • сама по себе проходит корректно;
    • но конфигурация модуля может сброситься к заводским значениям (скорость, сетевой адрес, режимы входов/выходов и т.п.), если загрузчик действительно старый.

  2. No communication with the instrument (no answer) во время прошивки
    При обновлении устройства переводятся в специальный режим загрузчика. На этот момент:

    • обычный Modbus‑опрос их «теряет» и в системном журнале появляются ошибки отсутствия связи;
    • updater, наоборот, общается уже с загрузчиком.
      Если в итоге все устройства прошились и снова нормально опрашиваются — значит эти ошибки в логах отражают только временный разрыв связи в процессе прошивки, а не реальную проблему.

Что имеет смысл проверить

  1. После обновления:

    • Убедиться, что устройства отвечают по ожидаемым адресам и с нужной скоростью (через вкладку Устройства и/или wb-mqtt-serial[1].
    • Проверить и при необходимости восстановить параметры модулей (режимы входов/выходов и другие настройки), если вы меняли их от заводских.

  2. На будущее:

    • Если есть важная нестандартная конфигурация модулей, перед массовым обновлением стоит сохранить её (через wb-mqtt-serial.conf / шаблоны и, при необходимости, отдельный скрипт чтения нужных регистров) и быть готовым повторно применить после прошивки[2].

Если после проверки все модули работают штатно и настройки вас устраивают, текущие сообщения в журнале можно считать нормальными «служебными» логами процесса обновления и поводом для действий они не являются.

Если вы заметите, что у какого‑то устройства реально «слетела» конфигурация или оно перестало отвечать, напишите, пожалуйста, модель устройства, адрес на шине и выдержку из лога вокруг ошибки — подберём уже конкретные шаги.

Примечание: Я — искусственный интеллект, а не сотрудник-человек. В моих ответах возможны неточности.

  1. Драйвер wb-mqtt-serial — Wiren Board ↩︎

  2. https://wirenboard.com/wiki/RS-485_Modbus ↩︎

5

Добрый день. Благодарю за ожидание. Поясните, пожалуйста:

  1. О каких устройствах идет речь? с серийными номерами, пожалуйста
  2. Каким способом проводили обновление? ссылкой на инструкцию, желательно.
6

console.log в первом посте

Summary

image
image1089×1289 101 KB

7

Здравствуйте. Простите, потерял вашу тему. Попросил коллегу помочь.

1 Like
10

Извините, плохо получилось с вашем темой…давайте разбираться

  1. В стек‑трейсе ключевая строка:
wb_modbus.minimalmodbus.NoResponseError: No communication with the instrument (no answer)

Т.е. во время шага _send_info() / write_u16_regs() модуль по Modbus перестал отвечать. В результате поднимается FlashingError и это устройство считается не прошитым.

Типичные причины для такого «No communication with the instrument» именно при прошивке:

  • временный обрыв/шум на линии RS‑485 (особенно при длинной шине и высокой скорости);
  • слабое питание модуля (просадка на момент перезагрузки в загрузчик);
  • слишком маленький таймаут/большая нагрузка на шину (много устройств, прошивка идёт параллельно с опросом);
  • модуль ушёл в загрузчик (скорость/параметры в нём другие), а wb-mcu-fw-updater не удалось к нему «переключиться».
  1. Тем временем, в console.log в первом посте нет никаких ошибок.

Если смотреть на один и тот отрезок времени в логах и в стек‑трейсе:
Там в 12:42:34.301 видно:

NoResponseError: No communication with the instrument (no answer)
...
raise_from
wb_mcu_fw_updater.fw_flasher.FlashingError

Это следующий шаг wb-mcu-fw-updater: после записи bootloader’а он пытается отправить «служебную» информацию (_send_info – регистры с версией/моделью). В этот момент:

  • устройство уже перезагрузилось с новым загрузчиком;
  • часть команд/регистров могла стать недоступна или оно ещё не успело подняться;

У вас осталось какое-либо непонимание описанного? если да, то чего именно?

14

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