Architektura watchdoga i resetu systemu w długopisach czytających dla nabywców B2B

Odbiorcy: Niniejszy przewodnik jest skierowany do liderów zespołów inżynierii sprzętowej, architektów firmware OEM oraz inżynierów ds. niezawodności, którzy muszą zwalidować działanie watchdoga (WDT) oraz zachowanie resetu systemu danego SKU długopisu czytającego przed zatwierdzeniem produkcji masowej. Do drugorzędnych odbiorców należą inżynierowie serwisu terenowego debugujący zgłoszenia zawieszania się długopisu oraz kierownicy QA projektujący profile testów obciążeniowych dla procedury odtwarzania po zawieszeniu firmware.

Brazylijski dystrybutor skontaktował się z nami w I kwartale 2026 r., ponieważ jego długopisy T2 zawieszały się w terenie z częstotliwością 1,4% miesięcznie. Zawieszenie objawiało się zamrożoną diodą LED, brakiem wyjścia audio oraz brakiem odpowiedzi BLE. Pobraliśmy z pola 12 zawieszonych egzemplarzy, podłączyliśmy debugger JTAG i stwierdziliśmy, że mikrokontroler wszedł w stan hard-fault z powodu dereferencji wskaźnika null w firmware rozpoznawania OID. Watchdog powinien był wykryć hard-fault i zresetować długopis, ale watchdog nie był serwisowany, ponieważ sam handler hard-fault był źródłem dereferencji. Rozwiązaniem było przeniesienie serwisu watchdoga do sprzętowego przerwania timerowego, które jest wyzwalane niezależnie od stanu pętli głównej. Każdy długopis czytający w naszym katalogu (B1, B2, F8, K7, KF1, L5, P2, Q6, Q8, T2, Y6) wykorzystuje watchdog, a niniejszy przewodnik omawia, w jaki sposób architektura WDT przekłada się na odtwarzanie po zawieszeniu firmware oraz ogólną niezawodność systemu.

1. Dwie architektury watchdoga

W katalogu stosujemy dwie architektury watchdoga. W warstwie ekonomicznej (B1, B2, F8, P2) używamy wewnętrznego okienkowego watchdoga (WWDT) mikrokontrolera – 12-bitowego licznika zliczającego w dół, taktowanego z wewnętrznego oscylatora RC 32 kHz. WWDT musi być serwisowany w oknie 64 ms, a pominięcie serwisu powoduje reset systemu. Konstrukcja okienkowego watchdoga wykrywa zarówno nieskończone pętle (które serwisowałyby WWDT zbyt późno), jak i serwis wywołany „zbyt wcześnie” (przed otwarciem okna).

Warstwa średnia i premium (K7, KF1, L5, Q6, Q8, T2, Y6) wykorzystuje dodatkowo zewnętrzny sprzętowy watchdog (HWDT) w postaci dedykowanego układu nadzorcy, niezależnego od wewnętrznego WWDT. HWDT monitoruje sygnał resetu mikrokontrolera oraz dedykowaną linię GPIO przełączaną przez firmware. Jeśli GPIO nie zostanie przełączone w ciągu 1,6 sekundy, HWDT ściąga linię resetu do stanu niskiego i wymusza pełny reset typu power-on. HWDT dodaje 0,06 USD do kosztu jednostkowego, ale wykrywa tryb awarii, w którym mikrokontroler żyje, lecz utknął w procedurze obsługi przerwania, która nie serwisuje WWDT. To właśnie ten tryb awarii wystąpił w modelu T2 w terenie.

Architektura podwójnego watchdoga w SKU warstwy średniej i premium wykrywa zarówno tryb awarii „zawieszenia pętli głównej” (wykrywany przez WWDT), jak i tryb awarii „zawieszenia handlera przerwań” (wykrywany przez HWDT). SKU warstwy ekonomicznej wykrywają wyłącznie tryb zawieszenia pętli głównej, ponieważ nie posiadają HWDT.

Wskaźnik odzyskiwania po zawieszeniu jest mierzony jako odsetek zawieszeń firmware'u, które kończą się pomyślnym resetem w ciągu 2 sekund od zdarzenia zawieszenia. 7-punktowa procentowa różnica między SKU ekonomicznymi a średnimi/premium to korzyść płynąca z podwójnego watchdoga.

2. Dyscyplina usługi Window Watchdog

Window watchdog musi być obsłużony w ściśle określonym oknie czasowym. Okno otwiera się 32 ms po uruchomieniu licznika WWDT i zamyka się po 64 ms. Obsługa WWDT przed otwarciem okna lub po jego zamknięciu wywołuje reset. Konstrukcja okna chroni przed trybami awarii typu „utknięcie w szybkiej pętli”, w których firmware żyje, ale nie robi postępów.

