Grovy311/VersaMCU
1
0
Fork 0
forked from jappel/VersaMCU
Code Pull requests Activity

Fix bootloader hardware bring-up and add key-based boot entry

Browse source 
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>
This commit is contained in:
Julian Appel 2026-08-05 21:28:15 +02:00
parent 4749adcd1d
commit f60a29137c
8 changed files with 234 additions and 82 deletions
Download patch file Download diff file Expand all files Collapse all files

20
doc/09_known_limitations.md
View file

@ -6,9 +6,23 @@ Robustheitskorrekturen. Sie ist keine Liste bereits umgesetzter Features.
## Bootloader-Ziel bleibt nicht unterstützt
Das aktive Ziel `versapad_nobl` reserviert den kompletten Bereich
`0x1FB00..0x1FFFF` für Makros und Config. Das auskommentierte
USB-Bootloader-Environment verwendet dagegen weiterhin eine historische
Board-/Linker-Konfiguration und ist nicht als Produktionsziel verifiziert.
`0x1FB00..0x1FFFF` für Makros und Config.
Ein USB-Bootloader-Pfad wird im Branch `feature/usb-bootloader` aufgebaut
(`bootloader/`, App-Environment `env:versapad_usb`). Der Bootloader selbst
(UF2, `bootloader/`) ist dort auf echter Hardware verifiziert — inklusive
eines gefundenen und behobenen Bugs beim Sprung in die App (fehlende
`__DSB()`/`__ISB()` vor dem `bx`, siehe `bootloader/README.md`,
"Hardwaretest"). `env:versapad_usb`s Linkerskript
(`variants/versapad/linker_scripts/gcc/flash_with_bootloader.ld`) reserviert
inzwischen denselben NVM-Bereich wie `flash_without_bootloader.ld`.
Trotzdem noch kein Produktionsziel: `env:versapad_usb` verwendet
`upload_protocol = sam-ba`, das klassische Arduino/Atmel-SAM-BA-Protokoll —
das spricht der UF2-Bootloader nicht. Die App-Firmware erzeugt außerdem noch
keine `.uf2`-Datei. Vor einem Merge nach `master` fehlen also noch die
`.uf2`-Erzeugung und ein Ende-zu-Ende-Test des tatsächlichen USB-Flashwegs
(Datei aufs `VERSABOOT`-Laufwerk kopieren).
Die aktive Boarddatei benennt die MCU als `samd21g17d`, setzt für den
Arduino-Core aber weiterhin das Kompatibilitätsmakro `__SAMD21G18A__`. Der