AURIX TC3xx LBIST: Schritt-für-Schritt-Sicherheitsanleitung

Autor: Johnny Liu

Titel: CEO bei Dowway Vehicle

Datum: 24. Juni 2026

Kategorie: Automobilelektronik / Funktionale Sicherheit / Eingebettete Firmware

Häufig gestellte Fragen

Was ist LBIST auf dem AURIX TC3xx? Es handelt sich um einen Hardware-Selbsttest, der die digitalen Logikgatter des Mikrocontrollers überprüft. Er nutzt interne Scan-Ketten, führt pseudozufällige Testmuster aus und erzeugt eine eindeutige Signatur, um zu bestätigen, dass die Hardware keine latenten Strukturfehler aufweist.

Warum löst die Ausführung von LBIST einen Warmstart aus? Der Scan-Test überschreibt und verändert den Zustand der digitalen Schaltkreise. Ein Warmstart ist erforderlich, um diese ungültigen Zustände zu beseitigen und das System in einem sauberen, vorhersehbaren Zustand neu zu starten.

Wo findet man die goldene Unterschrift für den Test? Es handelt sich um einen statischen, vorab berechneten 32-Bit-Wert. Die Signatur für Ihre spezifische Musteranzahl und Frequenz finden Sie im Anhang „System Control Unit (SCU)“ des Infineon AURIX TC3xx Benutzerhandbuchs.

Warum dieser Leitfaden wichtig ist (Der ISO 26262-Aspekt)

Bei sicherheitskritischen Fahrzeugkonstruktionen (ASIL-B bis ASIL-D) müssen zufällige Hardwarefehler erkannt werden. Latente Fehler sind besonders gefährlich. Diese Fehler bleiben während der normalen Fahrt unentdeckt, können aber bei Auftreten eines zweiten Fehlers zu Sicherheitsverstößen führen.

Der integrierte Logik-Selbsttest (LBIST) ist ein wichtiger Hardware-Sicherheitsmechanismus (SM:MCU:LBIST) auf dem AURIX TC3xx. Es zielt auf die Latent Fault Metric (LFM) ab. Da es die digitalen Kerngatter prüft, ermöglicht ein erfolgreicher LBIST-Lauf die Überprüfung von CPU, Bus und Sicherheitssteuerungen beim Systemstart. Dadurch entfällt die Notwendigkeit langsamer, komplexer softwarebasierter Logikprüfungen im weiteren Verlauf.

Schneller Vergleich von Startup-Selbsttests

Um Ihr Design übersichtlich zu halten, verwechseln Sie LBIST nicht mit anderen integrierten Tests auf dieser Plattform:

Testmechanismus	Was es testet	Ursachen für einen Reset?	Wann sollte man es ausführen?	Hauptziel
LBIST	Interne digitale Logik	Ja (Warmstart)	Früher Bootvorgang (Kaltstart / Standby-Aufwachen)	Erkennt strukturelle Torfehler für LFM
MBIST	SRAM- und Flash-Speicher	NEIN (Konfigurierbar)	Start- oder Laufzeit	Findet Speicherzellen- und Adressleitungsfehler
MONBIST	PMS-Spannungsmonitore	NEIN	Früher Boot	Überprüft die Backup-Pfade des Spannungsmonitors
FwCheck	Schlüsselregisterkonfigurationen	NEIN	Nach dem Reset / Laufzeit	Prüft Register und Firmware-Footprints

Wie TC3xx LBIST in Hardware funktioniert

Scan-Ketten und Signaturkomprimierung

LBIST setzt auf strukturelle Scan-Tests. Während der Fertigung verbinden die Chipdesigner die internen Flip-Flops zu seriellen Registern, sogenannten Scan-Ketten.

+---------------------------------------------------------------------------------+
|                                 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)    |   |
|   +-------------------+                     +-------------------------------+   |
+---------------------------------------------------------------------------------+

Die Hardware durchläuft einen sauberen, automatisierten Zyklus:

