🛠 Le firmware caché : mettre à jour le bridge STM32H7 M7 qui expose les périphériques à Linux

Objectifs

Sous la surface de la X8 travaille un troisième système que l'IDE ne voit jamais : le Cortex-M7 du STM32H747XI exécute un firmware bridge propriétaire Arduino (dépôt arduino/portentax8-stm32h7-fw, dernière release 0.0.3, octobre 2023) « normalement invisible à l'utilisateur », qui mappe tous les périphériques du MCU en périphériques Linux via les modules noyau x8h7_\* (dépôt portentax8-x8h7). Quand ce firmware est désynchronisé, les périphériques côté Linux tombent sans que le sketch M4 y soit pour quoi que ce soit. Ce tuto : diagnostic, mise à jour propre, et connaissance des bugs ouverts (CAN TX stall).

Matériel

• 1 × Arduino Portenta X8 + câble USB-C data
• Binaire de firmware : STM32H747AII6_CM7.bin depuis les releases de github.com/arduino/portentax8-stm32h7-fw
• adb + accès sudo sur la carte
• Les notes de version : docs.arduino.cc/tutorials/portenta-x8/x8-firmware-release-notes
• Pour le debug bas niveau du H7 : config OpenOCD stlink stm32h7x_dual_bank (définie dans boards.txt du core Mbed)

Code complet

# 1. Telecharger le binaire de firmware M7 (releases du depot officiel)
#    puis le pousser sur la carte :
adb push STM32H747AII6_CM7.bin /home/fio

# 2. Installer la mise à jour dans le STM32H747
adb shell
fio@portenta-x8:~$ cd /home/fio
fio@portenta-x8:~$ sudo ./399-install-update

# 3. Reboot : maintenir le bouton poussoir embarque ~10 s

# 4. après reboot, vérifier l'état general
sudo journalctl -fu m4-proxy        # le pont RPC doit repasser au vert
lsmod | grep x8h7                   # modules bridge charges
dmesg | grep -i x8h7                # traces du probe des peripheriques

# Optionnel : dashboard Linux Wizard depuis le PC
#   adb forward tcp:8080 tcp:80  ->  http://localhost:8080

Vérification attendue

Après 399-install-update et le reboot au bouton (10 s), les modules x8h7_* sont chargés (lsmod), le service m4-proxy redémarre proprement et les appels RPC refonctionnent. La procédure est exactement celle du tuto officiel image-flashing ; le dashboard Linux Wizard donne une vue d'ensemble de l'état de la carte. C'est la première chose à faire avant de accuser ton sketch quand « le RPC ne marche plus du tout ».

Erreurs fréquentes

• Croire que le firmware M7 se flash comme un sketch Arduino : il se met à jour depuis Linux (adb push + sudo ./399-install-update), pas depuis l'IDE — l'IDE, lui, ne parle qu'au M4.
• Oublier le reboot de 10 s au bouton après l'install : sans reboot, l'ancien firmware reste actif et rien ne change — la procédure officielle l'exige explicitement.
• Firmware désynchronisé = périphériques Linux fantômes : le bridge M7 expose GPIO, CAN, etc. à Linux ; un firmware trop vieux casse ces périphériques sans message clair côté application — vérifier la page firmware-release-notes en premier.
• Bug CAN connu : « HAL_FDCAN_TxBufferCompleteCallback silently drops the TX-complete status when the shared SPI queue is full — causes permanent Linux-side TX stall » (issue #74, ouverte) ; des correctifs de buffer-overrun ont été poussés via #60/#61 — si ton bus CAN se fige côté Linux, c'est un suspect documenté, pas ton câblage.
• Plateforme peu active : dernière release firmware octobre 2023 — ne t'attends pas à des correctifs rapides ; teste toute hypothèse de fix sur une carte de démo.
• >
• >