Mechanizm bootloadera i odzyskiwania oprogramowania czytnika — przewodnik dla nabywców B2B

Odbiorcy: Niniejszy przewodnik jest przeznaczony dla kierowników zespołów inżynierii sprzętowej, architektów oprogramowania sprzętowego OEM oraz kierowników serwisu terenowego, którzy muszą zwalidować architekturę bootloadera, dwubankową pamięć flash, odzyskiwanie po aktualizacji OTA oraz zachowanie trybu DFU w danym SKU czytnika, zanim zatwierdzą produkcję masową. Do drugorzędnych odbiorców należą kierownicy ds. kontroli jakości opracowujący plany testów odzyskiwania po brickowaniu oraz operatorzy aktualizacji OTA zarządzający aktualizacjami dużych flot urządzeń.

Meksykański dystrybutor skontaktował się z nami w połowie 2025 roku, ponieważ aktualizacja OTA oprogramowania sprzętowego spowodowała zbrickowanie 312 z 1800 czytników K7 pracujących w terenie. Czytniki otrzymały paczkę OTA przez BLE, rozpoczęły jej zapis do pamięci flash, a następnie utraciły zasilanie w trakcie zapisu, ponieważ czytniki były przewożone na szkolnych wózkach z niestabilnym stykiem USB-C. Czytnik się włączał, zielona dioda LED migała przez 200 ms, a następnie gasła. Przyczyną brickowania był brak architektury dwubankowej pamięci flash: czytnik posiadał tylko jeden bank flash, a aktualizacja OTA nadpisywała działające oprogramowanie sprzętowe. Po utracie zasilania nowe oprogramowanie było niekompletne i czytnik nie mógł się uruchomić. Rozwiązaniem było dodanie drugiego banku flash oraz bootloadera, który zawsze uruchamia się z prawidłowego banku. Każdy czytnik w naszym katalogu (B1, B2, F8, K7, KF1, L5, P2, Q6, Q8, T2, Y6) wykorzystuje architekturę dwubankowego bootloadera, a niniejszy przewodnik wyjaśnia, jak ta architektura przekłada się na niezawodność OTA i odzyskiwanie po brickowaniu.

1. Architektura dwubankowej pamięci flash

W naszym katalogu stosujemy architekturę dwubankowej pamięci flash. Mikrokontroler posiada 8 MB lub 16 MB wewnętrznej pamięci flash, podzielonej na dwa równe banki. Bank A przechowuje aktualnie działające oprogramowanie sprzętowe; Bank B przechowuje poprzednie oprogramowanie sprzętowe lub przychodzącą paczkę OTA. Bootloader w momencie startu odczytuje wersję oprogramowania z każdego banku i wybiera prawidłowy bank.

Logika wyboru banku jest następująca:

1. Jeśli Bank A jest prawidłowy i wersja Banku A > wersja Banku B, uruchom z Banku A.
2. Jeśli Bank A jest prawidłowy, a Bank B jest nieprawidłowy, uruchom z Banku A.
3. Jeśli Bank A jest nieprawidłowy, a Bank B jest prawidłowy, uruchom z Banku B i oznacz Bank A jako wymagający ponownego zapisu.
4. Jeśli oba banki są nieprawidłowe, wejdź w tryb DFU (Device Firmware Upgrade) i czekaj na wgranie oprogramowania przez USB-C.

Sprawdzanie poprawności polega na obliczeniu CRC32 dla obrazu oprogramowania sprzętowego, wykonywanym przez bootloader w momencie startu. CRC32 jest przechowywany w nagłówku oprogramowania, a bootloader odczytuje nagłówek, oblicza CRC32 dla obrazu i porównuje. Jeśli CRC32 się zgadza, bank jest prawidłowy. Jeśli nie, bank jest nieprawidłowy.

Narzut czasowy bootowania związany ze sprawdzaniem dwóch banków wynosi 240 ms, co jest pomijalne w porównaniu z 1,8-sekundowym zimnym startem.

2. Procedura aktualizacji OTA

Procedura aktualizacji OTA dla każdego SKU przebiega w ściśle określonej kolejności, aby zapobiec sytuacjom zablokowania urządzenia:

1. Host (aplikacja mobilna lub narzędzie na PC) pobiera nowy obraz firmware z serwera w chmurze.
2. Host oblicza CRC32 dla nowego obrazu firmware i weryfikuje go z podpisem przechowywanym w chmurze.
3. Host nawiązuje połączenie BLE z piórem i uwierzytelnia się 6-cyfrowym kodem PIN.
4. Host przesyła obraz firmware do pióra w paczkach po 4 KB przez BLE.
5. Pióro zapisuje każdą paczkę w Banku B (nieaktywny bank) i weryfikuje CRC32 każdej paczki.
6. Po przesłaniu wszystkich paczek pióro weryfikuje pełne CRC32 Banku B.
7. Pióro ustawia flagę „oczekującej aktualizacji” w domenie zawsze aktywnego RTC.
8. Pióro wykonuje restart. Bootloader sprawdza flagę, zamienia wskaźnik aktywnego banku i uruchamia nowy obraz.

Kluczowym krokiem jest krok 5: zapis do nieaktywnego banku. Bank A nie jest w ogóle naruszany aż do kroku 8, po pełnym zapisaniu i zweryfikowaniu nowego obrazu. Jeśli pióro utraci zasilanie w dowolnym momencie kroków 4–7, bootloader wykryje niekompletny Bank B i prawidłowy Bank A oraz uruchomi system z Banku A. Pióro nie zostaje zablokowane.

Problem z meksykańskim K7 dotyczył innego SKU (starszego projektu), który nie posiadał architektury dwubankowej. Obecny K7 z firmware 1.9.5 posiada architekturę dwubankową oraz opisaną powyżej procedurę OTA. Nie odnotowaliśmy żadnego przypadku zablokowania urządzenia w SKU z architekturą dwubankową w ciągu 24 miesięcy od wdrożenia tej architektury w całym katalogu.

3. Tryb DFU i odzyskiwanie po zablokowaniu

Jeśli zarówno Bank A, jak i Bank B są nieprawidłowe (co nie powinno mieć miejsca w normalnej eksploatacji), pióro przechodzi w tryb DFU. W trybie DFU bootloader udostępnia interfejs USB-C, który przyjmuje surowy upload firmware. Tryb DFU jest sygnalizowany szybko migającą czerwoną diodą LED (3 Hz, cykl pracy 50%).

Narzędzie do uploadu DFU to dedykowane narzędzie wiersza poleceń producenta, działające w systemach Windows, macOS i Linux. Narzędzie przesyła obraz firmware do pióra w paczkach po 64 KB, a bootloader zapisuje każdą paczkę w Banku A. Po przesłaniu pełnego obrazu bootloader weryfikuje CRC32 i uruchamia system z Banku A. Upload DFU trwa 18 sekund dla obrazu 8 MB i 36 sekund dla obrazu 16 MB przez USB 2.0 High Speed.

Tryb DFU jest również dostępny podczas normalnej pracy poprzez przytrzymanie przycisku zasilania przez 12 sekund. 12-sekundowe przytrzymanie jest celowym rozwiązaniem, aby zapobiec przypadkowemu wejściu w tryb DFU. Szybko migająca czerwona dioda LED daje użytkownikowi wyraźny sygnał wizualny, że pióro znajduje się w trybie DFU.

4. Wersja bootloadera i mechanizm aktualizacji

Sam bootloader jest przechowywany w oddzielnym, tylko do odczytu obszarze pamięci flash, który nie może być nadpisany przez aktualizację OTA. Wersja bootloadera jest niezależna od wersji firmware. Od 2023 roku wprowadziliśmy trzy wersje bootloadera:

• Bootloader v1.0 (2023): podstawowy dual-bank, sprawdzanie CRC32, tryb DFU.
• Bootloader v1.2 (2024): dodano weryfikację podpisu firmware za pomocą ECDSA-P256.
• Bootloader v2.0 (2025): dodano ochronę przed rollbackiem (nie można uruchomić wersji firmware starszej niż aktualnie znajdująca się w Banku A, chyba że zostanie to jawnie włączone).

