Le développement firmware embarqué ne s’arrête pas au premier démarrage d’une carte. Un capteur transmet ses mesures et la communication fonctionne : le prototype semble prêt. Pourtant, il faut encore prévoir les incidents avant de fabriquer le produit.
Que fait le système si un capteur ne répond plus ? Comment réagit-il lorsque plusieurs événements arrivent ensemble ou qu’une coupure interrompt une mise à jour ? Sur microcontrôleur, la fiabilité dépend autant du code que des essais sur la carte finale.
Voici les points à cadrer pour passer du prototype à un produit que votre équipe pourra fabriquer, maintenir et faire évoluer.
Développement firmware embarqué : cadrer les exigences
Dans cet article, le firmware désigne le logiciel qui s’exécute sur un microcontrôleur. Il pilote les périphériques, traite les données et gère les communications. Il peut fonctionner sans système d’exploitation, en « bare metal », ou avec un système temps réel, appelé RTOS, comme FreeRTOS.
Le choix d’un STM32 ou d’une autre famille dépend donc des besoins du produit : mémoire, interfaces, consommation et performances. Il faut aussi prévoir les futures opérations de maintenance.
Avant de développer, transformez ces besoins en critères vérifiables :
- Quel délai maximal le système doit-il respecter entre une mesure et son traitement ?
- Combien de temps le produit peut-il mettre à démarrer ?
- Quelle consommation faut-il atteindre en activité et en veille ?
- Quelles ressources faut-il réserver aux évolutions et aux mises à jour ?
- Comment le système doit-il réagir lorsqu’une fonction devient indisponible ?
Par exemple, « le système doit être réactif » laisse trop de place à l’interprétation. Fixez plutôt un délai mesurable et un scénario d’essai. Dès le départ, le développement firmware embarqué relie ainsi les attentes du produit aux critères de validation.
Intégrer le firmware sur la carte finale
Une carte de développement facilite les premiers essais. En revanche, la carte du produit peut présenter des différences de câblage, d’alimentation ou de composants. L’équipe doit donc vérifier ses hypothèses sur le matériel final.
Contrôler le démarrage et les périphériques
La mise au point commence par les horloges, les broches et l’initialisation des périphériques. Elle couvre aussi les interruptions et, si le projet les utilise, les transferts DMA, qui permettent un accès direct à la mémoire.
Sur STM32, STM32CubeMX facilite la configuration et la génération du code d’initialisation. La documentation de STMicroelectronics en précise le périmètre. Toutefois, l’équipe doit ensuite vérifier les réglages et le comportement du code sur sa propre carte.
Testez notamment la mise sous tension, le redémarrage logiciel, le retour après incident et la sortie de veille. Mesurez également la consommation dans les états réels du produit, avec ses périphériques connectés.
Prévoir les erreurs de communication
Pour chaque liaison I²C, SPI, UART ou CAN, définissez les délais d’attente et les conditions de nouvelle tentative. Prévoyez aussi la réaction aux données invalides.
Par exemple, un capteur peut cesser de répondre sur une liaison I²C. Selon la fonction, le système peut signaler une mesure indisponible, tenter une récupération limitée ou passer dans un état de repli. L’équipe produit choisit alors le comportement attendu, puis les développeurs le testent sur carte.
Dans un projet de développement firmware embarqué, ces règles évitent qu’une attente sans limite bloque d’autres fonctions. Pour approfondir les communications concernées, consultez notre article sur les usages industriels du bus CAN.
Organiser les tâches et maîtriser les ressources
Une boucle principale peut convenir lorsque les traitements restent simples et maîtrisés. Un RTOS peut, quant à lui, faciliter la gestion de plusieurs activités concurrentes : acquisition, communication, traitement et supervision.
Le choix dépend des délais à respecter, des échanges entre fonctions et des compétences de l’équipe. Avec un RTOS, il faut notamment maîtriser les priorités, les synchronisations et l’accès aux ressources partagées.
Mesurez ensuite sur le microcontrôleur :
- Les temps d’exécution et les délais de réaction.
- L’utilisation de la RAM et de la mémoire flash.
- La pile de chaque tâche et les tampons de communication.
- Le comportement sous forte activité.
FreeRTOS propose par exemple une mesure de la marge de pile observée. Cette indication aide au dimensionnement. Cependant, elle reflète uniquement les scénarios que l’équipe a exécutés : elle ne garantit pas la marge dans tous les cas.
Pour approfondir la structure du code et la gestion des ressources, retrouvez notre article sur le développement C++ embarqué.
Développement firmware embarqué : tester les incidents
Les essais fonctionnels vérifient que le produit accomplit ses tâches. Le développement firmware embarqué demande aussi de tester ses réactions lorsqu’un composant ou une communication cesse de fonctionner.
Combinez donc plusieurs niveaux de validation :
| Niveau de test | Situations à couvrir | Objectif |
|---|---|---|
| Tests hors cible | Calculs, machines à états, décodage de messages | Vérifier rapidement la logique et ses cas limites |
| Tests sur carte | Périphériques, communications, interruptions, veille et réveil | Vérifier l’intégration et les contraintes réelles |
| Essais en défaut | Capteur absent, données invalides, perte de liaison, coupure d’alimentation | Vérifier la détection et les réactions attendues |
| Essais prolongés | Cycles répétés, activité soutenue, accumulation d’événements | Rechercher les anomalies qui apparaissent avec le temps ou la charge |
Les tests sur PC facilitent l’automatisation. En revanche, ils ne suffisent pas à valider le matériel final. La documentation du simulateur natif de Zephyr précise notamment que cet environnement ne reproduit pas un microcontrôleur particulier.
Préparez également le diagnostic : version du firmware, cause du dernier redémarrage et erreurs de communication. Ces informations aident le support à comprendre une panne. Leur collecte doit toutefois respecter les limites de mémoire et de performance du produit.
Un chien de garde, ou « watchdog », peut déclencher un redémarrage si le logiciel ne le rafraîchit plus dans le délai prévu. La documentation STM32 décrit ce mécanisme. Pour vérifier son utilité, provoquez des blocages représentatifs et contrôlez la réaction du système.
Prévoir les mises à jour dès la conception
La mise à jour fait partie du développement firmware embarqué dès la conception. En effet, elle influence la répartition de la mémoire flash, le démarrage et la maintenance.
Selon le produit, l’équipe peut transmettre une nouvelle version par une liaison locale ou à distance. Dans les deux cas, elle doit répondre à plusieurs questions :
- Comment vérifier la compatibilité avec la carte et les données de configuration ?
- Comment détecter une image logicielle incomplète ou invalide ?
- Que faire si l’alimentation se coupe pendant l’opération ?
- Comment récupérer un équipement qui ne démarre plus correctement ?
Un bootloader, c’est-à-dire un programme de démarrage, peut prévoir une phase d’essai avant de confirmer une nouvelle version. Par exemple, MCUboot propose des mécanismes de retour à la version précédente, selon le mode de mise à jour choisi.
L’équipe doit toutefois vérifier que sa configuration permet ce retour. Elle doit aussi prévoir la compatibilité des données persistantes, afin que l’ancienne version puisse les relire.
Enfin, distinguez corruption et authenticité. Un CRC détecte certaines erreurs accidentelles, mais ne prouve pas l’origine du firmware. Pour authentifier une version, le système peut notamment vérifier une signature à partir d’une clé de confiance. STM32Trust présente les fonctions de démarrage et de mise à jour sécurisés de l’écosystème STM32.
Préparer la fabrication et la maintenance
Avant la production, identifiez précisément la version que chaque équipement doit recevoir. Pour chaque livraison, conservez le code source, les dépendances, les paramètres de compilation, le binaire et les résultats de validation.
Indiquez également les révisions de carte compatibles. Vous pourrez ainsi retrouver la bonne combinaison entre matériel et logiciel lors d’un retour terrain.
La procédure de programmation précise ensuite le firmware à utiliser, les paramètres propres au produit et les contrôles après programmation. Elle indique aussi les informations à conserver. Sans cette traçabilité, l’équipe risque de perdre du temps à reconstituer la configuration d’un équipement.
Enfin, préparez une documentation courte et exploitable : compilation, programmation, récupération, limites connues et points de vigilance. Un autre ingénieur doit pouvoir reprendre le projet à partir de ces éléments.
Renforcer votre équipe de développement firmware embarqué
Un renfort en développement firmware embarqué peut faciliter la mise au point d’une carte, l’intégration d’un protocole ou une campagne de validation. Il peut aussi répondre à un besoin durable de maintenance et d’évolution.
Pour cadrer l’intervention, partez d’un résultat vérifiable : diagnostiquer des redémarrages, valider une mise à jour, intégrer un périphérique ou automatiser des essais sur banc. Le choix du profil dépend alors de la cible et du travail attendu : C/C++, mise au point sur carte, RTOS, communications ou validation.
GEEKO accompagne les équipes industrielles en développement logiciel embarqué et en renfort d’équipe. Un premier échange permet ainsi de préciser votre contexte technique, les difficultés du projet et les compétences à mobiliser.
Vous préparez une nouvelle carte ou cherchez à fiabiliser un firmware existant ? Découvrez notre accompagnement en conseil en ingénierie et échangeons sur votre besoin.