Il est fréquent en développement embarqué que la fonction printf se comporte normalement lors d'une session de débogage, mais cesse de fonctionner une fois le firmware flashé sur la cible, exécutée de manière autonome. Ce problème complexe peut découler de multiples facteurs liés à la configuration matérielle, l'initialisation des périphériques et la gestion des bibliothèques logicielles. Cet article propose une analyse systématique des causes profondes et des solutions détaillées.

I. Analyse et Solutions des Causes Courantes

1. Absence de Redirection de la Sortie Standard

Par défaut, la fonction printf de la bibliothèque standard C est conçue pour envoyer ses données à la sortie standard (stdout), généralement associée à un écran ou une console sur un système d'exploitation. Dans un système embarqué, cette sortie doit être explicitement redirigée vers un péripphérique physique tel qu'une liaison série (UART), un écran LCD ou une interface USB.

Solution : Implémenter une Redirection Appropriée

La méthode la plus courante consiste à surcharger la fonction fputc (ou parfois _write pour certaines toolchains comme newlib-nano), qui est appelée par printf pour envoyer chaque caractère.

#include <stdio.h> // Pour FILE et fputc
#include <stdint.h> // Pour uint8_t

// Fonction abstraite d'envoi d'un octet via UART.
// L'implémentation réelle dépend du microcontrôleur et de la couche d'abstraction matérielle (HAL) utilisée.
void envoyer_octet_uart(uint8_t donnee) {
    // Exemple conceptuel pour un microcontrôleur STM32 avec HAL:
    // HAL_UART_Transmit(&h_uart_peripherique, &donnee, 1, 100);
    // Ou un accès direct aux registres:
    // while (!(UART_REGISTRE->SR & USART_SR_TXE)); // Attendre que le buffer de transmission soit vide
    // UART_REGISTRE->DR = donnee; // Envoyer l'octet
}

// Redirection de la fonction fputc de la bibliothèque standard C
int fputc(int caractere_a_envoyer, FILE *flux_de_sortie) {
    // Vérifier si le flux est la sortie standard ou la sortie d'erreur standard
    if (flux_de_sortie == stdout || flux_de_sortie == stderr) {
        envoyer_octet_uart((uint8_t)caractere_a_envoyer);
        return caractere_a_envoyer; // Retourner le caractère envoyé en cas de succès
    }
    return EOF; // Retourner EOF (End Of File) pour indiquer une erreur ou un flux non géré
}

Pour des raisons de légèreté ou pour éviter certaines dépendances de la bibliothèque standard, une fonction printf personnalisée peut être implémentée. Celle-ci utilise généralement vsnprintf pour formater la chaîne dans un buffer, puis envoie ce buffer caractère par caractère via une fonction d'envoi série.

#include <stdarg.h> // Pour gérer les listes d'arguments variables (va_list)
#include <stdio.h>  // Pour vsnprintf

// Fonction d'envoi d'un seul caractère via la liaison série (implémentée via envoyer_octet_uart)
void envoyer_char_serie(char c) {
    envoyer_octet_uart((uint8_t)c);
}

// Implémentation simplifiée d'une fonction d'impression personnalisée
void ma_fonction_print(const char *format_chaine, ...) {
    char buffer_temp[256]; // Buffer pour stocker la chaîne formatée
    va_list arguments_variables;

    va_start(arguments_variables, format_chaine);
    // Formater la chaîne et ses arguments dans le buffer_temp
    vsnprintf(buffer_temp, sizeof(buffer_temp), format_chaine, arguments_variables);
    va_end(arguments_variables);

    // Envoyer le contenu du buffer, caractère par caractère
    for (char *ptr = buffer_temp; *ptr != '\0'; ptr++) {
        envoyer_char_serie(*ptr);
    }
}

2. Initialisation Incomplète ou Erronée du Périphérique Série (UART)

Lorsque le programme est flashé et s'exécute de manière autonome, il est crucial que toutes les étapes d'initialisation du périphérique série soient exécutées correctement. En mode débogage, l'outil de débogage (J-Link, ST-Link, etc.) peut parfois initialiser ou maintenir actifs certains périphériques, masquant ainsi des lacunes dans le code d'initialisation du programme.

Solution : Vérifier et Confirmer l'Initialisation de l'UART

