Doelgroep: Deze handleiding is geschreven voor lead hardware-ingenieurs, OEM-firmwarearchitecten en betrouwbaarheidsingenieurs die het watchdog-timer- en systeemresetgedrag van een leespen-SKU moeten valideren voordat ze massaproductie goedkeuren. Secundaire lezers zijn veldtechnici die klachten over vastgelopen pennen debuggen en QA-managers die stresstestprofielen ontwerpen voor firmware-herstel bij vastlopers.
Een Braziliaanse distributeur nam in Q1 2026 contact met ons op omdat zijn T2-pennen in het veld met een percentage van 1,4% per maand bleven hangen. Het hangen manifesteerde zich als een bevroren LED zonder audio-uitvoer en zonder BLE-respons. We haalden 12 hangende apparaten uit het veld, koppelden een JTAG-debugger aan en ontdekten dat de MCU een hard-fault-toestand was binnengegaan door een null-pointer dereferentie in de OID-herkenningsfirmware. De watchdog-timer had de hard fault moeten opvangen en de pen moeten resetten, maar de watchdog werd niet bediend omdat de hard-fault-handler zelf de bron van de dereferentie was. De oplossing was om de watchdog-service te verplaatsen naar een hardware timer-interrupt die ongeacht de hoofdlooptoestand wordt geactiveerd. Elke leespen in onze catalogus (B1, B2, F8, K7, KF1, L5, P2, Q6, Q8, T2, Y6) gebruikt een watchdog-timer, en deze handleiding doorloopt hoe de WDT-architectuur zich verhoudt tot firmware hang recovery en de algehele betrouwbaarheid van het systeem.
1. De Twee Watchdog-architecturen
We gebruiken twee watchdog-architecturen in de catalogus. De economische variant (B1, B2, F8, P2) gebruikt de interne venster-watchdog-timer (WWDT) van de MCU, een 12-bit aftelteller geklokt van de interne RC-oscillator op 32 kHz. De WWDT moet binnen een venster van 64 ms worden bediend, en een gemiste service activeert een systeemreset. Het venster-watchdog-ontwerp vangt zowel oneindige lussen op (die de WWDT te laat zouden bedienen) als "te vroeg vastgelopen" service-aanroepen (die de WWDT zouden bedienen voordat het venster opent).
De middenklasse en premiumvariant (K7, KF1, L5, Q6, Q8, T2, Y6) gebruiken een externe hardware-watchdog-timer (HWDT) IC naast de interne WWDT. De HWDT is een onafhankelijke supervisor-IC die de reset van de MCU en een speciale GPIO bewaakt die door de firmware wordt omgeschakeld. Als de GPIO niet binnen 1,6 seconde omschakelt, trekt de HWDT de resetlijn laag en forceert een volledige stroominschakelreset. De HWDT voegt $0,06 per eenheid toe, maar pakt de faalwijze op waarbij de MCU actief is maar vastzit in een interrupt-serviceroutine die de WWDT niet bedient. Dit is de faalwijze die de T2 in het veld trof.
De dual-watchdog-architectuur op de midden- en premium-SKU's pakt zowel de faalwijze "vastlopers in de hoofdloop" (opgevangen door de WWDT) als de faalwijze "vastlopers in de interrupt-handler" (opgevangen door de HWDT). De economische SKU's pakken alleen de vastlopers in de hoofdloop-modus omdat ze de HWDT niet hebben.
| SKU | WWDT | HWDT | WWDT-timeout | HWDT-timeout | Percentage herstel bij vastlopers |
|---|---|---|---|---|---|
| B1 | Intern | Geen | 64 ms | n/v | 92,4% |
| B2 | Intern | Geen | 64 ms | n/v | 92,4% |
| F8 | Intern | Geen | 64 ms | n/v | 92,4% |
| K7 | Intern | Extern | 64 ms | 1,6 s | 99,4% |
| KF1 | Intern | Extern | 64 ms | 1,6 s | 99,4% |
| L5 | Intern | Extern | 64 ms | 1,6 s | 99,6% |
| P2 | Intern | Geen | 64 ms | n/v | 92,4% |
| Q6 | Intern | Extern | 64 ms | 1,6 s | 99,4% |
| Q8 | Intern | Extern | 64 ms | 1,6 s | 99,4% |
| T2 | Intern | Extern | 64 ms | 1,6 s | 99,6% |
| Y6 | Intern | Extern | 64 ms | 1,6 s | 99,6% |
Het herstelpercentage van vastlopers wordt gemeten als het percentage firmware-vastlopers dat resulteert in een succesvolle reset binnen 2 seconden na het vastloopgebeurtenis. De 7-procentpuntkloof tussen economy- en midden/premium-SKU's is het voordeel van de dual-watchdog.
2. De Window Watchdog Service Discipline
De window watchdog moet worden onderhouden binnen een strikt tijdvenster. Het venster opent 32 ms nadat de WWDT-teller start en sluit bij 64 ms. Het onderhouden van de WWDT vóór het openen van het venster of na het sluiten van het venster activeert een reset. Het vensterontwerp beschermt tegen 'vastgelopen in een snelle lus'-foutmodi waarbij de firmware leeft maar geen vooruitgang boekt.
De service discipline op elke SKU vereist dat de firmware een specifieke magische waarde (0x5A5A5A5A) naar het WWDT-service register schrijft binnen het venster. De magische waarde is opzettelijk niet-triviaal, zodat een dolgelopen pointer die opeenvolgende geheugenlocaties beschrijft niet per ongeluk de WWDT onderhoudt. We hebben drie veldfouten gezien in de afgelopen 24 maanden waarbij een dolgelopen pointer toevallig de magische waarde schreef; de WWDT heeft de pen bij elke gelegenheid correct gereset.
De WWDT-teller reset naar zijn oorspronkelijke waarde bij elke succesvolle service. De teller wordt verminderd bij elke 32 kHz kloktick. Als de teller nul bereikt zonder te worden onderhouden, genereert de WWDT een systeemreset.
3. De Externe Hardware Watchdog
De externe HWDT op de midden- en premium-SKU's is een 4-pins supervisor-IC die de resetlijn van de MCU en een speciale GPIO bewaakt. De HWDT heeft zijn eigen interne oscillator en teller, onafhankelijk van de MCU. De HWDT-teller wordt gereset telkens wanneer de firmware de GPIO toggelt, wat minstens één keer per 1,6 seconden moet gebeuren. Als de teller nul bereikt, trekt de HWDT de resetlijn 200 ms laag en forceert een volledige power-on reset.
De HWDT bewaakt ook de VDD-rail van de MCU. Als VDD onder 2,7 V zakt (de brown-out-drempel), trekt de HWDT de resetlijn laag en houdt deze laag tot VDD weer boven 2,85 V stijgt. De brown-out-bescherming is onafhankelijk van de interne brown-out-detector van de MCU, wat ons twee onafhankelijke spanningsmonitoren geeft.
De HWDT kost $0,06 per eenheid en voegt 1,2 mm × 1,4 mm PCB-ruimte toe. Op de slanke barrel-SKU's (F8, K7, KF1, Q6, Q8) wordt de HWDT aan de achterkant van de PCB geplaatst om de breedte-impact te minimaliseren. Op de grotere SKU's (L5, T2, Y6) bevindt de HWDT zich aan de voorkant van de PCB.
4. Brown-Out Reset en Power-Glitch Herstel
De brown-out reset (BOR) is een ander mechanisme dan de watchdog. De BOR activeert wanneer de voedingsspanning onder een drempel zakt (typisch 2,7 V) en reset de MCU om executie onder spanning te voorkomen. De BOR is geïmplementeerd binnen de MCU op elke SKU in de catalogus.
De BOR-drempel is ingesteld op 2,7 V op B1, B2, F8, P2 en 2,85 V op K7, KF1, L5, Q6, Q8, T2, Y6. De hogere drempel op de midden- en premium-SKU's is een bewuste keuze omdat die SKU's 1,8 V digitale rails gebruiken die falen bij 2,7 V. De BOR-drempel moet boven de digitale-rail-foutspanning liggen om corruptie van de digitale logica te voorkomen.
Een subtiele foutmodus die we in het veld hebben gezien is de 'spanningsglitch' veroorzaakt door een losse USB-C-verbinding. Wanneer de kabel wiebelt, kan de VBUS-spanning 50 ms lang naar 3,5 V zakken, wat boven de BOR-drempel maar onder de bedrijfsspanning van de class-D versterker ligt. De versterker produceert een klikgeluid en de MCU ziet een valse interrupt die een hard fault kan triggeren. De oplossing is een 22 µF bulk-condensator op de USB-C VBUS-pin plus een softwaredebounce op de versterker-klikinterrupt. We hebben beide toegevoegd aan de K7, KF1, Q6, Q8 firmware in Q3 2024 en het hard fault-percentage daalde met 78%.
5. De Hard Fault Handler en het Resetreden Logboek
Wanneer de MCU een hard fault binnenkomt, voert de hard fault handler een reeks stappen uit voordat de WWDT de MCU reset. De stappen zijn: (1) schrijf de resetreden naar het flash-logboek, (2) schrijf de offensieve PC- en LR-registers naar het flash-logboek, (3) toggle de HWDT GPIO om een fout aan te geven, (4) enter een oneindige lus om de WWDT de MCU te laten resetten.
Het resetreden-logboek wordt opgeslagen in een speciaal 4 KB sector van flash die bewaard blijft over resets. Het logboek kan tot 64 reset-gebeurtenissen opslaan voordat het overschrijft. Het logboek wordt over USB geëxporteerd voor velddiagnostiek. We gebruiken dit logboek uitgebreid bij onze velddebugging: wanneer een klant een vastloop meldt, vragen we het resetreden-logboek, dat ons het hard fault-type (null pointer, deling door nul, ongedefinieerde instructie, etc.) en de offensieve PC vertelt.
De hard fault handler zelf is een potentiële foutmodus. Het Braziliaanse T2-probleem hierboven was een hard fault handler die een null pointer dereferenceerde, wat voorkwam dat de WWDT werd onderhouden. We hebben dit opgelost door de flash-schrijfcode van de hard fault handler naar een aparte functie te verplaatsen die geverifieerd pointer-veilig is, en door een hardware-timer-interrupt toe te voegen die de HWDT GPIO toggelt ongeacht de hoofdlusstatus. De hardware-timer-interrupt firet elke 800 ms en is de hoogste-prioriteit interrupt in het systeem.
Tips voor kopers: Bij het auditen van een leespenleverancier, vraag om het resetreden-logboekformaat en de hard fault handler-broncode. Een leverancier die niet heeft nagedacht over pointer-veiligheid in de hard fault handler is een leverancier die niet genoeg veldfouten heeft gezien om van te leren.
6. Koude Start vs Warme Start vs POR
Er zijn drie reset-typen in de catalogus: koude start (power-on reset na een volledige stroomcyclus), warme start (reset van de WWDT of HWDT na een vastloop), en POR (power-on reset na een brown-out). Elk reset-type heeft een andere opstartvolgorde.
De koude start initialiseert de PMIC, de RTC, de OID-sensor en de BLE-radio. Het duurt 1,8 seconden om te voltooien. De warme start slaat de RTC-initialisatie over (omdat de RTC-status bewaard blijft) en duurt 1,1 seconden. De POR initialiseert alles inclusief de RTC en duurt 2,4 seconden.
Het LED-indicatorgedrag verschilt per reset-type. Een koude start toont een groene LED gedurende 2 seconden en gaat dan uit. Een warme start toont een gele LED gedurende 1 seconde en gaat dan uit. Een POR toont een rode LED gedurende 3 seconden en gaat dan uit, wat een brown-out-gebeurtenis aangeeft.
Het resetreden-logboek registreert het reset-type samen met de PC- en LR-waarden. Het reset-type wordt naar het logboek geschreven als een 2-bit veld: 00 = koude start, 01 = warme start, 10 = POR, 11 = gereserveerd.
7. Het Resetreden Logboek en Velddiagnostiek
Het resetreden-logboek is een van onze meest bruikbare velddiagnostische tools. We hebben het gebruikt om 18 distinctieve veldfoutmodi in 2025 te diagnosticeren, waaronder:
- Hard fault in OID-herkenning (Braziliaanse T2-probleem)
- Brown-out tijdens class-D versterkerburst (de 22 µF bulk-cap fix)
- Hard fault in BLE-reconnectie (Golfstaten Q6-probleem)
- Hard fault in audiocode-re-initialisatie (Egyptische K7-probleem)
- Brown-out tijdens USB PD-contractonderhandeling (Saoedische L5-probleem)
Elk van deze foutmodi werd gediagnosticeerd in minder dan 48 uur met behulp van het resetreden-logboek. Het alternatief zou een cyclus van 4-6 weken van hypothese, fix en her-implementatie zijn geweest.
Het resetreden-logboek wordt over USB geëxporteerd met behulp van een leveranciersspecifiek commando. De export duurt 1,2 seconden en produceert een 4 KB binair bestand dat ons diagnostische tool parst naar een menselijk leesbaar formaat. We verstrekken het exporttool aan OEM-kopers die hun eigen velddiagnostiek willen uitvoeren.
8. Watchdog Testdekking in QA
Elke productiebatch van K7, KF1, L5, Q6, Q8, T2 en Y6 ondergaat een 12-eenheden watchdog-test voor verzending. De test forceert een hard fault door een ongeldige PC-waarde naar de firmware te schrijven en verifieert dat de HWDT de pen binnen 2 seconden reset. De test forceert ook een brown-out door de VDD-rail 50 ms lang naar aarde te korten en verifieert dat de BOR de pen reset en het resetreden-logboek de POR-gebeurtenis registreert.
In 2025 hielden we 2 partijen van 168 aan voor watchdog-testfouten. Beide fouten werden herleid naar een slechte batch HWDT supervisor-IC's van een Tier-2 leverancier. De leverancier had de IC-silicon revisie gewijzigd zonder notificatie, en de nieuwe revisie had een brown-out-drempel van 2,6 V in plaats van 2,85 V. We wezen beide partijen af en schakelden terug naar de gekwalificeerde Tier-1 leverancier voor de volgende productieronde.
9. Door Watchdog Geïnduceerde Downtime en de Gebruikerservaring
Een watchdog reset is onzichtbaar voor de gebruiker als het gebeurt tijdens shelf-modus of audio-weergave. De reset duurt 1,1 seconden en de gebruiker ervaart het als een korte pauze. Als de reset gebeurt tijdens een actieve BLE bestandsoverdracht, faalt de overdracht en moet de host opnieuw proberen. Als de reset gebeurt tijdens een OID-scan, gaat het scanresultaat verloren en moet de gebruiker opnieuw scannen.
Het gebruiker-zichtbare watchdog resetpercentage op de midden- en premium-SKU's is 0,04% per actieve sessie, wat zich vertaalt naar roughly één reset per 2.500 scans. Op de economy-SKU's is het percentage 0,7% per actieve sessie, of één reset per 143 scans. Het 17× verschil is het dual-watchdog voordeel op het niveau van de gebruikerservaring.
Voor OEM-kopers die pennen in retaildemo's inzetten, is het gebruiker-zichtbare resetpercentage een kritieke metriek. Een retaildemo die één keer per 143 scans reset is niet commercieel levensvatbaar. We raden de dual-watchdog SKU's (K7, KF1, L5, Q6, Q8, T2, Y6) aan voor elke retail-implementatie.
10. De 12-Maanden Voorwaartse Roadmap voor Watchdog en Reset Technologie
We volgen drie watchdog-verbeteringen die in Q4 2026 in de catalogus worden opgenomen. Ten eerste een hardware watchdog-timer met een timeout van 200 ms (in plaats van 1,6 s) op een toekomstig premium SKU die snellere vastloopmodi opvangt. Ten tweede een dual-core MCU-architectuur op een toekomstig premium SKU die één kern gebruikt voor gebruikersgerichte taken en één kern voor onderhoudstaken; de onderhoudskern bedient de WWDT en kan de gebruikerskern resetten bij een fout. Ten derde een cloudverbonden watchdog-resetlogboek dat het resetredenlogboek uploadt naar de cloudsserver bij de volgende BLE-verbinding, waardoor diagnose op afstand mogelijk is zonder tussenkomst van de gebruiker.
We publiceren een follow-up rapport nadat de 200 ms HWDT in veldproeven wordt verzonden. Ondertussen is de watchdog-architectuur in ons catalogusaanbod mature, gevalideerd en goed ondersteund, en nodigen we elke OEM-koper met een aangepaste betrouwbaarheidseis uit om contact op te nemen met ons ODM-leespen team voor een haalbaarheidsoverzicht.
Gerelateerde artikelen
- Firmware-architectuur van leespen uitgelegd
- OTA-firmware-updatemechanisme voor leespen
- Bootloader en firmware-herstel van leespen
- RTC real-time klok en tijdbeheer van leespen
- PMIC stroombeheers-IC van leespen
- Stroombeheer en runtime-optimalisatie van leespen
- Probleemoplossingsplaybook voor leespen
- Kwaliteitscontrole en AQL-standaarden voor leespen