Dyscyplina obsługi na każdym SKU wymaga, aby firmware zapisał określoną wartość magiczną (0x5A5A5A5A) do rejestru obsługi WWDT w obrębie okna. Wartość magiczna jest celowo nietrywialna, aby niekontrolowany wskaźnik zapisujący sekwencyjne lokalizacje pamięci nie obsłużył przypadkowo WWDT. W ciągu ostatnich 24 miesięcy odnotowaliśmy trzy awarie w terenie, w których niekontrolowany wskaźnik zapisał wartość magiczną przez przypadek; WWDT prawidłowo zresetował pióro przy każdej okazji.

Licznik WWDT resetuje się do wartości początkowej przy każdej pomyślnej obsłudze. Licznik jest dekrementowany przy każdym tyknięciu zegara 32 kHz. Jeśli licznik osiągnie zero bez obsługi, WWDT generuje reset systemu.

3. Zewnętrzny sprzętowy watchdog

Zewnętrzny HWDT w średnich i premium SKU to 4-pinowy układ nadzorczy, który monitoruje linię resetu MCU i dedykowany GPIO. HWDT ma własny wewnętrzny oscylator i licznik, niezależny od MCU. Licznik HWDT jest resetowany za każdym razem, gdy firmware przełącza GPIO, co musi następować co najmniej raz na 1,6 sekundy. Jeśli licznik osiągnie zero, HWDT ściąga linię resetu do stanu niskiego na 200 ms i wymusza pełny reset po włączeniu zasilania.

HWDT monitoruje również szynę VDD MCU. Jeśli VDD spadnie poniżej 2,7 V (próg zaniku napięcia), HWDT ściąga linię resetu do stanu niskiego i utrzymuje ją w tym stanie, aż VDD ponownie wzrośnie powyżej 2,85 V. Ochrona przed zanikiem napięcia jest niezależna od wewnętrznego detektora zaniku napięcia MCU, co daje nam dwa niezależne monitory napięcia.

HWDT kosztuje 0,06 USD za sztukę i zajmuje 1,2 mm × 1,4 mm powierzchni PCB. W SKU z wąską lufą (F8, K7, KF1, Q6, Q8) HWDT jest umieszczony na tylnej stronie PCB, aby zminimalizować wpływ na szerokość. W większych SKU (L5, T2, Y6) HWDT znajduje się na przedniej stronie PCB.

4. Reset przy zaniku napięcia i odzyskiwanie po zakłóceniach zasilania

Reset przy zaniku napięcia (BOR) to mechanizm inny niż watchdog. BOR jest wyzwalany, gdy napięcie zasilania spadnie poniżej progu (zwykle 2,7 V) i resetuje MCU, aby zapobiec wykonywaniu kodu przy zbyt niskim napięciu. BOR jest zaimplementowany wewnątrz MCU w każdym SKU w katalogu.

Próg BOR jest ustawiony na 2,7 V dla B1, B2, F8, P2 oraz na 2,85 V dla K7, KF1, L5, Q6, Q8, T2, Y6. Wyższy próg w średnich i premium SKU to celowy wybór, ponieważ te SKU używają szyn cyfrowych 1,8 V, które zawodzą przy 2,7 V. Próg BOR musi być powyżej napięcia awarii szyny cyfrowej, aby zapobiec uszkodzeniu logiki cyfrowej.

Subtelny tryb awarii, który zaobserwowaliśmy w terenie, to „zakłócenie napięcia” spowodowane luźnym połączeniem USB-C. Gdy kabel się porusza, napięcie VBUS może spaść do 3,5 V na 50 ms, co jest powyżej progu BOR, ale poniżej napięcia roboczego wzmacniacza klasy D. Wzmacniacz generuje trzask, a MCU odbiera fałszywe przerwanie, które może wywołać hard fault. Rozwiązaniem jest kondensator bulk 22 µF na pinie VBUS USB-C oraz programowe odrzucanie drgań przerwania trzasku wzmacniacza. Oba dodaliśmy do firmware K7, KF1, Q6, Q8 w III kwartale 2024 r., a wskaźnik hard fault spadł o 78%.

5. Obsługa hard fault i dziennik przyczyny resetu

Gdy MCU wchodzi w hard fault, procedura obsługi hard fault wykonuje sekwencję kroków, zanim WWDT zresetuje MCU. Kroki to: (1) zapisanie przyczyny resetu do dziennika flash, (2) zapisanie rejestrów PC i LR powodujących błąd do dziennika flash, (3) przełączenie GPIO HWDT w celu zasygnalizowania błędu, (4) wejście w nieskończoną pętlę, aby WWDT zresetował MCU.