Mustergenerierung: Ein lineares Rückkopplungsschieberegister (LFSR) erzeugt pseudozufällige Testmuster basierend auf einem Startwert (dem Samen).
Einzug: Der Controller überträgt diese Muster in die internen Scan-Ketten.
Erfassungsphase: Das System verwendet einen oder mehrere Funktionstaktgeber. Die Logikgatter verarbeiten die Signalmuster, und die Flipflops erfassen das Ausgangssignal.
Ausblenden & Komprimieren: Die erfassten Daten werden in ein Multiple Input Signature Register (MISR) ausgegeben, welches den langen Bitstrom in einen einzigen Wert komprimiert. 32-Bit-SignaturDie
Bewertung: Die Software vergleicht diese Signatur mit dem Referenzwert, um zu bestätigen, dass die Hardware in einwandfreiem Zustand ist.

Was LBIST nicht abdeckt

Beachten Sie bitte folgende Hardwarebeschränkungen:

Analogmodule: Es testet nicht die analogen Blöcke PMS, EVR oder ADC.
SRAM-Inhalt: Die Speicherprüfung erfolgt durch MBIST. Da MBIST die Hardware verschlüsselt, werden bestimmte Register der Speichertesteinheit (MTU) beschädigt. Ihre Software muss diese Registerwerte sichern und wiederherstellen können.

Wichtige Hardware-Register

Die Konfiguration des Tests erfordert das Schreiben in Register der System Control Unit (SCU). Diese Schreibvorgänge sind geschützt durch Sicherheitsendpunkt (SEINIT) um eine versehentliche Ausführung zu verhindern.

LBISTCTRL0 (Steuerung 0): Enthält die redundanten Triggerbits (LBISTREQ Und LBISTREERFORDERT), das Controller-Reset-Bit (LBISTRES), und das Abschlussflag (LBISTDONE).
LBISTCTRL1 (Kontrolle 1): Legt den Testtaktfrequenzteiler fest (FREQU), die logische Struktur (KÖRPER), Anpassung der Geschwindigkeitsbegrenzungen zur Bewältigung von Stromspitzen (SPLITSH), und der LFSR-Samen (SAMEN).
LBISTCTRL2 (Kontrolle 2): Legt die Anzahl der auszuführenden Testmuster fest (LÄNGE).
LBISTCTRL3 (Kontrolle 3): Enthält die endgültige 32-Bit-Testsignatur (UNTERSCHRIFT).
RSTSTAT (Status zurücksetzen): Überwacht, wie der Test über die LBTERM (Test wurde normal beendet) und LBPORST (Test wurde nicht durch einen Neustart abgebrochen) Flags.

Die Warm-Reset-Grenze

Die Hardware erzwingt nach Abschluss des Tests stets einen System-Warmreset. Dies ist eine bewusste Designentscheidung.

Da der Scan-Test zufällige Werte durch den Chip leitet, werden die internen Zustände der Logikgatter ungültig. Der Warm-Reset leert alle Register und startet den Mikrocontroller in einem sauberen Zustand.

Obwohl der SRAM seine Daten nach einem Warm-Reset beibehält, werden durch den Reset Teile der MTU beschädigt. Die Software muss diesen Übergang sorgfältig handhaben.

Entwurf eines Cross-Reset-Zustandsautomaten

Da der Test einen Warmstart auslöst, müssen Sie Ihren Softwaretreiber in zwei Teile aufteilen: den Vor-Reset-Triggerphase und die Analysephase nach dem ResetDie

                    +--------------------+
                    |     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. Einrichten des permanenten Speichers

Um Statusinformationen während eines Warm-Resets zu übermitteln, benötigen Sie einen kleinen Speicherblock, der beim Reset nicht gelöscht wird. Beim AURIX TC3xx verwenden wir dafür ein dediziertes Segment des DLMU SRAM Konfiguriert für Energieerhaltung im Standby-Modus.