Assurez-vous que les horloges du périphérique UART et des broches GPIO associées sont activées, que les broches GPIO sont configurées en mode fonction alternative approprié, et que les paramètres de communication (baud rate, nombre de bits de données, bits d'arrêt, parité) sont corrects.

#include <stdint.h>

// Ces définitions sont des exemples conceptuels.
// Les adresses et masques réels dépendent de l'architecture spécifique du microcontrôleur.
#define REG_RCC_AHB_EN   *(volatile uint32_t*)0x40023830 // Exemple : Registre d'activation des horloges AHB
#define REG_RCC_APB_EN   *(volatile uint32_t*)0x40023844 // Exemple : Registre d'activation des horloges APB

#define REG_GPIO_MODER   *(volatile uint32_t*)0x40020000 // Exemple : Registre de mode des GPIO (Port A)
#define REG_GPIO_AFRL    *(volatile uint32_t*)0x40020020 // Exemple : Registre de fonction alternative basse des GPIO (Port A)

#define REG_UART_BRR     *(volatile uint32_t*)0x40013808 // Exemple : Registre de Baud Rate de l'UART1
#define REG_UART_CR1     *(volatile uint32_t*)0x4001380C // Exemple : Registre de contrôle 1 de l'UART1

// Bits d'activation et configuration pour des périphériques spécifiques
#define BIT_EN_GPIOA     (1 << 0) // Bit d'activation de l'horloge GPIOA
#define BIT_EN_UART1     (1 << 4) // Bit d'activation de l'horloge USART1 (APB2)

// Fonction de configuration du port série (UART1)
void configurer_port_serie(uint32_t vitesse_baud) {
    // 1. Activer les horloges des périphériques (UART et GPIO)
    REG_RCC_AHB_EN |= BIT_EN_GPIOA; // Activer horloge GPIO Port A
    REG_RCC_APB_EN |= BIT_EN_UART1; // Activer horloge UART1

    // 2. Configurer les broches GPIO pour la fonction alternative UART
    // Supposons PA9 (TX) et PA10 (RX) pour UART1
    // Configurer PA9 en mode fonction alternative (AF)
    REG_GPIO_MODER &= ~(0b11 << (9 * 2)); // Effacer bits mode PA9
    REG_GPIO_MODER |= (0b10 << (9 * 2));  // Définir PA9 en AF
    // REG_GPIO_AFRH (ou AFRL) doit être configuré pour sélectionner AF7 pour UART1 TX/RX sur STM32F4
    // REG_GPIO_AFRL &= ~(0xF << (9 * 4)); REG_GPIO_AFRL |= (0x7 << (9 * 4)); // Exemple pour AF7

    // 3. Configurer les paramètres de l'UART
    REG_UART_CR1 = 0; // Désactiver UART pendant la configuration

    // Calcul du diviseur de baud rate (exemple pour une horloge PCLK de 84MHz)
    // Diviseur = Fréquence_PCLK_UART / (16 * Vitesse_baud)
    REG_UART_BRR = (uint32_t)(84000000 / (16 * vitesse_baud)); // À adapter selon votre horloge
    
    // Configurer 8 bits de données, pas de parité, 1 bit d'arrêt
    REG_UART_CR1 |= (1 << 3);  // Activer l'émetteur (TE)
    // REG_UART_CR1 |= (1 << 2);  // Activer le récepteur (RE) si nécessaire

    // 4. Activer le périphérique UART
    REG_UART_CR1 |= (1 << 13); // Activer l'UART (UE)
}

3. Configuration Inappropriée des Librairies et de l'Environnement de Compilation

Certaines versions ou configurations de bibliothèques C standard peuvent ne pas être optimisées ou complètes pour les environnements embarqués, entraînant des problèmes lors de l'exécution autonome.

Solution : Ajuster les Options de Compilateur/Lieur

• MicroLIB : Pour les IDE comme Keil, l'option "Use MicroLIB" (ou "Use C MicroLib") doit être activée. Cette version allégée de la bibliothèque C est optimisée pour les systèmes à ressources limitées.
• Support des Flottants : Si printf est utilisé avec le spécificateur de format %f pour les nombres à virgule flottante, un support spécifique peut être requis. Par exemple, avec Keil, il faut ajouter -u _printf_float aux options du lieur. Avec GCC, cela peut impliquer d'utiliser -specs=nano.specs -u _printf_float.
• Bibliothèques Allégées : Envisagez d'utiliser des implémentations de printf tierces et plus légères, comme mpaland/printf, qui sont conçues spécifiquement pour les systèmes embarqués et offrent une meilluere maîtrise de la taille du code et des dépendances.

4. Problèmes de Gestion de la Mémoire (Pile/Tas)

La fonction printf, surtout avec des chaînes de format complexes ou un grand nombre d'arguments, peut consommer une quantité non négligeable de mémoire temporaire sur la pile (pour les arguments et les buffers internes) ou sur le tas (si elle alloue dynamiquement). Un débordement de pile ou un manque de mémoire peut entraîner des comportements imprévisibles.

Solution : Optimiser la Gestion de la Mémoire

• Ajuster les Tailles de Pile et de Tas : Augmentez la taille allouée à la pile (__stack_size) et au tas (__heap_size) dans le fichier de démarrage du projet (par exemple, startup_*.s). Le tas est moins souvent utilisé par printf directement, mais un débordement de pile peut corrompre d'autres zones mémoire.
• Désactiver la Mise en Cache par Ligne : Utilisez setvbuf(stdout, NULL, _IONBF, 0) pour désactiver la mise en mémoire tampon par ligne de stdout. Cela assure que les caractères sont envoyés immédiatement, réduisant ainsi les risques de débordement de buffer interne de printf.
• Utiliser des Buffers Circulaires : Pour les applications temps réel, une approche plus robuste consiste à utiliser un buffer circulaire avec une routine d'envoi par interruption pour l'UART. Cela permet d'écrire rapidement les données dans le buffer sans bloquer l'exécution du programme, et l'UART envoie les données en arrière-plan.

5. Différences de Comportement entre Débogage et Exécution Autonome

Le débogueur peut introduire des conditions qui masquent des problèmes latents. Par exemple, un débogueur peut maintenir l'alimentation stable ou initialiser des registres que le code ne fait pas explicitement.

Solution : Vérifications Approfondies

• Mode de Flashage et Cavaliers : Assurez-vous que la carte est configurée pour le mode d'exécution autonome après le flashage (par exemple, des cavaliers de démarrage bien positionnés).
• Vérification de la Connexion Matérielle : Assurez-vous que les câbles série sont correctement connectés (TX vers RX, RX vers TX, GND vers GND) et que l'alimentation de la carte est stable et suffisante (une tension trop basse peut affecter le fonctionnement des périphériques).
• Initialisation Complète : Confirmez que toutes les fonctions d'initialisation matérielle sont appelées au début de main(), avant toute utilisation de printf.

II. Stratégies de Diagnostic et Vérification

Lorsqu'un problème persiste, des techniques de débogage ciblées peuvent aider à isoler la cause.

1. Tests Minimaux : Créez un projet minimaliste contenant uniquement l'initialisation de l'UART et un appel à printf("Hello World\n");. Si cela fonctionne, réintroduisez progressivement des parties de votre code pour identifier le conflit.
2. Indicateurs Visuels : Utilisez une LED. Allumez-la avant l'appel à printf et éteignez-la après. Si la LED s'allume mais ne s'éteint pas, ou si elle ne s'allume pas du tout, cela indique un blocage ou un crash dans ou avant la fonction d'impression.
3. Analyse du Signal UART : Un analyseur logique ou un oscilloscope peut être utilisé pour observer le signal sur la broche TX de l'UART. Cela permet de vérifier si des données sont réellement envoyées, à quelle vitesse (baud rate), et si le format est correct. Même si les données sont illisibles, la présence d'un signal indique que la partie matérielle de l'UART fonctionne.
4. Validation par Méthodes Alternatives : Essayez d'envoyer une chaîne de caractères directement via la fonction de transmission d'octets de votre HAL (par exemple, HAL_UART_Transmit(&huart1, (uint8_t*)"Test", 4, 100);). Si cette méthode fonctionne, le problème se situe probablement dans la redirection de fputc ou dans la configuration de la bibliothèque printf.

III. Synthèse des Différences de Comportement

Comprendre pourquoi printf peut fonctionner en débogage mais échouer en exécution autonome est clé pour la résolution.