VersaMCU/bootloader/TESTING.md
Julian Appel f60a29137c Fix bootloader hardware bring-up and add key-based boot entry
Hardware-tested the UF2 bootloader end to end on a real VersaPad v2
board. Found and fixed a real bug: the bootloader's jump into the app
(__set_MSP -> SCB->VTOR -> bx) hard-faulted on every standalone boot,
even with the debugger fully disconnected; identical register/VTOR
values injected directly by a halted debugger ran fine, which pointed
at the missing __DSB()/__ISB() barriers ARM's own guidance requires
for this exact pattern. Also fixed a USB PID collision (0x0011 is
Adafruit's own Gemma M0 bootloader PID, misidentified by Windows as a
Circuit Playground COM port instead of exposing VERSABOOT).

This board has no dedicated reset/boot button, so add a hardware boot
entry that doesn't need one: holding the bottom-right Cherry MX key
(key_id 24) during reset/power-on drives its matrix row and reads its
column directly in the bootloader, before the app is even validated.

Also corrected the app-side flash_with_bootloader.ld (was missing the
NVM carve-out flash_without_bootloader.ld already has) and
boards/versapad.json (wrong flash/RAM size, wrong MCU macro, stale
PID), and enabled the previously-commented-out env:versapad_usb.

Documented findings in bootloader/README.md, bootloader/TESTING.md,
and doc/09_known_limitations.md.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-05 21:28:15 +02:00

2.9 KiB

Bootloader-Testflash -- Ergebnis

Der UF2-Bootloader (siehe README.md) wurde am 2026-08-05 auf einem echten VersaPad-v2-Board über Atmel-ICE/SWD getestet. Zusammenfassung der Ergebnisse steht im Hardwaretest-Abschnitt der README. Dieses Dokument hält den Testablauf und die Antworten auf die ursprünglichen Prüffragen fest.

Sicherheitsrahmen, der eingehalten wurde: Der Bootloader-Flash schreibt nur 0x0000..0x1FFF (8 KiB). Die App-Firmware ab 0x2000 blieb dabei unangetastet. Über SWD war der Chip jederzeit neu beschreibbar; ein Brick war zu keinem Zeitpunkt möglich, solange der Atmel-ICE-Zugriff funktionierte.

Voraussetzungen

  • Board per Atmel-ICE/SWD angeschlossen, wie beim normalen App-Firmware-Flashen (pio run -e versapad --target upload, siehe ../doc/08_development.md)
  • PlatformIO Core (hier: PlatformIO-IDE-penv unter %USERPROFILE%\.platformio\penv\Scripts\pio.exe)

Ablauf

  1. git checkout feature/usb-bootloader
  2. cd bootloader && pio run -e versapad_bootloader — Build sauber (89,9 % Flash, 7364/8192 Byte)
  3. pio run -e versapad_bootloader --target upload — Flash + Verify über Atmel-ICE/SWD

Ursprüngliche Prüffragen und Antworten

  • Ist der Flash-Befehl ohne Fehler durchgelaufen? Ja, ** Verified OK ** bei jedem Flash.
  • Erscheint nach dem Bootloader-Einstieg ein Laufwerk VERSABOOT? Ja. Getestete Board-Revision hat keinen physischen Reset-/Boot-Taster (Custom-PCB) — der ursprünglich geplante Doppel-Tap-Reset-Test war damit nicht durchführbar. Stattdessen wurde ein Hardware-Bootloader-Einstieg über eine gehaltene Cherry-MX-Taste ergänzt, siehe README.md. Mit dieser Ergänzung: gehaltene Taste beim Power-On → VERSABOOT.
  • Was steht in INFO_UF2.TXT?
    UF2 Bootloader versapad-1 SFHWRO
    Model: VersaPad v2
    Board-ID: SAMD21G17D-VersaPad-v2
    
  • Reagiert das Board normal als App-Firmware, wenn man es ohne gehaltene Taste ansteckt? Ja, nach dem in der README beschriebenen DSB/ISB-Fix. Vor dem Fix: nein, siehe unten.
  • Ungewöhnliches? Ja, ein echter Bug: siehe Hardwaretest-Abschnitt der README für die Fehlersuche (Bootloader-eigener Sprung faultete zuverlässig, obwohl vom Debugger injizierte identische Register-/VTOR-Werte einwandfrei liefen) und den Fix (fehlende __DSB()/__ISB() vor dem bx in check_start_application()).
  • USB-Identität korrekt, kein Fremdtreiber-Konflikt? Nach PID-Wechsel von 0x0011 auf 0x0043 ja (siehe README, "Bekannte Einschränkungen" zum ursprünglichen Adafruit-PID-Konflikt).

Noch NICHT getestet

Firmware tatsächlich über das VERSABOOT-Laufwerk flashen. Der Firmware-Build der App erzeugt noch keine .uf2-Datei (nur .bin/.elf für den SWD-Weg) — das ist der nächste Schritt, siehe README, "Bekannte Einschränkungen".