Aqui estão alguns pensamentos e idéias:
Use a ROM de maneira mais criativa.
Armazene o que puder na ROM. Em vez de calcular coisas, armazene tabelas de consulta na ROM. (Verifique se o compilador está exibindo suas tabelas de consulta na seção somente leitura! Imprima os endereços de memória em tempo de execução para verificar!) Armazene sua tabela de vetor de interrupção na ROM. Obviamente, execute alguns testes para ver o quão confiável sua ROM é comparada à sua RAM.
Use sua melhor RAM para a pilha.
Os SEUs na pilha são provavelmente a fonte mais provável de falhas, porque é onde coisas como variáveis de índice, variáveis de status, endereços de retorno e ponteiros de vários tipos normalmente vivem.
Implemente rotinas de timer-tick e watchdog.
Você pode executar uma rotina de "verificação de integridade" a cada marca de timer, bem como uma rotina de vigilância para lidar com o bloqueio do sistema. Seu código principal também pode incrementar periodicamente um contador para indicar progresso, e a rotina de verificação de integridade pode garantir que isso ocorra.
Implemente códigos de correção de erros no software.
Você pode adicionar redundância aos seus dados para poder detectar e / ou corrigir erros. Isso aumentará o tempo de processamento, potencialmente deixando o processador exposto à radiação por mais tempo, aumentando assim a chance de erros; portanto, você deve considerar o trade-off.
Lembre-se dos caches.
Verifique os tamanhos dos caches da sua CPU. Os dados que você acessou ou modificou recentemente provavelmente estarão em um cache. Eu acredito que você pode desativar pelo menos alguns dos caches (com um grande custo de desempenho); você deve tentar isso para ver como os caches são suscetíveis aos SEUs. Se os caches forem mais difíceis que a RAM, você poderá ler e reescrever regularmente dados críticos para garantir que eles permaneçam no cache e traga a RAM de volta à linha.
Use manipuladores de falhas de página de maneira inteligente.
Se você marcar uma página de memória como não presente, a CPU emitirá uma falha de página quando você tentar acessá-la. Você pode criar um manipulador de falhas de página que faça alguma verificação antes de atender à solicitação de leitura. (Os sistemas operacionais de PC usam isso para carregar de forma transparente as páginas que foram trocadas para o disco.)
Use a linguagem assembly para coisas críticas (que podem ser tudo).
Com a linguagem assembly, você sabe o que há nos registros e o que há na RAM; você sabe quais tabelas de RAM especiais a CPU está usando e pode projetar coisas de maneira indireta para manter seu risco baixo.
Usar objdump
para realmente examinar a linguagem assembly gerada e descobrir quanto código cada uma de suas rotinas ocupa.
Se você estiver usando um grande sistema operacional como o Linux, estará pedindo problemas; há tanta complexidade e tantas coisas para dar errado.
Lembre-se de que é um jogo de probabilidades.
Um comentarista disse
Toda rotina que você escreve para detectar erros estará sujeita à falha da mesma causa.
Embora isso seja verdade, as chances de erros nos (digamos) 100 bytes de código e dados necessários para que uma rotina de verificação funcione corretamente são muito menores do que as chances de erros em outros lugares. Se sua ROM é bastante confiável e quase todo o código / dados está realmente na ROM, então suas chances são ainda melhores.
Use hardware redundante.
Use 2 ou mais configurações de hardware idênticas com código idêntico. Se os resultados diferirem, uma redefinição deve ser acionada. Com 3 ou mais dispositivos, você pode usar um sistema de "votação" para tentar identificar qual deles foi comprometido.