AURIX TC3xx LBIST: Guía de seguridad paso a paso

Autor: Johnny Liu

Título: Director ejecutivo de Dowway Vehicle

Fecha: 24 de junio de 2026

Categoría: Electrónica automotriz / Seguridad funcional / Firmware integrado

Preguntas frecuentes rápidas

¿Qué es LBIST en el AURIX TC3xx? Se trata de una autocomprobación de hardware que verifica las compuertas lógicas digitales de los microcontroladores. Utiliza cadenas de escaneo internas, ejecuta patrones de prueba pseudoaleatorios y crea una firma única para verificar que el hardware no contenga fallas estructurales latentes.

¿Por qué la ejecución de LBIST provoca un reinicio en caliente? La prueba de escaneo sobrescribe y altera el estado de los circuitos digitales. Es necesario un reinicio en caliente para borrar estos estados no válidos y reiniciar el sistema en un estado limpio y predecible.

¿Dónde se encuentra la firma dorada para la prueba? Se trata de un valor estático precalculado de 32 bits. Puede encontrar la firma correspondiente al número de patrones y la frecuencia específicos en el apéndice de la Unidad de Control del Sistema (SCU) del Manual del Usuario de Infineon AURIX TC3xx.

Por qué esta guía es importante (El enfoque de la norma ISO 26262)

En los diseños automotrices críticos para la seguridad (ASIL-B a ASIL-D), debemos detectar fallas aleatorias de hardware. Las fallas latentes son especialmente peligrosas. Se trata de fallas que permanecen ocultas durante la conducción normal, pero que pueden provocar violaciones de seguridad si se produce una segunda falla.

La prueba de autodiagnóstico integrada de lógica (LBIST) es un mecanismo clave de seguridad del hardware (SM:MCU:LBIST) en el AURIX TC3xx. Se centra en la Métrica de Fallos Latentes (LFM). Dado que comprueba las compuertas del núcleo digital, una ejecución exitosa de LBIST nos permite verificar la CPU, el bus y los controladores de seguridad durante el arranque. Esto elimina la necesidad de realizar comprobaciones lógicas por software lentas y complejas posteriormente.

Comparación rápida de autoevaluaciones para startups

Para mantener un diseño limpio, no confunda LBIST con otras pruebas integradas en esta plataforma:

Mecanismo de prueba	Qué evalúa	¿Causas Reiniciadas?	Cuándo ejecutarlo	Objetivo principal
LBIST	Lógica digital interna	Sí (Reinicio en caliente)	Arranque anticipado (PORST frío / Activación en modo de espera)	Detecta fallos estructurales en las compuertas para LFM
MBIST	Memorias SRAM y Flash	No (Configurable)	Inicio o tiempo de ejecución	Detecta fallos en las celdas de memoria y en las líneas de dirección.
MONBISTA	Monitores de voltaje PMS	No	Arranque temprano	Verifica las rutas de respaldo del monitor de voltaje.
FwCheck	Configuraciones de registro de claves	No	Tiempo de ejecución/posterior al reinicio	Comprueba el registro y la huella del firmware.

Cómo funciona TC3xx LBIST en hardware

Cadenas de escaneo y compresión de firmas

LBIST se basa en pruebas de escaneo estructural. Durante la fabricación, los diseñadores de chips conectan los biestables internos para formar registros en serie llamados cadenas de escaneo.

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

El hardware sigue un ciclo limpio y automatizado:

Generación de patrones: Un registro de desplazamiento con retroalimentación lineal (LFSR) crea patrones de prueba pseudoaleatorios basados en un valor inicial (el Semilla).
Cambio de entrada: El controlador traslada estos patrones a las cadenas de escaneo internas.
Fase de captura: El sistema utiliza uno o más relojes funcionales. Las compuertas lógicas procesan los patrones y los biestables capturan la salida.
Desplazamiento y compresión: Los datos capturados se envían a un Registro de Firma de Entrada Múltiple (MISR), que comprime el largo flujo de bits en uno solo. firma de 32 bits.
Evaluación: El software compara esta firma con el valor de referencia para confirmar que el hardware está en buen estado.

Lo que LBIST no cubre

Tenga en cuenta estas limitaciones de hardware:

Módulos analógicos: No prueba los bloques analógicos PMS, EVR ni ADC.
Contenido de la SRAM: Las pruebas de memoria las realiza MBIST. Dado que LBIST altera el hardware, corrompe ciertos registros de la Unidad de Prueba de Memoria (MTU). Su software debe realizar copias de seguridad y restaurar estos valores de registro.