So können Sie diesen Speicherblock in C einrichten:

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. Softwareablauf und Schritte

Phase A: Vorreset-Trigger

Grund für Zurücksetzung prüfen: Lesen RSTSTAT. Führe den Test nur aus, wenn der Reset ein Kalte Post oder ein Standby-Aufwachen. Bei softwaregesteuerten Resets ist dies nicht erforderlich.
Lesen Sie den aktuellen Status: Lesen g_LbistContext.state. Beim Kaltstart initialisieren Sie dies auf LBIST_STATE_STARTDie
MTU-Register sichern: Speichern Sie alle kritischen MTU-Registerzustände im Aufbewahrungs-RAM, damit Sie sie nach dem Reset wiederherstellen können.
Hardware konfigurieren: Interrupts deaktivieren. Den Sicherheitsendit-Schutz aufheben (UnlockSEINIT()Schreiben Sie die Konfigurationen für Startwert, Frequenz und Musteranzahl auf LBISTCTRL1 Und LBISTCTRL2Die
Schreibabsichtsprüfung: Berechne eine CRC-Prüfsumme der Konfiguration und schreibe sie in g_LbistContext.callerIntentCheck. Dadurch wird verhindert, dass schwerwiegende Softwarefehler den Test versehentlich auslösen.
Status auf AUSFÜHREN setzen: Schreiben LBIST_STATE_RUN Zu g_LbistContext.stateDie
Redundanter Auslöser: Schreiben 1 beiden LBISTCTRL0.LBISTREQ Und LBISTCTRL0.LBISTREQRED im selben Taktzyklus.
CPU sperren: Eine Endlosschleife im Assembler-Modus wird ausgelöst (while(1);) und warten Sie, bis der Hardware-Reset erfolgt.

Phase B: Analyse nach dem Reset

Bootvorgang: Der Mikrocontroller startet. Die Software liest aus RSTSTAT und erkennt den Warm-Reset.
Status prüfen: Die Software liest g_LbistContext.state und stellt fest, dass es auf eingestellt ist LBIST_STATE_RUNDie
Absicht überprüfen: Berechnen Sie die CRC und vergleichen Sie sie mit g_LbistContext.callerIntentCheck. Wenn sie nicht übereinstimmen, wird ein Datenbeschädigungsfehler gemeldet und der Test übersprungen, um Boot-Schleifen zu vermeiden.
Prüfflaggen: Bestätigen Sie, dass RSTSTAT.LBTERM == 1, RSTSTAT.LBPORST == 0, Und LBISTCTRL0.LBISTDONE == 1Die
Unterschrift überprüfen: Lesen Sie die Unterschrift von LBISTCTRL3.SIGNATURE und vergleiche es mit dem Goldwert.
- Wenn es übereinstimmt: Stellen Sie den Status auf LBIST_STATE_PASS. Setzen Sie den LBIST-Controller zurück über LBISTRES. Löschen Sie die Kaltstart-Flags in RSTSTAT Um zu verhindern, dass der Test bei nachfolgenden Neustarts erneut ausgeführt wird, stellen Sie die MTU-Register wieder her und starten Sie die Anwendung neu.
- Falls es nicht übereinstimmt: Führe die Wiederholungslogik aus.

3. Implementierung der Produktionsumgebung C

Hier ist eine saubere, produktionsreife Implementierung des Treibers:

#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;
        }
    }
}

Praktische Fallstricke im Ingenieurwesen

1. Standby-SRAM-Energieeinstellungen

Im Standby-Modus kann das System die Stromzufuhr zum Retention-RAM unterbrechen. In diesem Fall wird die Zustandsvariable zurückgesetzt, und der Mikrocontroller führt bei jedem Aufwachen einen erneuten Test durch, was zu einer Endlosschleife beim Booten führt.

