Débogage Firmware MCU : Méthodes de Diagnostic

# Débogage des firmwares de microcontrôleurs : Méthodes diagnostiques éprouvées

Le diagnostic des firmwares sur microcontrôleurs commence par des vérifications basiques des paramètres système. Sans cela, le développement devient de l'empirisme pur. Nous aborderons des techniques éprouvées, des simples LED aux interfaces avancées, en nous focalisant sur des scénarios réels pour STM32 et plateformes similaires.

Première étape : sortie de l'horloge système sur les broches MCO. Cela permet de mesurer la fréquence réelle HSE ou SYSCLK avec un oscilloscope après division.

HAL_RCC_MCOConfig(RCC_MCO1, RCC_MCO1SOURCE_HSE, RCC_MCODIV_4);
HAL_RCC_MCOConfig(RCC_MCO2, RCC_MCO2SOURCE_SYSCLK, RCC_MCODIV_5);

{.pad.port=PORT_C, .pad.pin=9, .name="MCO_2",   .stm_mode=GPIO_MODE_AF_PP,      .gpio_pull=GPIO__PULL_AIR, .speed=GPIO_SPEED_FREQ_VERY_HIGH,  .alternate= GPIO_AF0_MCO,},
{.pad.port=PORT_A, .pad.pin=8, .name="MCO_1",   .stm_mode=GPIO_MODE_AF_PP,      .gpio_pull=GPIO__PULL_AIR, .speed=GPIO_SPEED_FREQ_VERY_HIGH,  .alternate= GPIO_AF0_MCO,},

Comparer les mesures avec votre code révèle les erreurs de configuration d'horloge.

Indicateurs de statut et vérifications basiques

Une LED de battement cardiaque est indispensable dans tout firmware. Une LED clignotant à 1 Hz confirme que le code s'exécute, vérifie le timing et montre que le système est vivant. Ajoutez une LED rouge dédiée aux erreurs logicielles ou matérielles.

• Avantages : Test visuel de fumée — aucun équipement supplémentaire requis.
• Implémentation : Timer avec période de 500 ms pour basculer la broche.
• Extensions : Multiples LED pour sous-systèmes (horloges, périphériques).

Pas de clignotement ? Le débogage ultérieur est inutile — le firmware ne démarre pas ou est bloqué.

Les fonctions assert ajoutent des vérifications robustes. Elles se déclenchent sur zéro argument :

• makeAssert : Vérifications à la compilation via Makefile.
• preprocAssert : Validations préprocesseur.
• staticAssert : Validation de config à la compilation.
• DynamicAssert : À l'exécution avec support de point d'arrêt GDB.

Un placement stratégique des assert localise les pannes sur toutes les phases du projet.

Débogage avancé via interfaces

L'interface CLI sur UART est l'outil le plus flexible. Une interface texte full-duplex sur Rx/Tx/GND permet :

• Lecture/écriture mémoire par adresse.
• Appel de fonctions par pointeur.
• Surveillance de compteurs, envoi de paquets I2C/SPI/UART.
• Interprétation des registres de timers.

Fonctionnalités minimales CLI :

• Écho d'entrée.
• Historique de commandes en mémoire non volatile.
• Aide et autocomplétion TAB.
• Authentification.
• Sortie colorée (rouge pour erreurs, jaune pour avertissements).
• Rendu de tableaux (GPIO, ADC).

La CLI préserve le timing temps réel, contrairement à JTAG/SWD. Le logging RAM avec vidage UART post-init diagnostique le démarrage précoce, y compris les horloges. Niveaux de support : LOG_ERROR, LOG_WARNING, LOG_INFO, LOG_DEBUG avec filtres par module (ex. : ll usb debug).

Outils d'analyse de signaux

Pour les processus temps réel, utilisez les GPIO comme marqueurs :

• Basculer des broches pour compter les étapes d'initialisation système.
• Mapper GPIO : Convertir des nombres en codes binaires sur plusieurs broches.

Un oscilloscope (au moins 2 canaux, numérique) capture les fronts. Les analyseurs logiques (Saleae, 8–16 canaux) excellent pour les bus comme MII/I2S/SDIO : vitesses USB 3.0, analyse période/fréquence/cycle de service sur PC.

Le DAC (10–12 bits) sort des valeurs analogiques vers l'oscillo. Idéal pour déboguer un ordonnanceur : les marches de tension révèlent les priorités des threads.

Limites du débogage pas à pas et alternatives

GDB sur SWD/JTAG s'arrête aux points d'arrêt (PC/LR depuis HardFault). Mais il perturbe le timing : les timers matériels avancent plus vite, le WDT reset le MCU. Les optimisations (-O0 -g3) consomment l'espace Flash, souvent indisponible.

Alternative : arm-none-eabi-addr2line pour mapper les adresses HardFault aux lignes source :

set ELF_FILE=C:/ncs/v2.1.0/nrf/applications/nrf5340_audio/build/gateway_app/zephyr/zephyr.elf
set ADDR2LINE="C:\Program Files (x86)\GNU Arm Embedded Toolchain\10 2021.10\bin\arm-none-eabi-addr2line.exe"
%ADDR2LINE% -e %ELF_FILE% 0x000054cd
%ADDR2LINE% -e %ELF_FILE% 0x0000857e

Les écrans OLED fournissent des métriques autonomes : monitoring style Tamagotchi sans UART. Les tests unitaires couvrent le code sans débogueur, permettant un refactoring sécurisé.

Points clés à retenir

• LED battement cardiaque et MCO : Tests de fumée essentiels — sans eux, vous naviguez à l'aveugle.
• CLI avec niveaux de logging : Contrôle total sans perturbation de timing.
• GPIO/DAC + oscillo/analyseur : Insights signaux temps réel.
• Asserts et addr2line : Localisation précise des HardFault sans débogage complet.
• GDB/SWD : Dernier recours à cause des distorsions de timing.

— Editorial Team