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

Objetivos

Bajo la superficie de la X8 trabaja un tercer sistema que el IDE nunca ve: el Cortex-M7 del STM32H747XI ejecuta un firmware bridge propietario de Arduino (repositorio arduino/portentax8-stm32h7-fw, última release 0.0.3, octubre de 2023) «normalmente invisible para el usuario», que mapea todos los periféricos del MCU como periféricos de Linux a través de los módulos del kernel x8h7_\* (repositorio portentax8-x8h7). Cuando este firmware está desincronizado, los periféricos del lado de Linux fallan sin que el sketch M4 tenga nada que ver. Este tutorial: diagnóstico, actualización limpia y conocimiento de los bugs abiertos (CAN TX stall).

Hardware

• 1 × Arduino Portenta X8 + cable USB-C de datos
• Binario del firmware: STM32H747AII6_CM7.bin desde las releases de github.com/arduino/portentax8-stm32h7-fw
• adb + acceso sudo en la placa
• Las notas de versión: docs.arduino.cc/tutorials/portenta-x8/x8-firmware-release-notes
• Para la depuración de bajo nivel del H7: configuración OpenOCD stlink stm32h7x_dual_bank (definida en boards.txt del core Mbed)

Código completo

# 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 a 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. apres reboot, verifier l'etat 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

Verificación esperada

Después de 399-install-update y el reinicio con el botón (10 s), los módulos x8h7_* están cargados (lsmod), el servicio m4-proxy se reinicia correctamente y las llamadas RPC vuelven a funcionar. El procedimiento es exactamente el del tutorial oficial image-flashing; el dashboard Linux Wizard ofrece una visión general del estado de la placa. Es lo primero que debes hacer antes de culpar a tu sketch cuando «el RPC ya no funciona en absoluto».

Errores frecuentes

• Creer que el firmware M7 se flashea como un sketch de Arduino: se actualiza desde Linux (adb push + sudo ./399-install-update), no desde el IDE — el IDE, por su parte, solo habla con el M4.
• Olvidar el reinicio de 10 s con el botón después de la instalación: sin reinicio, el firmware antiguo permanece activo y nada cambia — el procedimiento oficial lo exige explícitamente.
• Firmware desincronizado = periféricos fantasma de Linux: el bridge M7 expone GPIO, CAN, etc. a Linux; un firmware demasiado antiguo rompe estos periféricos sin mensajes claros en el lado de la aplicación — verifica primero la página firmware-release-notes.
• Bug conocido de CAN: «HAL_FDCAN_TxBufferCompleteCallback silencia el estado de TX-complete cuando la cola SPI compartida está llena — provoca un bloqueo permanente de TX en el lado de Linux» (issue #74, abierta); se han enviado correcciones de desbordamiento de buffer mediante #60/#61 — si tu bus CAN se congela en el lado de Linux, es un sospechoso documentado, no tu cableado.
• Plataforma poco activa: la última release del firmware es de octubre de 2023 — no esperes correcciones rápidas; prueba cualquier hipótesis de solución en una placa de demostración.
• >
• >