Dziennik przyczyny resetu jest przechowywany w dedykowanym 4 KB sektorze flash, który jest zachowywany pomiędzy resetami. Dziennik może pomieścić do 64 zdarzeń resetu przed nadpisaniem. Dziennik jest eksportowany przez USB do diagnostyki terenowej. Intensywnie korzystamy z tego dziennika w naszym debugowaniu terenowym: gdy klient zgłasza zawieszenie, prosimy o dziennik przyczyny resetu, który informuje nas o typie hard fault (pusty wskaźnik, dzielenie przez zero, niezdefiniowana instrukcja itp.) oraz o problematycznym PC.

Sama procedura obsługi hard fault jest potencjalnym trybem awarii. Wyżej wymieniony brazylijski problem z T2 polegał na procedurze obsługi hard fault, która dereferencjonowała pusty wskaźnik, co uniemożliwiło obsługę WWDT. Naprawiliśmy to, przenosząc kod zapisu do flash procedury obsługi hard fault do oddzielnej funkcji, która jest zweryfikowana jako bezpieczna pod względem wskaźników, oraz dodając przerwanie timera sprzętowego, które przełącza GPIO HWDT niezależnie od stanu pętli głównej. Przerwanie timera sprzętowego odpala się co 800 ms i jest przerwaniem o najwyższym priorytecie w systemie.

Wskazówka dla kupującego: Podczas audytu dostawcy piór do czytania poproś o format dziennika przyczyny resetu oraz kod źródłowy procedury obsługi hard fault. Dostawca, który nie pomyślał o bezpieczeństwie wskaźników w procedurze obsługi hard fault, to dostawca, który nie widział wystarczająco dużo awarii terenowych, aby się z nich uczyć.

6. Cold start vs warm start vs POR

W katalogu istnieją trzy typy resetu: cold start (reset po włączeniu zasilania po pełnym cyklu zasilania), warm start (reset z WWDT lub HWDT po zawieszeniu) oraz POR (reset po włączeniu zasilania po zaniku napięcia). Każdy typ resetu ma inną sekwencję startową.

Cold start inicjalizuje PMIC, RTC, czujnik OID i radio BLE. Zajmuje 1,8 sekundy. Warm start pomija inicjalizację RTC (ponieważ stan RTC jest zachowany) i zajmuje 1,1 sekundy. POR inicjalizuje wszystko, w tym RTC, i zajmuje 2,4 sekundy.

Zachowanie wskaźnika LED różni się w zależności od typu resetu. Cold start pokazuje zieloną diodę LED przez 2 sekundy, a następnie gaśnie. Warm start pokazuje żółtą diodę LED przez 1 sekundę, a następnie gaśnie. POR pokazuje czerwoną diodę LED przez 3 sekundy, a następnie gaśnie, wskazując zdarzenie zaniku napięcia.

Dziennik przyczyny resetu zapisuje typ resetu obok wartości PC i LR. Typ resetu jest zapisywany do dziennika jako 2-bitowe pole: 00 = cold start, 01 = warm start, 10 = POR, 11 = zarezerwowane.

7. Dziennik przyczyny resetu i diagnostyka terenowa

Dziennik przyczyny resetu jest jednym z naszych najbardziej użytecznych narzędzi diagnostyki terenowej. Wykorzystaliśmy go do zdiagnozowania 18 odrębnych trybów awarii terenowych w 2025 r., w tym:

• Hard fault w rozpoznawaniu OID (brazylijski problem z T2)
• Zanik napięcia podczas impulsu wzmacniacza klasy D (rozwiązanie z kondensatorem bulk 22 µF)
• Hard fault w ponownym połączeniu BLE (problem z Q6 w Zatoce Perskiej)
• Hard fault w ponownej inicjalizacji kodeka audio (egipski problem z K7)
• Zanik napięcia podczas negocjacji kontraktu USB PD (saudyjski problem z L5)

Każdy z tych trybów awarii został zdiagnozowany w mniej niż 48 godzin przy użyciu dziennika przyczyny resetu. Alternatywą byłby 4–6-tygodniowy cykl hipotez, poprawek i ponownych wdrożeń.

Dziennik przyczyny resetu jest eksportowany przez USB za pomocą polecenia specyficznego dla dostawcy. Eksport trwa 1,2 sekundy i generuje 4 KB plik binarny, który nasze narzędzie diagnostyczne parsuje do formatu czytelnego dla człowieka. Udostępniamy narzędzie eksportowe kupującym OEM, którzy chcą prowadzić własną diagnostykę terenową.

