Auteur: Johnny Liu
Titre: PDG de Dowway Vehicle
Date: 24 juin 2026
Catégorie: Électronique automobile / Sécurité fonctionnelle / Micrologiciel embarqué
Table of Contents
FAQ rapide
Qu’est-ce que LBIST sur l’AURIX TC3xx ? Il s’agit d’un autotest matériel qui vérifie les portes logiques numériques des microcontrôleurs. Il utilise des chaînes de balayage internes, exécute des séquences de test pseudo-aléatoires et crée une signature unique pour vérifier l’absence de défauts structurels latents dans le matériel.
Pourquoi l’exécution de LBIST déclenche-t-elle une réinitialisation à chaud ? Le test de balayage perturbe et brouille l’état des circuits numériques. Une réinitialisation à chaud est nécessaire pour effacer ces états invalides et redémarrer le système dans un état normal et prévisible.
Où trouve-t-on la signature d’or pour ce test ? Il s’agit d’une valeur statique précalculée sur 32 bits. Vous trouverez la signature correspondant à votre nombre de motifs et à votre fréquence dans l’annexe relative à l’unité de contrôle système (SCU) du manuel d’utilisation de l’Infineon AURIX TC3xx.
Pourquoi ce guide est important (L’angle ISO 26262)
Dans la conception automobile critique pour la sécurité (ASIL-B à ASIL-D), il est impératif de détecter les défaillances matérielles aléatoires. Les défaillances latentes sont particulièrement dangereuses : elles restent invisibles en conduite normale, mais peuvent entraîner des problèmes de sécurité si une seconde défaillance survient.
L’autotest intégré logique (LBIST) est un mécanisme de sécurité matériel clé (SM:MCU:LBISTSur l’AURIX TC3xx, il cible la métrique de défaut latent (LFM). Grâce à la vérification des portes logiques du cœur numérique, un test LBIST réussi permet de contrôler le processeur, le bus et les contrôleurs de sécurité dès le démarrage. Ceci évite d’avoir à effectuer ultérieurement des vérifications logiques logicielles lentes et complexes.
Comparaison rapide des autotests pour startups
Pour une conception claire, ne confondez pas LBIST avec les autres tests intégrés à cette plateforme :
| Mécanisme de test | Ce que cela teste | Causes de la réinitialisation ? | Quand l’exécuter | Objectif principal |
| LBIST | Logique numérique interne | Oui (Réinitialisation à chaud) | Démarrage anticipé (Cold ORST / Réveil en veille) | Détecte les défauts structurels des portes pour LFM |
| MBIST | Mémoires SRAM et Flash | Non (Configurable) | Démarrage ou exécution | Détecte les défaillances des cellules mémoire et des lignes d’adresse |
| MONBIST | Moniteurs de tension PMS | Non | Démarrage précoce | Vérifie les chemins de secours du moniteur de tension |
| Vérification du firmware | Configurations des registres clés | Non | Post-réinitialisation / Exécution | Vérifie les registres et les empreintes du micrologiciel |
Comment fonctionne TC3xx LBIST dans le matériel
Chaînes de balayage et compression de signature
LBIST repose sur des tests de balayage structurel. Lors de la fabrication, les concepteurs de puces relient les bascules internes pour former des registres sériels appelés chaînes de balayage.
+---------------------------------------------------------------------------------+
| AURIX TC3xx SCU |
| |
| +-------------------+ Test Patterns +-------------------------------+ |
| | LFSR Engine |====================>| Internal Scan Chains | |
| | (Seed & Patterns) | | (Registers linked in series) | |
| +-------------------+ +-------------------------------+ |
| || |
| || Capture & Shift |
| \/ |
| +-------------------+ Final Signature +-------------------------------+ |
| | LBISTCTRL3 |<====================| MISR Compressor | |
| | (SIGNATURE) | | (Compresses output stream) | |
| +-------------------+ +-------------------------------+ |
+---------------------------------------------------------------------------------+
Le matériel suit un cycle propre et automatisé :
- Générer des modèles : Un registre à décalage à rétroaction linéaire (LFSR) crée des motifs de test pseudo-aléatoires à partir d’une valeur initiale (le Graine).
- Déplacement vers l’intérieur : Le contrôleur intègre ces modèles dans les chaînes de balayage internes.
- Phase de capture : Le système exécute une ou plusieurs horloges fonctionnelles. Les portes logiques traitent les signaux, et les bascules capturent le signal de sortie.
- Décalage et compression : Les données capturées sont transférées vers un registre de signature à entrées multiples (MISR), qui compresse le long flux de bits en une seule valeur. Signature 32 bits.
- Évaluation : Le logiciel compare cette signature à la valeur de référence pour confirmer le bon fonctionnement du matériel.
Ce que LBIST ne couvre pas
Gardez à l’esprit ces limites matérielles :
- Modules analogiques : Il ne teste pas les blocs analogiques PMS, EVR ou ADC.
- Contenu SRAM : Le test de mémoire est confié à MBIST. Comme LBIST brouille le matériel, il corrompt certains registres de l’unité de test de mémoire (MTU). Votre logiciel doit sauvegarder et restaurer les valeurs de ces registres.
Registres matériels à connaître
Configurer le test implique d’écrire dans les registres de l’unité de contrôle du système (SCU). Ces écritures sont protégées par Initialisation de sécurité (SEINIT) pour éviter toute exécution accidentelle.
LBISTCTRL0(Contrôle 0) : Contient les bits de déclenchement redondants (LBISTRAQetLBISTRAQRED), le bit de réinitialisation du contrôleur (LBISTRES), et le drapeau d’achèvement (LBISTDONE).LBISTCTRL1(Contrôle 1) : Configure le diviseur de fréquence de l’horloge de test (FRÉQUENCE), la disposition structurelle logique (CORPS), en modifiant les limitations de vitesse pour gérer les pics actuels (SPLITSH), et la graine LFSR (GRAINE).LBISTCTRL2(Contrôle 2) : Définit le nombre de modèles de test à exécuter (LONGUEUR).LBISTCTRL3(Contrôle 3) : Contient la signature de test finale de 32 bits (SIGNATURE).RSTSTAT(Réinitialiser l’état) : Surveille le déroulement du test via leLBTERM(le test s’est terminé normalement) etLBPRIST(le test n’a pas été interrompu par une réinitialisation à la mise sous tension) indicateurs.
La limite de réinitialisation à chaud
Le matériel force systématiquement une réinitialisation à chaud du système à la fin du test. Il s’agit d’un choix de conception matérielle délibéré.
Le test de balayage, en injectant des valeurs aléatoires dans la puce, invalide l’état interne des portes logiques. La réinitialisation à chaud efface tous les registres et redémarre le microcontrôleur à partir d’un état initial.
Bien que la SRAM conserve ses données lors d’une réinitialisation à chaud, cette dernière corrompt certaines parties de l’unité de transmission maximale (MTU). Le logiciel doit gérer cette transition avec précaution.
Conception d’une machine à états à réinitialisation croisée
Étant donné que le test déclenche une réinitialisation à chaud, vous devez diviser votre pilote logiciel en deux parties : le Phase de déclenchement de pré-réinitialisation et le Phase d’analyse post-réinitialisation.
+--------------------+
| Power On |
+--------------------+
|
v
+------------------------+
| Read RSTSTAT Register |
+------------------------+
|
Is Cold PORST or Standby Wakeup?
/ \
YES NO
/ \
v v
+------------------+ +--------------------+
| Check Persistent | | Skip LBIST & Boot |
| Context State | +--------------------+
+------------------+
/ | \
START RUN PASS/FAIL (Terminal States)
/ | \_______________________
v v \
[Trigger] [Analyze Signature] v
/ \ +--------------------+
Valid Invalid | Continue app boot |
/ \ +--------------------+
v v
Set PASS Retries < 3?
Clear Flags / \
App Boot YES NO
/ \
v v
Increment Set FAIL
Retry Counter Enter Safe State
Re-Trigger
1. Configuration du stockage persistant
Pour transmettre des informations d’état lors d’une réinitialisation à chaud, il faut un petit bloc de mémoire qui ne s’efface pas pendant la réinitialisation. Sur l’AURIX TC3xx, nous utilisons un segment dédié de la mémoire. DLMU SRAM configuré pour la conservation de l’alimentation en mode veille.
Voici comment configurer ce bloc de mémoire en C :
typedef enum {
LBIST_STATE_START = 0xA5A5A5A5U,
LBIST_STATE_RUN = 0x5A5A5A5AU,
LBIST_STATE_PASS = 0x3C3C3C3CU,
LBIST_STATE_FAIL = 0xC3C3C3C3U
} LbistState_t;
typedef struct {
LbistState_t state;
uint32_t retryCounter;
uint32_t callerIntentCheck; // Prevents wild triggers via a CRC
uint32_t lastFailureReason;
} LbistPersistedContext_t;
/* Map this struct to a non-initialized retention RAM area */
__attribute__((section(".bss.backup_ram_noinit")))
volatile LbistPersistedContext_t g_LbistContext;
2. Flux et étapes du logiciel
Phase A : Déclencheur de pré-réinitialisation
- Vérifier la cause de la réinitialisation : Lire
RSTSTAT. N’exécutez le test que si la réinitialisation était une Port froid ou un Réveil en veille. Ignorez cette option pour les réinitialisations déclenchées par logiciel. - Lire l’état actuel : Lire
g_LbistContext.état. Au démarrage à froid, initialisez ceci àLBIST_STATE_START. - Registres MTU de sauvegarde : Enregistrez les états critiques des registres MTU dans la mémoire RAM de rétention afin de pouvoir les restaurer après la réinitialisation.
- Configurer le matériel : Désactiver les interruptions. Déverrouiller la protection Safety Endinit (
DéverrouillerSEINIT()). Écrivez les configurations de la graine, de la fréquence et du nombre de motifs àLBISTCTRL1etLBISTCTRL2. - Vérification de l’intention d’écriture : Calculez le CRC de la configuration et écrivez-le dans
g_LbistContext.callerIntentCheck. Cela empêche des bogues logiciels importants de déclencher accidentellement le test. - Définir l’état sur EXÉCUTER : Écrire
LBIST_STATE_RUNàg_LbistContext.état. - Déclencheur redondant : Écrire
1à tous les deuxLBISTCTRL0.LBISTREQetLBISTCTRL0.LBISTREQREDau cours du même cycle d’horloge. - Verrouiller le processeur : Entrez dans une boucle d’assemblage infinie (
tant que(1);) et attendez que la réinitialisation matérielle s’effectue.
Phase B : Analyse post-réinitialisation
- Entrée du coffre : Le microcontrôleur démarre. Le logiciel lit
RSTSTATet détecte la réinitialisation à chaud. - Vérifier l’état : Le logiciel lit
g_LbistContext.étatet constate qu’il est réglé surLBIST_STATE_RUN. - Vérifier l’intention : Calculez le CRC et comparez-le à
g_LbistContext.callerIntentCheck. Si les valeurs ne correspondent pas, signalez une erreur de corruption de données et ignorez le test afin d’éviter les boucles de démarrage. - Vérifier les drapeaux : Confirmez cela
RSTSTAT.LBTERM == 1,RSTSTAT.LBPORST == 0, etLBISTCTRL0.LBISTDONE == 1. - Vérifier la signature : Lisez la signature de
LBISTCTRL3.SIGNATUREet comparez-la à la valeur d’or.- Si cela correspond : Définir l’état à
LBIST_STATE_PASS. Réinitialisez le contrôleur LBIST viaLBISTRES. Effacer les indicateurs de réinitialisation à froid dansRSTSTATPour éviter de relancer le test lors des redémarrages à chaud suivants, restaurez les registres MTU et redémarrez l’application. - En cas de non-concordance : Exécutez la logique de nouvelle tentative.
- Si cela correspond : Définir l’état à
3. Implémentation en C de production
Voici une implémentation propre et prête pour la production du pilote :
#include "tc3xx_scu_registers.h"
#define GOLDEN_LBIST_SIGNATURE 0x2E4A9F18U // Golden signature from User Manual
#define MAX_LBIST_RETRIES 3U
void Handle_Fatal_Safety_Fault(uint32_t reason) {
// Notify the SMU and transition the ECU to a safe state
while (1);
}
void Execute_LBIST_Evaluation_Sequence(void) {
uint32_t rststat = SCU_RSTSTAT.U;
// Check if the reset source is Cold PORST or Standby Exit
if ((rststat & SCU_RSTSTAT_COLD_RESET_MASK) != 0U) {
// Safe initialization check for retention RAM
if (g_LbistContext.state == 0xFFFFFFFFU) {
g_LbistContext.state = LBIST_STATE_START;
g_LbistContext.retryCounter = 0U;
}
switch (g_LbistContext.state) {
case LBIST_STATE_START: {
Backup_MTU_Configuration();
// Unlock Safety Endinit and write configurations
Unlock_Safety_Endinit();
SCU_LBISTCTRL1.U = (0x1U << 16) | (0x0U << 8) | 0x5A5A5A5AU; // SPLITSH, BODY, SEED
SCU_LBISTCTRL2.U = 0x000003E8U; // LENGTH (1000 Patterns)
Lock_Safety_Endinit();
// Protect against wild software jumps
g_LbistContext.callerIntentCheck = Calculate_CRC32((uint8_t*)&g_LbistContext, sizeof(g_LbistContext) - 8);
g_LbistContext.state = LBIST_STATE_RUN;
// Redundant trigger write
Unlock_Safety_Endinit();
SCU_LBISTCTRL0.U |= (1U << SCU_LBISTCTRL0_LBISTREQ_POS) | (1U << SCU_LBISTCTRL0_LBISTREQRED_POS);
Lock_Safety_Endinit();
// Wait for hardware reset
while (1) {
__nop();
}
break;
}
case LBIST_STATE_RUN: {
// Verify caller intent CRC
uint32_t calc_crc = Calculate_CRC32((uint8_t*)&g_LbistContext, sizeof(g_LbistContext) - 8);
if (calc_crc != g_LbistContext.callerIntentCheck) {
g_LbistContext.state = LBIST_STATE_FAIL;
Handle_Fatal_Safety_Fault(0xFEED0001U);
return;
}
// Verify hardware flags
uint32_t test_done = (SCU_LBISTCTRL0.U & (1U << SCU_LBISTCTRL0_LBISTDONE_POS));
uint32_t normal_term = (rststat & (1U << SCU_RSTSTAT_LBTERM_POS));
uint32_t power_interrupted = (rststat & (1U << SCU_RSTSTAT_LBPORST_POS));
if ((test_done != 0U) && (normal_term != 0U) && (power_interrupted == 0U)) {
uint32_t signature = SCU_LBISTCTRL3.U;
if (signature == GOLDEN_LBIST_SIGNATURE) {
g_LbistContext.state = LBIST_STATE_PASS;
// Reset the controller and clear reset flags
Unlock_Safety_Endinit();
SCU_LBISTCTRL0.U |= (1U << SCU_LBISTCTRL0_LBISTRES_POS);
SCU_RSTCON.U |= SCU_RSTCON_CLEAR_COLD_FLAGS_MASK;
Lock_Safety_Endinit();
Restore_MTU_Configuration();
return; // Continue to main boot
}
}
// Run retry strategy
g_LbistContext.retryCounter++;
if (g_LbistContext.retryCounter >= MAX_LBIST_RETRIES) {
g_LbistContext.state = LBIST_STATE_FAIL;
Handle_Fatal_Safety_Fault(0xFEED0002U); // Hardware error
} else {
Unlock_Safety_Endinit();
SCU_LBISTCTRL0.U |= (1U << SCU_LBISTCTRL0_LBISTRES_POS);
Lock_Safety_Endinit();
g_LbistContext.state = LBIST_STATE_START;
Execute_LBIST_Evaluation_Sequence(); // Re-run
}
break;
}
case LBIST_STATE_PASS:
// Passed; continue standard boot
break;
case LBIST_STATE_FAIL:
default:
Handle_Fatal_Safety_Fault(0xFEED0003U);
break;
}
}
}
Pièges pratiques de l’ingénierie
1. Paramètres d’alimentation SRAM en veille
En mode veille, le système peut couper l’alimentation de la mémoire RAM de rétention. Dans ce cas, la variable d’état est réinitialisée et le microcontrôleur effectue un nouveau test à chaque réveil, ce qui provoque une boucle de démarrage infinie.
- Comment résoudre ce problème : Configurer le
STBYRAMSELetPROCONRAM.LMUINSELLes registres du SCU permettent de forcer l’alimentation des secteurs de la RAM LMU en mode veille. Assurez-vous également que votre script d’édition de liens inclut les éléments suivants :g_LbistContextvariable dans un.noinitsection afin que votre code d’initialisation C de démarrage ne l’efface pas au réveil.
2. Pièges liés à l’accès précoce aux données
La lecture de secteurs SRAM non initialisés juste après un démarrage à froid peut provoquer une Piège d’accès aux données sur certaines étapes de fabrication des puces AURIX en raison de bits ECC ou de parité défectueux.
- Comment résoudre ce problème : Votre gestionnaire d’interruption doit vérifier si l’exception s’est produite dans l’espace mémoire de rétention lors du démarrage initial. Si c’est le cas, écrivez des données factices pour initialiser les bits ECC, effacez l’état de l’interruption et reprenez l’exécution au lieu d’arrêter le processeur.
3. Coordination des bottes multicœurs
AURIX est une plateforme multicœur. Si tous les cœurs démarrent simultanément lors des cycles de réinitialisation à chaud, cela peut perturber le fonctionnement de votre machine à états.
- Comment résoudre ce problème : Configurez une séquence de démarrage maître-esclave. Maintenez tous les cœurs auxiliaires à l’arrêt (via les connecteurs du mode de démarrage ou les commandes SCU) pendant le démarrage. Autorisez uniquement Noyau 0 pour exécuter la machine à états LBIST. Une fois que le cœur 0 a vérifié le test et écrit
LBIST_STATE_PASS, il peut libérer les autres cœurs pour démarrer.
Essais et validation en laboratoire
Pour vérifier votre conception à l’aide d’évaluateurs de sécurité fonctionnelle, vous pouvez utiliser les méthodes de test suivantes :
- Vérifiez le Chemin d’Or : Utilisez votre débogueur pour confirmer que la machine à états termine correctement la transition : $$\text{START} \longrightarrow \text{Warm Reset} \longrightarrow \text{RUN} \longrightarrow \text{PASS}$$
- Erreurs d’injection de données : Arrêtez le processeur pendant la
COMMENCERphase, corrompre manuellement leg_LbistContext.callerIntentCheckChargez le CRC en mémoire et reprenez l’exécution. Vérifiez que le logiciel détecte l’erreur et passe à un état sûr sans exécuter le test. - Échecs d’injection de signature : Modifiez légèrement votre configuration de test (par exemple, en modifiant le nombre de motifs dans
LBISTCTRL2Cela modifiera la signature. Vérifiez que :- Le code tente d’exécuter le test jusqu’à 3 fois.
- Le microcontrôleur passe en mode sécurisé après 3 tentatives infructueuses.
Conclusion
L’exécution de LBIST sur l’AURIX TC3xx constitue une méthode très fiable pour satisfaire aux exigences de diagnostic de la norme ISO 26262 pour la logique numérique. Grâce à l’utilisation de chaînes de balayage internes et de séquences pseudo-aléatoires, le matériel localise avec précision les défaillances structurelles des portes logiques.
Pour garantir la sécurité de ce processus, vous devez créer une machine à états propre et à réinitialisation croisée. Concentrez-vous sur la protection de vos configurations de mémoire RAM de rétention, la gestion des interruptions au démarrage, la coordination de vos cœurs de processeur et la définition d’une limite de tentatives robuste. Ceci garantit la sécurité et la fiabilité de votre autotest.