Les développeurs de logiciels ont tendance à être un groupe très optimiste et juste garder leur code fonctionnant fidèlement pendant une longue période, c’est tout. Il semble assez rare pour un microcontrôleur de sortir de l’espace d’application et de s’exécuter dans un espace de code non intentionnel. Cependant, ce n’est pas moins probable qu’un débordement de cache ou un pointeur d’erreur perdant une référence. Cela arrive! Le comportement du système après que cela se produise sera incertain, parce que l’espace mémoire est 0xFF par défaut, ou parce que la zone mémoire n’est généralement pas écrite, la valeur qu’elle contient peut seulement être connue de dieu.

Cependant, il existe des techniques de liaison ou IDE assez complètes qui peuvent être utilisées pour aider à identifier de tels événements et à récupérer le système à partir de ceux-ci. Il existe de nombreuses combinaisons possibles que vous pouvez utiliser pour remplir la mémoire inutilisée, mais si vous voulez construire un système plus fiable, le choix le plus évident est de placer un gestionnaire de défaut ISR à ces endroits. Si quelque chose se passe mal dans le système, le processeur commence à exécuter le code en dehors de l’espace du programme, ce qui déclenche l’isr et permet de stocker l’état du processeur, du registre et du système avant de décider de la mesure corrective à prendre.

Un grand avantage pour les ingénieurs embarqués est que notre IDE et notre chaîne d’outils peuvent automatiquement générer une application ou une somme de contrôle de l’espace mémoire par rapport à laquelle vérifier que l’application est solide. Il est intéressant de noter que dans la plupart de ces cas, la somme de contrôle n’est utilisée que lorsque le code du programme est chargé dans le périphérique.

Cependant, si le CRC ou la somme de contrôle est conservé en mémoire, vérifier que l’application est toujours intacte au démarrage (ou même périodiquement pour un système de longue durée) est un excellent moyen de s’assurer que l’inattendu ne se produise pas. La probabilité de changement d’une application programmée est maintenant faible, mais compte tenu des milliards de microcontrôleurs livrés chaque année et de l’environnement de travail potentiellement difficile, le risque de crash d’une application de dispositif médical n’est pas nul. Plus probablement, une faille dans le système pourrait entraîner une écriture flash ou un effacement flash dans un secteur, compromettant ainsi l’intégrité de l’application.

Afin de construire un système plus fiable et plus solide, il est important de s’assurer que le matériel du système fonctionne correctement. Après tout, le matériel peut échouer. (heureusement, le logiciel ne tombe jamais en panne; Il fait ce que le code lui dit de faire, que ce soit bien ou mal.) Vérifier qu’il n’y a pas de problèmes à l’intérieur ou à l’extérieur de la RAM au démarrage est un bon moyen de s’assurer que le matériel fonctionne comme prévu.

Il existe de nombreuses façons d’effectuer une vérification de la RAM, mais une approche commune est d’écrire un motif connu et d’attendre un court laps de temps avant de le lire à nouveau. Le résultat devrait être que ce qui est lu est ce qui est écrit. La vérité est que les contrôles de RAM passent dans la plupart des cas, et c’est ce que nous voulons. Cependant, il y a aussi une très faible chance que la vérification ne passe pas, ce qui fournit une excellente occasion pour le système de signaler un problème matériel.

Pour de nombreux développeurs embarqués, la pile semble être une force assez mystérieuse. Quand des choses étranges commencent à se produire, les ingénieurs sont finalement trompés, et ils commencent à penser que peut-être quelque chose se passe dans la pile. Le résultat est d’ajuster sans réfléchir la taille et la position de la pile, et ainsi de suite. Mais l’erreur est souvent indépendante de la pile, mais comment pouvez-vous être si sûr? Après tout, combien d’ingénieurs ont réellement effectué une analyse de la taille de la cheminée dans le pire des cas?

La taille de la pile est attribuée statiquement au moment de la compilation, mais la pile est utilisée dynamiquement. Lorsque le code s’exécute, les variables, les adresses de retour et les autres informations requises par l’application sont stockées en continu sur la pile. Ce mécanisme fait croître la pile dans la mémoire qu’elle alloue. Cependant, cette croissance peut parfois dépasser les limites de capacité déterminées lors de la compilation, provoquant la corruption des données dans les régions mémoire adjacentes.

Une façon de s’assurer que la pile fonctionne correctement est d’implémenter un moniteur de pile dans le code "d’intégrité" de votre système (combien d’ingénieurs font cela?). Le moniteur de pile crée une zone tampon entre la pile et l’ "autre" zone mémoire et la remplit de motifs de bits connus. Le moniteur surveille alors constamment le modèle pour tout changement. Si le motif des bits change, cela signifie que la pile est devenue trop grande et est sur le point de pousser le système dans l’enfer sombre! À ce stade, le moniteur peut enregistrer la survenue d’événements, l’état du système, et toute autre donnée utile pour un diagnostic ultérieur du problème.

