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>

bootloader/TESTING.md

@@ -1,67 +1,65 @@
-# Bootloader-Testflash -- Anleitung für Hardware-Zugriff
+# Bootloader-Testflash -- Ergebnis
 
-Der UF2-Bootloader (siehe [README.md](README.md)) ist fertig gebaut, aber noch
-nie auf echter Hardware gelaufen. Diese Anleitung ist für jemanden mit
-Atmel-ICE-Zugriff aufs VersaPad-v2-Board, um das einmal zu testen.
+Der UF2-Bootloader (siehe [README.md](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](README.md#hardwaretest-2026-08-05).
+Dieses Dokument hält den Testablauf und die Antworten auf die ursprünglichen
+Prüffragen fest.
 
-**Wichtig zur Sicherheit:** Dieser Flash schreibt nur `0x0000..0x1FFF`
-(8 KiB). Die App-Firmware liegt ab `0x2000` und bleibt unangetastet. Falls
-etwas schiefgeht, ist das jederzeit per SWD neu beschreibbar, das Board kann
-dabei nicht dauerhaft "gebrickt" werden, solange der Atmel-ICE-Zugriff
-funktioniert.
+**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, genau wie beim normalen
-  App-Firmware-Flashen (`pio run -e versapad --target upload` in
-  `doc/08_development.md`)
-- PlatformIO Core installiert. Falls nicht:
-  ```bash
-  pip install -U platformio
+- 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](README.md#hardware-bootloader-einstieg-ohne-reset-taster).
+  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](README.md#hardwaretest-2026-08-05) 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).
 
-## 1. Repo auf diesem Branch auschecken
+## Noch NICHT getestet
 
-```bash
-git clone https://git.jappel.io/jappel/VersaMCU.git
-cd VersaMCU
-git checkout feature/usb-bootloader
-```
-
-## 2. Bootloader bauen und flashen
-
-```bash
-cd bootloader
-pio run -e versapad_bootloader --target upload
-```
-
-Der erste Aufruf lädt automatisch den ARM-Toolchain und OpenOCD herunter
-(einmalig, braucht Internet). Der Build sollte ohne Fehler durchlaufen
-(erwartete Größe: ~7,3 von 8 KB Flash).
-
-## 3. Prüfen, ob der Bootloader läuft
-
-Nach dem Flash: Board kurz vom USB trennen und wieder anstecken, dann
-**Reset-Taste zweimal kurz hintereinander drücken** (Doppel-Tap, wie bei
-Arduino-Zero-artigen Boards üblich).
-
-Erwartung: Das Board sollte sich als **USB-Massenspeicher-Laufwerk namens
-`VERSABOOT`** melden (in Windows z. B. im Explorer als neues Laufwerk).
-
-## 4. Ergebnis zurückmelden
-
-Bitte notieren und zurückgeben:
-
-- Ist der Flash-Befehl ohne Fehler durchgelaufen? (ggf. komplette
-  Fehlermeldung kopieren)
-- Erscheint nach dem Doppel-Tap-Reset ein Laufwerk `VERSABOOT`?
-- Falls ja: was steht in der Datei `INFO_UF2.TXT` auf dem Laufwerk?
-- Falls nein: reagiert das Board überhaupt noch normal als App-Firmware
-  (Tasten/LEDs), wenn man es normal per USB ansteckt ohne Doppel-Tap?
-- Alles, was ungewöhnlich aussieht (USB-Gerät mit falschem Namen, Windows
-  fragt nach Treiber, Laufwerk lässt sich nicht öffnen, etc.)
-
-Noch NICHT testen: Firmware tatsächlich über das `VERSABOOT`-Laufwerk
-flashen. Der Firmware-Build erzeugt noch keine `.uf2`-Datei (nur `.bin`
-für den bisherigen SWD-Weg), das ist der nächste Schritt, nachdem der
-Bootloader selbst bestätigt läuft.
+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".