Sous-traitance de firmware MCU : définir les exigences de réception

Un projet de firmware MCU sous-traité est prêt pour la réception lorsqu’un autre ingénieur peut le compiler, le programmer, vérifier les interfaces convenues et expliquer son comportement en cas de panne. Une démonstration réussie est utile, mais elle ne définit pas ce qui se passe lorsqu’un capteur est débranché, que l’alimentation disparaît pendant l’enregistrement des paramètres ou que le réseau reste indisponible.

Ce guide propose une structure de réception pour les produits à microcontrôleur disposant de ressources limitées, avec ou sans RTOS. Il s’agit d’une liste de vérifications techniques, pas de l’affirmation qu’une carte particulière les a réussies. Les produits liés à la sécurité nécessitent leur propre analyse des dangers, processus de développement et examen réglementaire.

1. Fixer le périmètre avant le prix

Commencez par une fiche identifiant la référence et la révision du MCU, la révision de carte, les horloges, les mémoires externes, les modules périphériques, la chaîne de compilation, le SDK et la version du RTOS. Listez les appareils externes réels et leurs documents de protocole. « Prise en charge RS485 » décrit une interface électrique, pas le débit, le délai de changement de direction, les registres, les reprises ni l’interopérabilité applicative.

Séparez les fonctions obligatoires, les exclusions explicites et les hypothèses qu’un autre intervenant doit satisfaire. Si le client fournit un chargeur de démarrage, précisez son format d’image, ses réservations mémoire et son contrat de mise à jour. Si le matériel évolue encore, désignez la révision soumise à réception et la méthode d’évaluation des changements ultérieurs de broches ou de composants.

Chaque exigence doit avoir un identifiant stable et un résultat observable. « Acquisition fiable » est trop vague. Une meilleure exigence précise la trame d’entrée, la valeur décodée attendue, le délai de transmission admis, le traitement d’une erreur de somme de contrôle et le moyen de recueillir les preuves.

2. Définir le parcours des données jusqu’à l’application

Documentez pour chaque interface les réglages physiques, le format des messages, les délais, la propriété des ressources et les erreurs. Un produit d’acquisition doit permettre de comparer, pour un même échantillon, la lecture de l’instrument, les octets reçus, la grandeur décodée et la charge utile transmise. Précisez les unités, l’échelle, le signe, la représentation des valeurs invalides et l’origine de l’horodatage.

Écrivez ce qui se passe lorsque les producteurs dépassent les consommateurs. Une file peut refuser le dernier élément, éliminer le plus ancien, bloquer une tâche ou déclencher une faute. Aucun choix n’est universel. L’exigence doit choisir une politique et prévoir un compteur distinguant une perte silencieuse d’une entrée réellement inactive.

Distinguez également la livraison par le transport de l’exécution applicative. Un accusé de réception doit signifier clairement « analysé », « accepté » ou « exécuté ». Si une reprise peut actionner deux fois un relais, convenez d’une règle d’idempotence ou de numérotation et testez volontairement une commande dupliquée.

3. Rendre mesurables les limites temporelles et mémoire

Choisissez les limites à partir des besoins du produit, plutôt qu’en recopiant une période de tick habituelle. Définissez le front déclencheur, le point de mesure, la charge autorisée et la statistique de réception. On peut par exemple mesurer la réponse entrée-sortie avec un analyseur logique sous trafic simultané. Séparez le maximum observé d’une borne analytique : un essai fini ne prouve pas tous les ordonnancements possibles.

Pour un projet RTOS, recueillez les marges de pile par tâche, les échecs d’allocation, les maxima d’occupation des files et les temps d’exécution utiles sous la charge définie. FreeRTOS propose des fonctions de suivi de pile et de détection de débordement, mais la configuration et le portage comptent. Le niveau maximal observé renseigne sur les chemins exécutés, sans garantir que tous les futurs appels tiendront. Voir la documentation FreeRTOS sur la vérification des piles.

Indiquez l’unité de chaque mesure. Selon l’API et la plateforme, une profondeur de pile peut être exprimée en éléments ou en octets. Réservez une marge pour le diagnostic et les évolutions et rendez visibles les budgets RAM et Flash convenus dans le rapport de version.

4. Réceptionner aussi le comportement en défaut

