Sureté de fonctionnement dans un système embarqué : les atouts d’une TMS570LC4357

Dans le cadre de nos activités logiciel embarqué, nous réalisons régulièrement pour nos clients des systèmes critiques basés sur des microcontrôleurs sur étagère. Ces systèmes sont utilisés dans des domaines aussi divers que l’avionique, le spatial, l’automotive… Les contraintes de criticité de plus en plus exigeantes mettent au-devant de la scène la sureté de fonctionnement.

Dans cette article, Cédric Landet, leader de la communauté d’experts « logiciel embarqué » de SII SUD-OUEST, titulaire d’un doctorat en conception de microprocesseurs pour les systèmes critiques, revient sur la mise en œuvre de la TMS570LC4357 et montre comment les structures matérielles ont été utilisées pour atteindre des objectifs élevés de sureté de fonctionnement.

Cet article commence par présenter les dispositifs matériels qui ont été utilisés, en terme de monitoring, de gestion des erreurs et évènements matériels ; puis il donne des éléments logiciels, fournis par le constructeur, qui facilitent et sécurisent l’utilisation de la puce. La conclusion donne un cadre d’utilisation

Vue générale du microcontrôleur

La TMS 570LC4357 est un microcontrôleur construit autour d’un ARM cortexR5F cadencé jusqu’à 300 MHz, avec un cache de données de 32 Ko, un cache d’instructions de 32 Ko. Il embarque 512 Ko de RAM en backend et 4Mo de Flash. Il dispose d’un bus EMIF pour un extension mémoire, plusieurs bus de communication (Ethernet, CAN, Flexray, I2C, SPI, UART, GPIO…) ainsi que des modules de calcul de CRC, de conversion analogique/numérique, des encodeurs de pulse (eQEP et ePWM) ainsi que de capture (eCAP).

Conçu pour des systèmes critiques, les mécanismes de protection dont il dispose permettent d’éviter, de corriger et de monitorer finement les pannes et erreurs qui pourraient subvenir dans un système critique piloté par ce microcontrôleur.

Mécanismes de protection hardware

Lockstep

Le CPU présent sur la carte comporte 2 cœurs. Afin d’augmenter la sureté, nous faisons exécuter le même code aux 2 cœurs. Un comparateur matériel (le CCM) compare les résultats en fin de pipeline. S’ils sont différents, une interruption est levée pour signaler le disfonctionnement du CPU. Ce mécanisme est appelé lockstep.

Protection mémoire

Toutes les mémoires sont protégées par des mécanismes d’ECC ou de parité. La MPU ne permet pas une définition des tailles au mot près, les plages d’adresses autorisées sont donc légèrement plus grandes que le besoin réel. Afin de prévenir tout saut dans une zone non protégée par la MPU mais ne contenant pas de données ou de code utile, ces zones sont remplies avec des mots ne correspondant à aucune instruction pour les segments exécutables et avec des valeurs NaN pour les autres.

Contrôler l’accès aux périphériques : NMPU et MPU et PCR

La Memory Protection Unit permet de contrôler les accès à différentes plages d’adresses en lecture, écriture et exécution, ainsi que leur caractère cachable. Elle est un élément essentiel pour assurer la ségrégation spatiale entre les tâches.

La System Memory Protection Unit (NMPU) permet de contrôler les accès en mode maitre au bus système. Le principe est le même que pour la MPU, mais elle ne gère pas de droits en exécution ni de caractère cachable vis-à-vis du CPU. Par contre elle permet de définir quel maitre a accès aux zones mémoire : le CPU, le DMA et l’EMAC. L’accès à chaque plage peut être contrôlé pour chacun des masters.

Les PCR sont les ports d’accès au bus d’interconnexion système. Ils sont 3 et chacun contrôle l’accès à un sous-ensemble de périphériques de la puce, tant pour les registres de configuration que pour la mémoire du périphérique. Ils en contrôlent l’accès pour chaque master, mais aussi l’activation et la désactivation.

La combinaison de ces 3 éléments donne un contrôle très fin des accès à chaque périphérique par les différents maitres présents sur la puce.

Gestion des erreurs et évènements : ESM, EPC et VIM

L’Error Signaling Module Collecte et reporte les erreurs levées par le microcontrôleur. Les 160 erreurs monitorées sont réparties par sévérité en 3 groupes qui peuvent lever des IRQ, Fast IRQ (FIQ) et/ou activer une broche externe. Dans tous les cas, un bit de statut peut être lu par le logiciel pour chaque erreur.

L’Error Profiling Controleur permet de tracer les erreurs d’ECC/parité du CPU, des RAM, et du bus d’interconnexion. Il garde la trace des adresses incriminées et signale les erreurs à l’ESM. Dans le cas d’erreurs qui peuvent être corrigées, ce signalement peut être soumis à un seuil.

Le Vectored Interupt Manager contrôle les 127 sources d’interruptions du microcontrôleur. Comme le CPU, il fonctionne en lockstep. La priorité et l’activation/masquage de chaque source d’interruption est programmable. Chaque source peut être associée à IRQ ou FIQ. De plus, le VIM permet d’associer les différentes sources à des ISR (Interupt Service Routine) différents ce qui rend la gestion des interruptions plus rapide et plus souple.