Registros de hardware que debe conocer

Configurar la prueba implica escribir en los registros de la Unidad de Control del Sistema (SCU). Estas escrituras están protegidas por Seguridad Finit (SEINIT) para evitar una ejecución accidental.

LBISTCTRL0 (Control 0): Contiene los bits de activación redundantes (LBISTREQ y LBISTREQUISITO), el bit de reinicio del controlador (LBISTRES), y el indicador de finalización (LBISTDONE).
LBISTCTRL1 (Control 1): Configura el divisor de frecuencia del reloj de prueba (FRECUENCIA), la disposición estructural lógica (CUERPO), modificando los límites de velocidad para gestionar los picos de corriente (SPLITSH), y la semilla LFSR (SEMILLA).
LBISTCTRL2 (Control 2): Establece el número de patrones de prueba a ejecutar (LONGITUD).
LBISTCTRL3 (Control 3): Contiene la firma de prueba final de 32 bits (FIRMA).
RSTSTAT (Estado de restablecimiento): Supervisa cómo terminó la prueba a través de la LBTERM (la prueba finalizó con normalidad) y LBPORST (La prueba no se interrumpió mediante un reinicio al encender el equipo) indicadores.

El límite del reinicio en caliente

El hardware siempre fuerza un reinicio en caliente del sistema cuando finaliza la prueba. Esta es una decisión de diseño deliberada del hardware.

Debido a que la prueba de escaneo fuerza el paso de valores aleatorios a través del chip, los estados internos de las compuertas lógicas se invalidan. El reinicio en caliente borra todos los registros y arranca el microcontrolador desde un estado limpio.

Aunque la SRAM conserva sus datos tras un reinicio en caliente, este reinicio corrompe partes de la MTU. El software debe gestionar esta transición con cuidado.

Diseño de una máquina de estados con reinicio cruzado

Debido a que la prueba activa un reinicio en caliente, debe dividir su controlador de software en dos partes: Fase de activación de pre-reinicio y el Fase de análisis posterior al reinicio.

                    +--------------------+
                    |     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. Configuración del almacenamiento persistente

Para transmitir información de estado a través de un reinicio en caliente, se necesita un pequeño bloque de memoria que no se borre durante el reinicio. En el AURIX TC3xx, utilizamos un segmento dedicado de la Memoria SRAM DLMU Configurado para retención de energía en modo de espera.

Así es como puedes configurar este bloque de memoria 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. Flujo y pasos del software

Fase A: Disparador de pre-reinicio

Comprueba la causa del reinicio: Leer RSTSTAT. Ejecute la prueba únicamente si el reinicio fue un Frío PORST o un Activación en modo de espera. Omítalo para los reinicios activados por software.
Lea el estado actual: Leer g_LibistContext.estado. En el arranque en frío, inicialice esto para LBIST_STATE_START.
Registros MTU de respaldo: Guarda cualquier estado crítico del registro MTU en la memoria RAM de retención para poder restaurarlo después del reinicio.
Configurar el hardware: Deshabilitar interrupciones. Desbloquear la protección Safety Endinit (DesbloquearSEINIT()). Escriba las configuraciones de semilla, frecuencia y recuento de patrones en LBISTCTRL1 y LBISTCTRL2.
Escribir verificación de intención: Calcula un CRC de la configuración y escríbelo en g_LibistContext.callerIntentCheck. Esto evita que errores de software inesperados activen la prueba accidentalmente.
Establecer el estado en EJECUCIÓN: Escribir LBIST_STATE_RUN a g_LibistContext.estado.
Disparador redundante: Escribir 1 a ambos LBISTCTRL0.LBISTREQ y LBISTCTRL0.LBISTREQRED en el mismo ciclo de reloj.
Bloquear CPU: Ingrese un bucle de ensamblaje infinito (mientras(1);) y espere a que se produzca el reinicio del hardware.

Fase B: Análisis posterior al reinicio