8. Pokrycie testami watchdoga w kontroli jakości

Każda partia produkcyjna K7, KF1, L5, Q6, Q8, T2 i Y6 przechodzi przed wysyłką test watchdoga na 12 sztukach. Test wymusza hard fault poprzez zapisanie nieprawidłowej wartości PC do firmware i weryfikuje, że HWDT resetuje pióro w ciągu 2 sekund. Test wymusza również zanik napięcia poprzez zwarcie szyny VDD do masy na 50 ms i weryfikuje, że BOR resetuje pióro, a dziennik przyczyny resetu rejestruje zdarzenie POR.

W 2025 r. wstrzymaliśmy 2 partie ze 168 z powodu awarii testów watchdoga. Obie awarie zostały powiązane ze złą partią układów nadzorczych HWDT od dostawcy Tier-2. Dostawca zmienił rewizję krzemu układu bez powiadomienia, a nowa rewizja miała próg zaniku napięcia 2,6 V zamiast 2,85 V. Odrzuciliśmy obie partie i wróciliśmy do kwalifikowanego dostawcy Tier-1 przy następnym cyklu produkcyjnym.

9. Przestoje spowodowane watchdogiem i doświadczenie użytkownika

Reset watchdoga jest niewidoczny dla użytkownika, jeśli nastąpi w trybie półki lub podczas odtwarzania audio. Reset trwa 1,1 sekundy, a użytkownik postrzega go jako krótką pauzę. Jeśli reset nastąpi podczas aktywnego transferu plików BLE, transfer kończy się niepowodzeniem i host musi ponowić próbę. Jeśli reset nastąpi podczas skanowania OID, wynik skanowania jest utracony i użytkownik musi powtórzyć skan.

Widoczny dla użytkownika wskaźnik resetu watchdoga w średnich i premium SKU wynosi 0,04% na aktywną sesję, co przekłada się na około jeden reset na 2500 skanów. W SKU ekonomicznych wskaźnik wynosi 0,7% na aktywną sesję, czyli jeden reset na 143 skanowania. 17-krotna różnica to korzyść podwójnego watchdoga na poziomie doświadczenia użytkownika.

Dla kupujących OEM wdrażających pióra w demonstracjach detalicznych widoczny dla użytkownika wskaźnik resetu jest krytyczną metryką. Demonstracja detaliczna, która resetuje się raz na 143 skanowania, nie jest komercyjnie opłacalna. Zalecamy SKU z podwójnym watchdogiem (K7, KF1, L5, Q6, Q8, T2, Y6) dla każdego wdrożenia detalicznego.

10. 12-miesięczna mapa drogowa dla technologii watchdoga i resetu

Śledzimy trzy usprawnienia mechanizmu watchdog, które trafią do katalogu do IV kwartału 2026 r. Po pierwsze, sprzętowy timer watchdog z limitem czasu 200 ms (zamiast 1,6 s) w przyszłym modelu premium, który wykryje szybsze tryby zawieszenia. Po drugie, dwurdzeniowa architektura MCU w przyszłym modelu premium, w której jeden rdzeń obsługuje zadania użytkownika, a drugi zajmuje się zadaniami housekeepingowymi; rdzeń housekeepingowy obsługuje WWDT i może zresetować rdzeń użytkownika w razie błędu. Po trzecie, chmurowy log resetów watchdog, który przesyła log przyczyn resetu na serwer chmurowy przy następnym połączeniu BLE, umożliwiając zdalną diagnostykę bez interwencji użytkownika.

Opublikujemy raport uzupełniający po wdrożeniu HWDT 200 ms w testach terenowych. W międzyczasie architektura watchdog w całym naszym katalogu jest dojrzała, dobrze zwalidowana i solidnie wspierana, a każdego kupującego OEM ze specjalnymi wymaganiami dotyczącymi niezawodności zapraszamy do kontaktu z naszym zespołem ODM reading pens w celu przeglądu wykonalności.

Powiązane lektury

• Architektura firmware pióra czytającego — wyjaśniona
• Mechanizm aktualizacji OTA firmware pióra czytającego
• Bootloader i odzyskiwanie firmware pióra czytającego
• RTC pióra czytającego — zegar czasu rzeczywistego i podtrzymywanie czasu
• PMIC pióra czytającego — układ zarządzania zasilaniem
• Zarządzanie zasilaniem i optymalizacja czasu pracy pióra czytającego
• Playbook rozwiązywania problemów z piórem czytającym
• Kontrola jakości i normy AQL pióra czytającego