Les moniteurs de pile sont disponibles dans la plupart des systèmes d’exploitation en temps réel (RTOS) ou des systèmes de microcontrôleurs qui implémentent une unité de protection de la mémoire (MPU). La chose effrayante est que ces fonctionnalités sont désactivées par défaut, ou sont souvent désactivées intentionnellement par les développeurs. Une recherche rapide sur le web révèle que beaucoup de gens recommandent d’éteindre le moniteur de pile dans le système d’exploitation en temps réel pour économiser 56 octets d’espace mémoire flash, etc., ce qui ne vaut pas le coût!

Dans le passé, il était difficile de trouver une unité de protection mémoire (MPU) dans un microcontrôleur petit et peu coûteux, mais cela commence à changer. Les microcontrôleurs du haut de gamme au bas de gamme ont déjà des mpu, et ces mpu offrent aux développeurs de logiciels embarqués la possibilité d’améliorer considérablement la robustesse de leur micrologiciel.

Le MPU a été progressivement couplé au système d’exploitation afin d’établir un espace mémoire où les traitements sont tous séparés, ou où les tâches peuvent exécuter leur code sans crainte d’être contournées. Si quelque chose se produit, le traitement non contrôlé est annulé et d’autres mesures de protection sont mises en œuvre. Gardez un œil sur les microcontrôleurs avec ce composant, et si oui, profitez de cette fonctionnalité.

Une des implémentations de chien de garde les plus populaires que vous trouverez souvent est où le chien de garde est activé (ce qui est un bon début), mais aussi où le chien de garde peut être mis à zéro avec une minuterie périodique; L’activation du Timer est complètement isolée de toute situation qui se produit dans le programme. Le but de l’utilisation d’un chien de garde est d’aider à s’assurer que si une erreur se produit, le chien de garde ne soit pas mis à zéro, c’est-à-dire lorsque le travail est suspendu, le système est forcé d’effectuer une réinitialisation matérielle afin de récupérer. L’utilisation d’une minuterie indépendante de l’activité du système permet au chien de garde de rester à l’écart même lorsque le système a échoué.

Les développeurs de cartes mères embarquées doivent examiner attentivement et concevoir comment les tâches d’application sont intégrées dans les systèmes de chien de garde. Par exemple, une technique peut permettre à chaque tâche qui se déroule pendant une certaine période de temps d’indiquer qu’ils peuvent accomplir leurs tâches avec succès. Dans ce cas, le chien de garde n’est pas autorisé et est forcé de réinitialiser. Il existe également des techniques plus avancées, telles que l’utilisation d’un processeur de chien de garde externe, qui peut être utilisé pour surveiller les performances du processeur principal, et vice versa. Pour un système fiable, il est important d’avoir un système de surveillance solide.

Les ingénieurs qui ne sont pas habitués à travailler dans un environnement à ressources limitées peuvent essayer d’utiliser des fonctionnalités de leur langage de programmation qui leur permettent d’utiliser l’allocation de mémoire volatile. Après tout, il s’agit d’une technique couramment utilisée dans les systèmes de calculatrice, où la mémoire n’est allouée que lorsque cela est nécessaire. Par exemple, lors du développement en C, les ingénieurs peuvent préférer utiliser malloc pour allouer de l’espace sur le tas. Une opération est exécutée, et une fois terminée, la mémoire allouée peut être retournée en utilisant free pour une utilisation en heap.

Dans les systèmes à ressources limitées, cela peut être un désastre! Un des problèmes avec l’utilisation de l’allocation de mémoire volatile est que des techniques défectueuses ou incorrectes peuvent conduire à des fuites de mémoire ou à la fragmentation de la mémoire. Si ces problèmes surviennent, la plupart des systèmes embarqués n’ont pas les ressources ou les connaissances nécessaires pour surveiller le tas ou le gérer correctement. Et quand ils le font, que se passe-t-il si l’application fait une demande d’espace, mais aucun espace demandé n’est disponible?

Les problèmes liés à l’utilisation de l’allocation mémoire volatile sont complexes, et les traiter correctement peut être un cauchemar! Une autre approche consiste à simplifier l’allocation de mémoire directement et statiquement. Par exemple, créez simplement un tampon de 256 octets dans le programme, plutôt que de demander un tampon en mémoire de cette taille via malloc. Cette mémoire allouée peut être maintenue tout au long de la vie de l’application sans souci de tas ou de fragmentation de la mémoire.