Les outils du banc
Trois fils sur le connecteur SWD, et le PC voit l’intérieur du RP2040 en marche. Presque tous les outils du projet passent par là, jusqu’à taper au clavier ou copier des fichiers sur la clé.
Dans cette page
La sonde
Le banc utilise une sonde CMSIS-DAP branchée sur le connecteur SWD1 de la carte : une
Raspberry Pi Debugprobe par l’USB, ou, depuis la v0.59, Eliott65Sonde, une sonde sans fil
écrite par le projet, qui passe par le Wi-Fi ; elle a son propre
wiki. Une seule variable, E65_SONDE, fait passer tous les
outils par elle ; avec le câblage actuel, on flashe à 200 kHz (E65_SWD_KHZ=200). Le SWD est le port de débogage des processeurs ARM : il permet de lire et
d’écrire la mémoire du RP2040, et de contrôler ses deux cœurs, pendant que le firmware tourne.
Le logiciel côté PC est OpenOCD, dans sa version de développement : la version 0.12.0 des distributions ne reconnaît pas la flash Puya de la carte.
Flasher sans se faire écraser
Un jour, le flashage s’est mis à échouer (« double fault », « failed to exit flash XIP mode »). La
cause était savoureuse : OpenOCD exécute son programme d’écriture de flash en RAM, par défaut à
l’adresse 0x20010000… qui est la mémoire de la 6502. Le bus DMA continuant à tourner, la 6502
incrémentait un compteur en page zéro et écrasait le programme d’OpenOCD.
Le script de flashage place désormais cette zone de travail ailleurs, dans de la RAM inutilisée, et échoue bruyamment si la vérification ne passe pas.
Les outils principaux
| Outil | Ce qu’il fait |
|---|---|
flasher.sh | flashe le firmware par SWD, en vérifiant |
sonde.py | lit l’état du noyau, la mémoire de la 6502 et mesure sa fréquence |
verifier_carte.py, run_tests.sh --carte | test d’acceptation complet sur la carte |
ecran.py | reconstruit l’image attendue et décode les tampons vidéo réellement émis |
usb.py | affiche le journal du pilote USB et l’état du clavier |
appel.py | fait des appels système depuis le PC |
copier_sur_cle.py, verifier_cle.py | copie des fichiers sur la clé, puis vérifie, sans la retirer |
taper.py, touches.py | tapent au clavier de la 6502, touches de contrôle comprises |
redemarrer_carte.sh | redémarre la carte par le chien de garde |
Appeler le noyau depuis le PC
appel.py utilise la propriété la plus utile de la 6502 de la carte : on peut la geler. L’outil
arrête la machine PIO du bus (la 6502, cœur statique, attend sans broncher), dépose un bloc de
paramètres, déclenche la porte, attend le noyau, puis restaure tout et relance la 6502. Elle ne
s’aperçoit de rien.
C’est ainsi qu’ont été faits les premiers essais d’écriture sur la clé, avant même qu’un programme 6502 sache écrire un fichier.
Copier sur la clé sans la débrancher
À la demande de l’utilisateur, les programmes sont copiés sur la clé par la sonde, sans la retirer de la carte. L’outil gèle la 6502, passe par les appels STOCKAGE du noyau, et utilise un écrivain FAT prudent : il sauvegarde chaque bloc avant de le modifier, refuse les doublons, met à jour les deux copies de la FAT et relit chaque bloc écrit. Une passe « à blanc », en lecture seule, précède toujours la copie réelle.
Pour que tout cela soit rapide, une session OpenOCD persistante est pilotée par son port de commande : une opération prend quelques millisecondes au lieu d’environ une demi-seconde.
Taper au clavier sans toucher la carte
taper.py dépose des caractères comme le ferait un vrai clavier. Pour les touches de contrôle
(flèches, Échap, et les raccourcis du noyau comme Ctrl+Tab),
touches.py va un cran plus bas : il dépose un rapport HID complet dans une boîte aux lettres du
firmware, traité exactement comme un rapport du vrai clavier. L’idée vient du projet Trinity, qui
pilote son clavier de la même façon.
Les pièges de la sonde
- Un redémarrage par le chien de garde ne faisait rien sans un registre que le SDK écrit avant de le déclencher : des « redémarrages » précédents avaient en fait été faits par le flashage.
- Quand OpenOCD laisse un cœur arrêté, le temporisateur du RP2040 se met en pause, et les attentes du noyau ne finissent plus. Le firmware désactive cette pause.
- La liaison SWD s’est montrée instable à plusieurs reprises (« Failed to connect multidrop ») ; il a parfois fallu une intervention sur la carte. Règle adoptée : vérifier la liaison par plusieurs lectures avant d’écrire sur la clé, et réessayer une lecture isolée qui échoue.