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>
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
git checkout feature/usb-bootloadercd bootloader && pio run -e versapad_bootloader— Build sauber (89,9 % Flash, 7364/8192 Byte)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 dembxincheck_start_application()). - USB-Identität korrekt, kein Fremdtreiber-Konflikt? Nach PID-Wechsel von
0x0011auf0x0043ja (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".