Interface firmware reste en mode MAINTENANCE après update (PR #4 / config zone soupçonnée)

[nedseb]

Symptôme

Mattéo rapporte qu'après avoir mis à jour le firmware DAPLink (asset steami-daplink-firmware-v0.23.1.bin depuis la release micropython-steami-lib v0.23.1), la carte STeaMi reste en mode MAINTENANCE au lieu de booter l'interface firmware.

Côté @nedseb, le binaire compilé localement à partir d'une checkout antérieure de DAPLink fonctionne normalement sur sa carte.

Investigation faite (2026-05-12)

Comparaison binaires

Build	DAPLink commit	SHA256	Comportement
Standalone local @nedseb	270b2f1d (PR #1 only) + local mods	ae166c6e…	✅ fonctionne
.build/DAPLink (via make daplink-firmware)	0949b351 (PR #4 merged)	41f1dcd2… (raw) / e64b21a3… (crc)	❌ reste MAINTENANCE
Asset release v0.23.1	0949b351	e64b21a3…	❌ idem

Le binaire de release est byte-identique au build local de @nedseb depuis 0949b351. La toolchain utilisée (ARM officielle 10.3-2021.10 téléchargée depuis developer.arm.com via le Makefile) est strictement identique entre CI et local. La CI n'est pas en cause.

Le seul commit qui diffère entre la version qui marche et celle qui ne marche pas est PR #4 (0949b351 — config zone in F103 internal flash gap).

Analyse du code de PR #4

• ✅ Pas de modification de daplink_addr.h ni des linker scripts
• ✅ Layout d'adresses cohérent : config zone à 0x0800BC00-0x0800C000, dans le gap existant entre BL (ends at 0x0800BC00) et IF (starts at 0x0800C000). Le gap existait déjà depuis 2020 (ex-CONFIG_ADMIN, retiré par upstream)
• ✅ prerun_board_config() dans steami32.c n'est pas modifié — aucun code config zone n'est appelé au boot
• ✅ steami_config.c n'a pas de constructeur / init code — les fonctions sont appelées uniquement depuis process_task() sur réception de commande I2C
• ⚠️ m_text: 78 KB / 78 KB (100.00%) dans le build de release — zéro marge dans la région text. Pas une cause directe (le link passe l'ASSERT __DATA_END <= text_end), mais suspect

Statut de PR #3

PR #3 (feat/config-zone) implémentait la même feature mais via le W25Q64 SPI flash externe. Elle est OPEN, jamais mergée. C'est elle qui avait la race condition I2C IRQ documentée (callback I2C priorité 0 vs polling MicroPython 5ms pendant un sector_erase 400ms). PR #4 a été conçue comme l'alternative safe (internal flash, pas de bus contention). PR #3 n'est donc pas en cause pour ce bug puisque non-mergée.

Hypothèses restantes à investiguer

1. Mattéo flashe le mauvais asset : la release contient à la fois steami-daplink-firmware-*.bin (F103 DAPLink) et steami-micropython-firmware-*.bin (WB55). Si Mattéo drop le firmware MicroPython sur le MAINTENANCE drive, le bootloader F103 rejette (vector table invalide pour F103) → symptôme exact. → Demander à Mattéo le nom exact du fichier flashé.

2. Local mods de @nedseb au moment du build de mars : version_git.h du build local indique GIT_LOCAL_MODS = 1. Le working tree de /home/nedjar/sandbox/DAPLink avait des modifications non-committées le 19 mars 2026 qui faisaient potentiellement la différence. Contenu de ces mods : oublié, non récupérable.

3. m_text à 100% : la zone text est exactement pleine. Un build dans des conditions légèrement différentes (autre ccache, autre temp, autre host) pourrait produire un binaire de quelques octets de plus qui ne linkerait pas — mais le link de release a réussi, donc ce n'est pas le problème actuel. À surveiller si la cause s'avère liée à la taille (alignement, padding, debug info, etc.).

4. validate_bin_nvic() côté bootloader : la check de validité bootloader inspecte la vector table à 0x0800C000 (top-of-stack + reset handler). Si quelque chose dans le linkage de PR steami: Add config zone in F103 internal flash gap #4 rend cette vector table invalide pour le bootloader de Mattéo (mais valide pour celui de @nedseb), ça expliquerait. Peu probable mais pas exclu.

5. Bootloader plus ancien chez Mattéo : compatibilité régressive. Peu probable car @nedseb a aussi flashé sur sa carte sans problème (mais avec un firmware d'un commit antérieur).

Reproduction nécessaire

Avant d'aller plus loin, il faut un test sur hardware :

• Reproduire le symptôme avec steami-daplink-firmware-v0.23.1.bin exact (SHA256 e64b21a31c3563bb6b7c12d71e5bb2ad608c39650f38b7bb9e391331952a9ed3)
• Capturer les logs UART debug pendant le boot tentative
• Vérifier l'état du flash interne F103 (zone 0x0800C000 notamment) après le flash et reboot
• Idéalement, comparer avec un flash du même binaire bin via SWD (pyocd/openocd) pour distinguer un problème de bootloader-update vs interface-runtime

Notes complémentaires

• PR ci: Use official Arm GNU Toolchain 10.3-2021.10 for releases #7 (fix workflow generate_release.yml du fork pour utiliser la toolchain ARM officielle au lieu de apt) n'est pas liée à ce bug — défensive uniquement, le workflow concerné n'a jamais tourné et la chaîne de release réelle (release.yml de micropython-steami-lib) utilise déjà la bonne toolchain.

cc @nedseb