Entrada de arranque: El MCU arranca. El software lee RSTSTAT y detecta el reinicio en caliente.
Verificar estado: El software lee g_LibistContext.estado y lo encuentra configurado en LBIST_STATE_RUN.
Verificar intención: Calcula el CRC y compáralo con g_LibistContext.callerIntentCheck. Si no coinciden, se detectará un error de corrupción de datos y se omitirá la prueba para evitar bucles de arranque.
Comprobar banderas: Confirma que RSTSTAT.LBTERM == 1, RSTSTAT.LBPORST == 0, y LBISTCTRL0.LBISTDONE == 1.
Verificar firma: Lea la firma de LBISTCTRL3.FIRMA y compararlo con el valor áureo.
- Si coincide: Establecer el estado en LBIST_STATE_PASS. Reinicie el controlador LBIST mediante LBISTRES. Borre las banderas de reinicio en frío en RSTSTAT Para evitar que la prueba se vuelva a ejecutar en reinicios en caliente posteriores, restaure los registros MTU e inicie la aplicación.
- Si no coincide: Ejecuta la lógica de reintento.

3. Implementación de C en producción

Aquí tienes una implementación limpia y lista para producción del controlador:

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

Errores prácticos en ingeniería

1. Configuración de energía de la SRAM en espera

Durante el modo de espera, el sistema podría cortar la alimentación de la memoria RAM de retención. Si esto ocurre, la variable de estado se reinicia y el microcontrolador inicia una nueva prueba cada vez que se activa, lo que provoca un bucle de arranque infinito.

Cómo solucionarlo: Configurar el STBYRAMSEL y PROCONRAM.LMUINSEL registros en la SCU para forzar a los sectores de RAM de LMU a permanecer alimentados durante el modo de espera. Además, asegúrese de que su script de enlace coloque el g_LibistContext variable en una .noinit sección para que su código de inicialización C de inicio no la borre al despertar.

2. Trampas del acceso temprano a los datos

La lectura de sectores SRAM no inicializados justo después de un arranque en frío puede provocar un Trampa de acceso a datos en algunos pasos de silicio de AURIX debido a errores en los bits ECC o de paridad.

Cómo solucionarlo: El manejador de excepciones debe comprobar si la excepción se produjo en el espacio de memoria de retención durante el arranque inicial. Si es así, escriba datos ficticios para inicializar los bits ECC, borre el estado de la excepción y reanude la ejecución en lugar de detener la CPU.

3. Coordinación de arranque multinúcleo

AURIX es una plataforma multinúcleo. Si todos los núcleos se inician simultáneamente durante los ciclos de reinicio en caliente, pueden interferir con la máquina de estados.

Cómo solucionarlo: Configure una secuencia de arranque maestro-esclavo. Mantenga todos los núcleos auxiliares en estado de parada (usando encabezados de modo de arranque o controles SCU) durante el arranque. Solo permita Núcleo 0 para ejecutar la máquina de estados LBIST. Una vez que el núcleo 0 verifica la prueba y escribe LBIST_STATE_PASS, puede liberar los otros núcleos para arrancar.

Pruebas y validación de laboratorio

Para verificar su diseño para los evaluadores de seguridad funcional, puede utilizar estos métodos de prueba:

Verifica el Camino Dorado: Utilice su depurador para confirmar que la máquina de estados completa correctamente la transición: $$\text{START} \longrightarrow \text{Warm Reset} \longrightarrow \text{RUN} \longrightarrow \text{PASS}$$
Errores de inyección de datos: Detenga la CPU durante el COMENZAR fase, corromper manualmente el g_LibistContext.callerIntentCheck CRC en memoria y reanudar. Confirme que el software detecta el error y pasa al estado seguro sin ejecutar la prueba.
Fallos en la inyección de firmas: Modifique ligeramente la configuración de su prueba (como cambiar el número de patrones en LBISTCTRL2). Esto modificará la firma. Verifique que:
1. El código intenta ejecutar la prueba hasta 3 veces.
2. La MCU entra en estado seguro tras el tercer intento fallido.

Conclusión

La ejecución de LBIST en el AURIX TC3xx es una forma muy fiable de cumplir con los requisitos de diagnóstico de la norma ISO 26262 para lógica digital. Mediante el uso de cadenas de escaneo internas y patrones pseudoaleatorios, el hardware detecta con precisión fallos estructurales en las compuertas.

Para ejecutar esto de forma segura, debe crear una máquina de estados limpia y con reinicio cruzado. Concéntrese en proteger sus configuraciones de RAM de retención, gestionar las interrupciones de inicio, coordinar sus núcleos de CPU y establecer un límite de reintentos sólido. Esto garantiza que su autodiagnóstico sea seguro y confiable.

Dowway-Intelligent-Chassis-Software