La combinaison de ces modules permet un contrôle fin et une réaction rapide et ciblée à tous les évènements du système, en particulier pour la gestion d’erreurs.

Software et outils

HalCoGen

HalCoGen est un outil de Texas-Instrument qui génère du code C et assembleur pour configurer la carte à partir d’une interface graphique. Le code généré dépend du compilateur qui sera utilisé. Lors de la création du projet, il est donc important de sélectionner celui-ci :

Voici un exemple : la configuration pour la mémoire flash.

La configuration ci-dessus dans l’interface graphique d’HalCoGen fera générer une routine d’initialisation pour la mémoire flash avec :

  • 0 pour adresse de base,
  • 3 wait-states,
  • les banques 0 et 1 actives,
  • la banque 7 en mode sleep (inactive).

Le code C généré est le suivant :

Si du code doit être ajouté, il doit l’être entre les balises

Ainsi il ne sera pas modifié si le code est régénéré à partir de l’outil.

Texas instruments safety library

Texas-Instruments fourni un document d’analyse et de recommandation sur les points à mettre en œuvre pour sécuriser au mieux l’utilisation de la carte ainsi qu’une implémentation en C de ces recommandations. Parmi celles-ci, on trouve :

Toutes les mémoires (flash, RAM, buffers SPI…) et les bus sont dotés soit de mécanismes de correction d’erreur (ECC), soit de mécanismes de détection d’erreur par parité. Il est recommandé d’activer ces mécanismes sur toutes les mémoires et bus utilisés. Cette activation nécessite une initialisation particulière des mémoires afin que les bits de contrôle soient initialisés. Pour ce faire, des mécanismes d’initialisation hardware sont fournis pour la plupart des mémoires. Une initialisation software semble possible, mais elle augmente inutilement la durée du boot de la puce. Ignorer cette phase d’initialisation conduit à une erreur d’ECC dès les premières lectures dans ces zones mémoires.

La relecture périodique des configurations en les comparant avec les configurations afin de s’assurer qu’elles n’ont pas changé. De tels changement peuvent se produire accidentellement par programmation, à cause d’une défaillance du matériel ou bien suite à des perturbations électromagnétiques liées à l’environnement de la puce. Ces rayonnements peuvent affecter aussi les mémoires et les bus, mais ils sont alors détectés et corrigés par les mécanismes de parité et d’ECC. Les registres de configuration n’étant pas protégés. Les pertes de configuration détectées peuvent alors être corrigées logiciellement ou les mesures conservatoires ad’hoc peuvent être prises.

La plupart des composants matériel de la puce fournissent des autotests qu’il est recommandé de jouer soit au démarrage, soit périodiquement pendant le fonctionnement du système. Parmi ceux-ci, on peut citer LBIST, PBIST…

PBIST

Le Programmable Built-In Self-Test est un module hardware qui permet de contrôler le bon fonctionnement des différentes mémoires de la puce. Les tests faits par le PBIST sont plus rapides et plus couvrants que ceux qu’on peut faire par logiciel. Les algorithmes utilisés (Marche13N, triple read slow read, triple read fast read) sont adaptés au différents types de mémoire de la puce.

LBIST

Logic Built-in Self-Test permet un autodiagnostic du CPU et des modules HET. Il couvre jusqu’à 96,41 % de la logique interne des modules testés.

La puce n’est pas utilisable pendant ces tests et un reset CPU survient à la fin de chacun d’eux.

Testabilité

Pour que le logiciel soit plus facile à tester, des routines de lecture et d’écriture des registres sont utilisées. Elles peuvent être bouchonnées pour les tests, ce qui permet de simuler des comportements difficiles à mettre en tests sur le matériel réel comme des pannes.

Dans la version finale, afin de ne pas impacter les performances, ces routines peuvent être inlinées.

Conclusion

La présence de mécanismes matériels qui permet un contrôle fin des accès, un monitoring optimal du fonctionnement et la gestion fine des pannes et anomalies accroit grandement la sureté de fonctionnement du système.

L’utilisation du lockstep permet un fonctionnement semblable à un modèle à 2 calculateurs dont l’un monitore le fonctionnement de l’autre, mais pour un encombrement et une consommation électrique bien moindre. Ceci peut être un bon compromis dans les domaines ou la place et la consommation sont des facteurs critiques comme le biomédical, le spatial ou l’avionique.

La présence d’HalCoGen et de la librairie safety fournie par Texas Instruments réduit beaucoup le « time to market » des produits et donne un niveau de confiance élevé dans le code produit. Cependant, ils ne sont pas utilisables dans les développements soumis à une norme comme la DO178. En effet, ils ne sont pas qualifiés, le code produit et la librairie fournie doivent donc être redéveloppés selon le process porté par la norme. Malgré cela, il peut être utilisé comme un prototype et industrialisé. Les temps de développement sont tout de même moins importants que lors d’un développement « from scratch »

Une amélioration possible de la part de TI serai par exemple qu’HalCoGen produise du code dans un langage plus orienté safety comme ADA ou RUST. De même pour la librairie Safety. Une telle évolution serait un pas vers des logiciels toujours plus surs.

Références

https://www.ti.com/product/TMS570LC4357#tech-docs

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0460c/CACCEFCJ.html

http://www.ti.com/tool/SAFETI_DIAG_LIB

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

quatre × 2 =