Autor: Johnny Liu
Título: CEO da Dowway Vehicle
Data: 24 de junho de 2026
Categoria: Eletrônica Automotiva / Segurança Funcional / Firmware Embarcado
Table of Contents
Perguntas frequentes rápidas
O que é LBIST no AURIX TC3xx? É um autoteste de hardware que verifica as portas lógicas digitais dos microcontroladores. Ele utiliza cadeias de varredura internas, executa padrões de teste pseudoaleatórios e cria uma assinatura única para verificar se o hardware contém falhas estruturais latentes.
Por que executar o LBIST aciona uma reinicialização a quente? O teste de varredura sobrescreve e embaralha o estado dos circuitos digitais. Uma reinicialização a quente é necessária para limpar esses estados inválidos e inicializar o sistema novamente em um estado limpo e previsível.
Onde você encontra a assinatura de ouro para o teste? Trata-se de um valor estático de 32 bits pré-calculado. Você pode encontrar a assinatura para a sua contagem e frequência de padrões específicas no apêndice da Unidade de Controle do Sistema (SCU) do Manual do Usuário do Infineon AURIX TC3xx.
Por que este guia é importante (a perspectiva da ISO 26262)
Em projetos automotivos críticos para a segurança (ASIL-B a ASIL-D), devemos detectar falhas de hardware aleatórias. Falhas latentes são especialmente perigosas. São falhas que permanecem ocultas durante a condução normal, mas podem levar a violações de segurança se uma segunda falha ocorrer.
O autoteste lógico integrado (LBIST) é um mecanismo de segurança de hardware fundamental (SM:MCU:LBIST) no AURIX TC3xx. Ele tem como alvo a Métrica de Falha Latente (LFM). Como verifica as portas lógicas do núcleo digital, a execução bem-sucedida do LBIST permite verificar a CPU, o barramento e os controladores de segurança na inicialização. Isso elimina a necessidade de verificações lógicas lentas e complexas baseadas em software posteriormente.
Comparação rápida de autotestes para startups
Para manter seu design organizado, não confunda LBIST com outros testes integrados nesta plataforma:
| Mecanismo de teste | O que testa | Causa a reinicialização? | Quando executar | Objetivo principal |
| LBIST | Lógica Digital Interna | Sim (Reinicialização a quente) | Inicialização antecipada (POST a frio / Despertar em modo de espera) | Detecta falhas estruturais em portas LFM. |
| MBIST | Memórias SRAM e Flash | Não (Configurável) | Inicialização ou Tempo de Execução | Detecta falhas em células de memória e linhas de endereço. |
| MONBIST | Monitores de tensão PMS | Não | Inicialização antecipada | Verifica os caminhos de backup do monitor de tensão. |
| Verificação de Fw | Configurações de registro de chave | Não | Pós-reinicialização / Tempo de execução | Verifica registros e pegadas de firmware |
Como funciona o TC3xx LBIST em hardware
Cadeias de Varredura e Compressão de Assinatura
O LBIST depende de testes de varredura estrutural. Durante a fabricação, os projetistas de chips interligam os flip-flops internos para formar registradores seriais chamados de cadeias de varredura.
+---------------------------------------------------------------------------------+
| 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) | |
| +-------------------+ +-------------------------------+ |
+---------------------------------------------------------------------------------+
O hardware segue um ciclo limpo e automatizado:
- Geração de padrões: Um Registrador de Deslocamento com Feedback Linear (LFSR) cria padrões de teste pseudoaleatórios com base em um valor inicial (o Semente).
- Mudança para dentro: O controlador transfere esses padrões para as cadeias de varredura internas.
- Fase de Captura: O sistema executa um ou mais relógios funcionais. As portas lógicas processam os padrões e os flip-flops capturam a saída.
- Deslocamento e compressão: Os dados capturados são transferidos para um Registro de Assinatura de Entrada Múltipla (MISR), que comprime o longo fluxo de bits em um único bit. assinatura de 32 bits.
- Avaliando: O software compara essa assinatura com o valor de referência para confirmar se o hardware está em boas condições.
O que a LBIST não cobre
Leve em consideração estas limitações de hardware:
- Módulos analógicos: Não testa os blocos analógicos PMS, EVR ou ADC.
- Conteúdo da SRAM: O teste de memória é feito pelo MBIST. Como o LBIST embaralha o hardware, ele corrompe certos registradores da Unidade de Teste de Memória (MTU). Seu software deve fazer backup e restaurar esses valores de registradores.
Registros de hardware que você precisa conhecer.
Configurar o teste significa escrever em registradores na Unidade de Controle do Sistema (SCU). Essas escritas são protegidas por Endinit de Segurança (SEINIT) para evitar execuções acidentais.
LBISTCTRL0(Controle 0): Contém os bits de disparo redundantes (LBISTREQeLBISTREQUÍVEL), o bit de reinicialização do controlador (LBISTRES), e o indicador de conclusão (LBISTDONE).LBISTCTRL1(Controle 1): Define o divisor de frequência do clock de teste (FREQU), o layout estrutural lógico (CORPO), alterando os limites de velocidade para gerenciar os picos de corrente (DIVIDIDO), e a semente LFSR (SEMENTE).LBISTCTRL2(Controle 2): Define o número de padrões de teste a serem executados (COMPRIMENTO).LBISTCTRL3(Controle 3): Contém a assinatura de teste final de 32 bits (ASSINATURA).RSTSTAT(Redefinir status): Monitora como o teste terminou através doLBTERM(o teste terminou normalmente) eLBPORST(o teste não foi interrompido por uma reinicialização de energia) sinalizadores.
O Limite de Reinicialização Aconchegante
O hardware sempre força uma reinicialização a quente do sistema quando o teste termina. Esta é uma escolha de projeto de hardware deliberada.
Como o teste de varredura força a passagem de valores aleatórios pelo chip, os estados internos das portas lógicas tornam-se inválidos. O reset a quente limpa todos os registradores e inicia o microcontrolador a partir de um estado limpo.
Embora a SRAM retenha seus dados durante uma reinicialização a quente, essa reinicialização corrompe partes da MTU. O software deve lidar com essa transição com cuidado.
Projetando uma máquina de estados de reinicialização cruzada
Como o teste aciona uma reinicialização a quente, você deve dividir seu driver de software em duas partes: a Fase de disparo de pré-reinicialização e o Fase de Análise Pós-Reinicialização.
+--------------------+
| 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. Configurando o armazenamento persistente
Para transmitir informações de status durante uma reinicialização a quente, você precisa de um pequeno bloco de memória que não seja apagado durante a reinicialização. No AURIX TC3xx, usamos um segmento dedicado da memória. DLMU SRAM Configurado para retenção de energia em modo de espera.
Eis como você pode configurar esse bloco de memória em 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. Fluxo e etapas do software
Fase A: Gatilho de Pré-Reinicialização
- Verifique a causa da reinicialização: Ler
RSTSTAT. Execute o teste somente se a reinicialização tiver sido um Porção fria ou um Despertar em modo de espera. Ignore esta opção para reinicializações acionadas por software. - Leia o estado atual: Ler
g_LbistContext.estado. Na inicialização a frio, inicialize isto paraLBIST_STATE_START. - Faça backup dos registros MTU: Salve quaisquer estados críticos de registro MTU na RAM de retenção para que você possa restaurá-los após a reinicialização.
- Configurar hardware: Desative as interrupções. Desbloqueie a proteção de segurança Endinit (
DesbloquearSEINIT()Escreva as configurações de semente, frequência e contagem de padrões emLBISTCTRL1eLBISTCTRL2. - Verificação de intenção de escrita: Calcule o CRC da configuração e escreva-o em
g_LbistContext.callerIntentCheck. Isso impede que bugs de software graves acionem o teste acidentalmente. - Defina o estado como RUN: Escrever
LBIST_STATE_RUNparag_LbistContext.estado. - Gatilho redundante: Escrever
1para ambosLBISTCTRL0.LBISTREQeLBISTCTRL0.LBISTREQREDno mesmo ciclo de clock. - Bloquear CPU: Entrar em um loop de montagem infinito (
enquanto(1);) e aguarde a reinicialização do hardware.
Fase B: Análise Pós-Reinicialização
- Entrada de inicialização: O microcontrolador inicializa. O software lê
RSTSTATe detecta a reinicialização a quente. - Verificar estado: O software lê
g_LbistContext.estadoe descobre que está configurado paraLBIST_STATE_RUN. - Verificar intenção: Calcule o CRC e compare-o com
g_LbistContext.callerIntentCheck. Caso não correspondam, sinalize um erro de corrupção de dados e ignore o teste para evitar loops de inicialização. - Verifique as bandeiras: Confirme que
RSTSTAT.LBTERM == 1,RSTSTAT.LBPORST == 0, eLBISTCTRL0.LBISTDONE == 1. - Verificar assinatura: Leia a assinatura de
LBISTCTRL3.ASSINATURAe compare-o com o valor áureo.- Se houver correspondência: Defina o estado para
LBIST_STATE_PASS. Reinicie o controlador LBIST através deLBISTRES. Limpe os sinalizadores de reinicialização a frio emRSTSTATPara evitar que o teste seja executado novamente em reinicializações a quente subsequentes, restaure os registros MTU e inicialize o aplicativo. - Se não houver correspondência: Execute a lógica de repetição.
- Se houver correspondência: Defina o estado para
3. Implementação em C de Produção
Aqui está uma implementação limpa e pronta para produção do driver:
#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;
}
}
}
Armadilhas práticas da engenharia
1. Configurações de energia SRAM em modo de espera
Durante o modo de espera, o sistema pode cortar a alimentação da sua memória RAM de retenção. Se isso acontecer, a variável de estado será reiniciada e o microcontrolador executará um novo teste a cada ativação, causando um loop de inicialização infinito.
- Como corrigir: Configure o
STBYRAMSELePROCONRAM.LMUINSELregistros no SCU para forçar os setores de RAM da LMU a permanecerem energizados durante o modo de espera. Além disso, certifique-se de que seu script de vinculação inclua og_LbistContextvariável em um.noinitseção para que seu código de inicialização em C não a limpe ao despertar.
2. Armadilhas do Acesso Antecipado a Dados
A leitura de setores SRAM não inicializados logo após uma inicialização a frio pode causar um problema. Armadilha de acesso a dados em algumas etapas de fabricação de silício AURIX devido a erros de ECC ou bits de paridade.
- Como corrigir: Seu manipulador de exceção deve verificar se a exceção ocorreu no espaço de memória de retenção durante a inicialização. Se sim, escreva dados fictícios para inicializar os bits ECC, limpe o status da exceção e retome a execução em vez de interromper a CPU.
3. Coordenação de inicialização multi-core
AURIX é uma plataforma multi-core. Se todos os núcleos inicializarem ao mesmo tempo durante os ciclos de reinicialização a quente, eles podem interferir na sua máquina de estados.
- Como corrigir: Configure uma sequência de inicialização mestre-escravo. Mantenha todos os núcleos auxiliares em estado de repouso (usando os cabeçalhos do modo de inicialização ou os controles da SCU) durante a inicialização. Permita apenas Núcleo 0 para executar a máquina de estados LBIST. Assim que o Core 0 verificar o teste e gravar
LBIST_STATE_PASS, ele pode liberar os outros núcleos para inicializar.
Testes e Validação em Laboratório
Para verificar a segurança funcional do seu projeto, você pode usar os seguintes métodos de teste:
- Verifique o Caminho Dourado: Use o seu depurador para confirmar se a máquina de estados concluiu a transição com sucesso: $$\text{START} \longrightarrow \text{Reinicialização a Quente} \longrightarrow \text{RUN} \longrightarrow \text{PASS}$$
- Erros de Injeção de Dados: Interrompa a CPU durante o
COMEÇARfase, corromper manualmente og_LbistContext.callerIntentCheckCRC na memória e retomar. Confirme se o software detecta o erro e transita para o estado seguro sem executar o teste. - Falhas na Injeção de Assinatura: Altere ligeiramente a configuração do seu teste (como, por exemplo, alterar a contagem de padrões em
LBISTCTRL2Isso alterará a assinatura. Verifique se:- O código tenta executar o teste até 3 vezes.
- O MCU entra em estado de segurança na 3ª tentativa falhada.
Concluindo
Executar o LBIST no AURIX TC3xx é uma maneira altamente confiável de atender aos requisitos de diagnóstico da norma ISO 26262 para lógica digital. Utilizando cadeias de varredura internas e padrões pseudoaleatórios, o hardware identifica com precisão falhas estruturais nas portas lógicas.
Para executar isso com segurança, você deve construir uma máquina de estados limpa e com reinicialização cruzada. Concentre-se em proteger suas configurações de RAM de retenção, gerenciar interrupções de inicialização, coordenar seus núcleos de CPU e definir um limite sólido de tentativas. Isso garante que seu autoteste seja seguro e confiável.