Bootloader może być aktualizowany, ale wyłącznie poprzez upload firmware przez USB-C skierowany bezpośrednio na obszar bootloadera. Aktualizacja bootloadera wymaga 12-sekundowego przytrzymania przycisku zasilania, a dioda LED świeci na niebiesko podczas aktualizacji. W historii linii produktowej dwukrotnie wydaliśmy aktualizacje bootloadera: z v1.0 do v1.2 w połowie 2024 r. oraz z v1.2 do v2.0 na początku 2025 r. Aktualizacje zostały zastosowane w ponad 12 000 działających piór w terenie ze 100% skutecznością.

5. Weryfikacja podpisu firmware

Od wersji bootloadera v1.2 każdy obraz firmware jest podpisywany podpisem ECDSA-P256. Podpis jest przechowywany w nagłówku firmware obok CRC32. Bootloader przechowuje klucz publiczny w obszarze jednokrotnego programowania (OTP) mikrokontrolera, a klucz publiczny jest ustawiany podczas provisionowania fabrycznego. Bootloader weryfikuje podpis w momencie uruchomienia, przed przełączeniem na nowy obraz.

Weryfikacja podpisu chroni przed złośliwym payloadem OTA. Bez podpisu atakujący mógłby skonstruować obraz firmware z prawidłowym CRC32, ale zawierający złośliwy kod. Podpis ECDSA-P256 wymaga 32-bajtowego klucza prywatnego przechowywanego wyłącznie w fabryce. Nie odnotowaliśmy ani jednego przypadku złośliwej aktualizacji OTA w ciągu 24 miesięcy od włączenia weryfikacji podpisu.

Subtelny punkt: klucz podpisu jest przypisany do fabryki, a nie do klienta. Jeśli kupujący OEM chce klucz podpisu przypisany do klienta (aby fabryka nie mogła wgrywać firmware do piór OEM), możemy provisionować klucz specyficzny dla klienta w obszarze OTP przy wzroście kosztu BOM o 0,04 USD na jednostkę i 4-tygodniowym czasie konfiguracji provisionowania.

6. Ochrona przed rollbackiem

Bootloader v2.0 dodał ochronę przed rollbackiem. Bootloader przechowuje numer wersji ostatnio uruchomionego firmware w domenie zawsze aktywnego RTC i odmawia uruchomienia wersji firmware starszej niż ta. Ochrona ta zapobiega cofaniu firmware przez atakującego do wersji z luką. Ochronę można wyłączyć za pomocą klucza specyficznego dla OEM w nagłówku firmware.

Dla kupujących OEM, którzy potrzebują możliwości downgrade (np. w celu wycofania firmware w zarządzaniu flotą podczas etapowego wdrażania), możemy wyłączyć ochronę przed rollbackiem dla każdego klienta indywidualnie. Bit wyłączający jest ustawiany w nagłówku firmware podczas provisionowania fabrycznego i nie może być zmieniony przez payload OTA.

7. Zachowanie przy utracie zasilania podczas OTA

Proces zapisu OTA do Banku B jest zaprojektowany tak, aby przetrwać utratę zasilania w dowolnym momencie. Zapis wykorzystuje schemat journalingu: każda paczka 4 KB jest zapisywana z 16-bajtowym nagłówkiem zawierającym numer sekwencyjny, CRC32 oraz flagę „complete”. Bootloader może wykryć niekompletny zapis, sprawdzając flagę „complete” i numer sekwencyjny.

Jeśli bootloader wykryje niekompletny zapis, oznacza bank jako nieprawidłowy i uruchamia system z prawidłowego banku. Nieprawidłowy bank pozostaje do nadpisania przez następną aktualizację OTA. Nie ma „utraconej” przestrzeni flash, ponieważ nagłówek journalingu jest częścią paczki 4 KB i bootloader ponownie wykorzystuje tę samą paczkę przy następnym zapisie.

Schemat zapisu z journalingiem pozostawia w najgorszym przypadku 4 KB niespójnych danych po utracie zasilania, ale sprawdzenie CRC32 to wychwytuje, a bank jest oznaczany jako nieprawidłowy. Pióro nigdy nie zostaje zablokowane.

8. Autotest OTA bootloadera

Każda partia produkcyjna modeli L5, Q6, Q8, T2 i Y6 przechodzi przed wysyłką 12-elementowy autotest bootloadera. Autotest wykonuje następujące czynności:

1. Zapis prawidłowego obrazu firmware w Banku B i weryfikacja, czy bootloader uruchamia się z niego.
2. Zapisz uszkodzony obraz (błędny CRC32) do Banku A i sprawdź, czy bootloader przełączy się awaryjnie na Bank B.
3. Zapisz uszkodzony obraz w obu bankach i sprawdź, czy bootloader przejdzie w tryb DFU.
4. Prześlij obraz firmware przez tryb DFU i sprawdź, czy bootloader uruchomi się z niego.

W 2025 roku zatrzymaliśmy 3 partie ze 168 z powodu awarii autotestu bootloadera. Dwie zostały powiązane z wadliwą partią kości pamięci flash od dostawcy Tier-2; trzecia wynikała z niezgodności rewizji bootloadera, wykrytej przez kontrolę CRC32.

9. Diagnostyka terenowa problemów z uruchamianiem

Gdy klient zgłasza długopis, który się nie uruchamia, prosimy go o przytrzymanie przycisku zasilania przez 12 sekund, aby wejść w tryb DFU. Jeśli długopis wejdzie w tryb DFU (szybko migająca czerwona dioda LED), problem leży w uszkodzonym obrazie firmware w obu bankach i jest możliwy do odzyskania przez wgranie przez DFU. Jeśli długopis nie wejdzie w tryb DFU (brak jakiejkolwiek reakcji diody LED), oznacza to awarię sprzętową, której nie można usunąć w terenie i która wymaga naprawy fabrycznej.

Stosunek awarii uruchamiania odzyskiwalnych przez DFU do awarii sprzętowych w naszych danych terenowych z 2025 roku wynosi 87:13. Te 87% jest zwykle spowodowane przerwaniem aktualizacji OTA w wyniku utraty zasilania lub rozłączenia BLE podczas fazy zapisu. Te 13% zwykle wynika z awarii kości pamięci flash, zwarcia na linii zasilania lub uszkodzenia złącza.

Udostępniamy narzędzie DFU przeznaczone dla klienta końcowego, które każdy kupujący OEM może oznakować własną marką i dystrybuować swoim użytkownikom końcowym. Narzędzie działa na Windows, macOS, Linux i Android (przez USB-C OTG) i zawiera instrukcję krok po kroku dla użytkowników nietechnicznych.

10. 12-miesięczna roadmap technologii bootloadera na przód

Śledzimy trzy ulepszenia bootloadera, które trafią do katalogu do Q4 2026. Po pierwsze, architekturę potrójnego banku A/B/C w przyszłym premium SKU, pozwalającą na jednoczesne przechowywanie dwóch payloadów OTA i umożliwiającą natychmiastowy rollback do znanej dobrej wersji bez ponownego pobierania. Po drugie, opcję szyfrowanego firmware w przyszłym premium SKU, wykorzystującą AES-128 do szyfrowania obrazu firmware at rest, chroniącą przed atakami polegającymi na zrzucie pamięci flash. Po trzecie, koordynowany w chmurze mechanizm OTA, który planuje fazę zapisu OTA w znanym bezpiecznym oknie ładowania (długopis na ładowarce, bateria > 50%, temperatura < 35 °C), aby zminimalizować ryzyko uceglenia w wyniku utraty zasilania.

Opublikujemy raport uzupełniający po wysyłce architektury potrójnego banku do prób terenowych. W międzyczasie architektura bootloadera w naszym katalogu jest dojrzała, dobrze zwalidowana i dobrze wspierana, a każdego kupującego OEM z niestandardowym wymaganiem dotyczącym aktualizacji firmware zapraszamy do kontaktu z naszym zespołem ODM reading pens w celu przeglądu wykonalności.

Powiązane lektury

• Architektura firmware długopisu do czytania wyjaśniona
• Mechanizm aktualizacji OTA firmware długopisu do czytania
• Watchdog i reset systemu długopisu do czytania
• RTC zegara czasu rzeczywistego i podtrzymywania czasu w długopisie do czytania
• PMIC układu zarządzania zasilaniem długopisu do czytania
• Zarządzanie zasilaniem i optymalizacja pracy długopisu do czytania
• Playbook rozwiązywania problemów z długopisem do czytania
• Kontrola jakości i normy AQL długopisu do czytania