So beheben Sie das Problem: Konfigurieren Sie die STBYRAMSEL Und PROCONRAM.LMUINSEL Register im SCU, um die Stromversorgung der LMU-RAM-Sektoren im Standby-Modus aufrechtzuerhalten. Stellen Sie außerdem sicher, dass Ihr Linker-Skript die folgenden Einträge enthält: g_LbistContext Variable in einem .noinit Abschnitt, damit Ihr C-Initialisierungscode beim Start nicht beim Aufwachen gelöscht wird.

2. Fallen beim frühen Datenzugriff

Das Lesen nicht initialisierter SRAM-Sektoren direkt nach einem Kaltstart kann zu einem Fehler führen. Datenzugriffsfalle bei einigen AURIX-Siliziumschritten aufgrund fehlerhafter ECC- oder Paritätsbits.

So beheben Sie das Problem: Ihr Trap-Handler muss prüfen, ob die Ausnahme während des frühen Systemstarts im Retention-Speicherbereich aufgetreten ist. Falls ja, schreiben Sie Dummy-Daten, um die ECC-Bits zu initialisieren, löschen Sie den Trap-Status und setzen Sie die Ausführung fort, anstatt die CPU anzuhalten.

3. Multi-Core-Boot-Koordination

AURIX ist eine Mehrkernplattform. Wenn während der Warmstartzyklen alle Kerne gleichzeitig hochfahren, kann dies zu Störungen in der Zustandsmaschine führen.

So beheben Sie das Problem: Richten Sie eine Master-Slave-Bootsequenz ein. Halten Sie alle Hilfskerne während des Startvorgangs im Haltzustand (mittels Boot-Modus-Headern oder SCU-Steuerung). Erlauben Sie nur Kern 0 um die LBIST-Zustandsmaschine auszuführen. Sobald Kern 0 den Test verifiziert und geschrieben hat, LBIST_STATE_PASSDadurch können die anderen Kerne zum Booten freigegeben werden.

Labortests und Validierung

Um Ihr Design für die Gutachter der funktionalen Sicherheit zu verifizieren, können Sie folgende Testmethoden anwenden:

Den Goldenen Pfad überprüfen: Verwenden Sie Ihren Debugger, um zu bestätigen, dass die Zustandsmaschine den Übergang erfolgreich abgeschlossen hat: $$\text{START} \longrightarrow \text{Warm Reset} \longrightarrow \text{RUN} \longrightarrow \text{PASS}$$
Fehler beim Einfügen von Daten: Halten Sie die CPU während des START Phase, manuell beschädigen g_LbistContext.callerIntentCheck CRC-Prüfsumme im Speicher prüfen und fortfahren. Sicherstellen, dass die Software den Fehler erkennt und in den sicheren Zustand wechselt, ohne den Test erneut auszuführen.
Fehler beim Einfügen der Signatur: Ändern Sie Ihre Testkonfiguration geringfügig (z. B. ändern Sie die Anzahl der Muster in LBISTCTRL2Dadurch wird die Signatur verändert. Überprüfen Sie Folgendes:
1. Der Code versucht, den Test bis zu 3 Mal auszuführen.
2. Die MCU wechselt beim dritten Fehlversuch in den sicheren Zustand.

Zusammenfassung

Die Ausführung von LBIST auf dem AURIX TC3xx ist eine äußerst zuverlässige Methode, um die Diagnoseanforderungen der ISO 26262 für digitale Logik zu erfüllen. Mithilfe interner Scan-Ketten und pseudozufälliger Muster lokalisiert die Hardware strukturelle Gatterfehler präzise.

Für einen sicheren Betrieb ist eine saubere, zustandsbasierte Zustandsmaschine mit Cross-Reset erforderlich. Achten Sie dabei auf den Schutz Ihrer RAM-Konfigurationen, die korrekte Handhabung von Startfehlern, die optimale Nutzung Ihrer CPU-Kerne und ein solides Wiederholungslimit. So gewährleisten Sie einen sicheren und zuverlässigen Selbsttest.

Dowway Vehicle