Aller au contenu
Eliott65Sondewiki
Sommaire

Les bancs de test

Avant d’aller sur la sonde, chaque pièce tourne sur le PC, face à un modèle de ce qu’elle trouvera en vrai. Ces bancs ont trouvé plusieurs défauts avant qu’ils n’atteignent le matériel.

Le principe

Tout ce qui ne dépend pas du Pico W est écrit en modules portables : processeur CMSIS-DAP, protocole SWD, journal, mise à jour, amorce. Ils se compilent aussi pour le PC, où ils tournent face à des modèles : une cible SWD, une flash, un serveur TCP. make test lance l’ensemble.

OpenOCD face à la cible simulée

Le serveur du PC présente la cible simulée (port de débogage du RP2040, deux cœurs, 64 Kio de RAM) comme une vraie sonde, sur les deux ports. Le vrai OpenOCD s’y connecte ; l’outil e65s.py aussi. Un scénario fait monter un compteur chaque milliseconde puis le fige, à l’image d’un programme 6502 qui s’arrête : de quoi essayer le déclencheur du journal.

Le programme PIO au simulateur

Le programme PIO du SWD est assemblé par l’outil officiel, puis exécuté dans le simulateur de PIO du projet Eliott65, face à une cible simulée bit à bit : elle lit SWDIO au front montant, mène la ligne pour ses réponses, et détecte la remise à zéro de la ligne.

  • Le scénario complet du processeur CMSIS-DAP y passe : remise à zéro, sélection des deux cœurs, identifiant, mise sous tension, écritures, lectures postées, bloc de 64 mots, attente, parité fausse, cible non sélectionnée.
  • Le banc vérifie que la sonde et la cible ne mènent jamais SWDIO en même temps, et, depuis les essais sur la carte, qu’aucun changement de SWDIO ne tombe sur un front d’horloge.
  • Un défaut trouvé au passage : faute de réponse de la cible, l’ancien code demandait plus de 32 bits d’un coup au programme PIO, qui n’en lit que 32.

La mise à jour et l’amorce

  • La mise à jour : 8 essais contre le serveur du PC (envoi, vérification, application, secteurs exacts, fichier UF2, CRC faux, vecteurs invalides, ordre des blocs et taille maximale, redémarrages, version), plus un test du réglage du chien de garde avant redémarrage.
  • L’amorce : 35 vérifications, dont 236 coupures de courant simulées, à chaque instant possible de l’installation (86), de la restauration (75) et de la préparation (75). Une coupure laisse le secteur en cours effacé, le pire cas, et plus rien ne s’écrit ensuite.
  • De bout en bout, avec une flash de 2 Mio et une amorce simulées : essai puis validation, image jamais validée et retour à l’ancienne au 4ᵉ démarrage, deux mises à jour de suite dont la seconde est rejetée, fichiers UF2 fusionnés, mauvaise adresse de base.

Sources dans le dépôt : README.md, docs/journal/01-cmsis-dap-tcp.md, docs/journal/02-firmware-pico-w.md, docs/journal/05-mise-a-jour-par-le-reseau.md, docs/journal/07-amorce.md.