• Entrée malformée : envoyez des trames tronquées, trop longues ou à somme de contrôle invalide. Vérifiez un traitement borné, un compteur défini et la reprise à la prochaine trame valide.
• Appareil absent : débranchez un capteur ou rendez un bus indisponible avec un montage sûr. Vérifiez les délais et la réactivité des fonctions indépendantes.
• Coupure réseau : interrompez le réseau d’essai autorisé. Observez les intervalles de reprise, les limites de file et la politique documentée d’abandon ou de retransmission après retour.
• Écriture de configuration interrompue : sur une unité de laboratoire récupérable, coupez l’alimentation pendant une modification autorisée. Le démarrage suivant doit choisir une version intacte ou des valeurs par défaut déclarées, pas des données partiellement décodées.
• Exécution bloquée : utilisez une version de test empêchant une tâche requise de progresser. Vérifiez la surveillance par watchdog, la cause de reset et l’état sûr des sorties.
• Mise à jour incorrecte : testez le rejet de métadonnées d’image ou une interruption selon le mécanisme de récupération. Préservez un moyen de restauration vérifié avant tout essai destructif.

Convenez au préalable du nombre d’unités, des répétitions, des conditions et des critères de réussite. Ce sont des décisions de projet, pas des seuils universels. N’attachez pas de charges industrielles non maîtrisées lors des injections de défauts.

5. Exiger un diagnostic utilisable après la livraison

Un enregistrement de faute doit relier le symptôme à une identité de compilation, une cause de reset, une durée de fonctionnement et un état limité. Définissez conservation, extraction et comportement lorsque le stockage est plein. Ne journalisez pas mots de passe, clés privées ou messages clients complets par simple commodité.

Lorsqu’il existe, un core dump de plateforme peut aider l’analyse après incident. ESP-IDF documente notamment des destinations Flash et UART et des outils utilisant la compilation correspondante. C’est une fonction spécifique à ESP-IDF, pas une promesse pour tout MCU. Voir le guide de core dump d’Espressif. Validez l’extraction choisie par une faute contrôlée avant réception.

6. Considérer le paquet de version comme un livrable testable

Exigez les révisions des sources et dépendances, instructions de compilation, configurations, scripts d’édition de liens, partitions, instructions de programmation, binaires, sommes de contrôle et symboles de débogage. Incluez licences et obligations de redistribution. Séparez identifiants de développement et instructions de provisionnement ; les secrets n’ont pas leur place dans l’archive de livraison.

L’ingénieur receveur doit compiler dans l’environnement propre documenté et programmer une unité désignée sans l’aide du poste du développeur initial. Si une reproduction octet pour octet est requise, définissez le contrôle des horodatages, fichiers générés et entrées de la chaîne d’outils. Sinon, exigez la reproduction fonctionnelle et expliquez les différences possibles de hachage.

Livrez ensemble procédure, preuves brutes, résultats par exigence et écarts non résolus. Chaque problème connu demande un déclencheur, un impact, un contournement, un responsable et une décision. « Accepté avec remarques » ne signifie rien si les remarques cachent une fonction obligatoire absente.

7. Diagnostiquer les échecs couche par couche

Si les données brutes sont correctes mais le décodage faux, examinez cadrage, ordre des octets et conversion avant le réseau. Si les délais apparaissent seulement avec les logs, comparez le blocage et la mise en tampon du journaliseur. Si seul un reset à chaud rétablit le fonctionnement, vérifiez état périphérique conservé, séquencement et validité des paramètres. Ne modifiez qu’un facteur à la fois et conservez la version défaillante pour démontrer l’amélioration avec le même test.

Appliquer la liste à un périmètre concret

La configuration de projet d’acquisition STM32 et d’intégration MQTT d’Obeita décrit le décodage d’instruments et les liaisons Ethernet ou cellulaires. Elle illustre le périmètre reliant trames brutes et valeurs publiées, sans prouver que la matrice ci-dessus a été exécutée. Pour revoir une livraison, consultez le service Diagnostic firmware et BSP.

Préparez révision de carte, exemples de protocole, paquet actuel de sources et de compilation, et courte liste des conséquences de panne inacceptables. Ces éléments transforment « firmware terminé » en plan de réception vérifiable.