我真的读了很多很棒的答案！

这是我的2美分：通过编写软件检查内存或执行频繁的寄存器比较，建立内存/寄存器异常的统计模型。此外，以虚拟机的形式创建一个仿真器，您可以在其中试验该问题。我想，如果你改变结尺寸、时钟频率、供应商、外壳等，你会观察到不同的行为。

即使我们的台式电脑内存也有一定的故障率，但这不会影响日常工作。

首先，围绕失败设计应用程序。确保作为正常流程操作的一部分，它需要重置（取决于您的应用程序和软或硬故障类型）。这很难做到完美：需要某种程度的事务性的关键操作可能需要在组装级别进行检查和调整，以便关键点的中断不会导致不一致的外部命令。一旦检测到任何不可恢复的内存损坏或控制流偏差，就立即失败。如果可能，记录故障。

第二，如果可能，纠正腐败并继续下去。这意味着经常检查和修复常量表（如果可以的话，还包括程序代码）；可能在每个主要操作之前或在定时中断上，并将变量存储在自动校正的结构中（同样在每个主要运算之前或在计时中断上，从3中获得多数票，如果是单个偏差，则进行校正）。如果可能，记录更正。

第三，测试失败。设置一个可重复的测试环境，随机翻转内存中的位。这将允许您复制损坏情况，并帮助围绕它们设计应用程序。

你问的是一个非常复杂的话题——不容易回答。其他答案是可以的，但它们只涵盖了你需要做的所有事情的一小部分。

正如在评论中看到的，不可能100%解决硬件问题，但是使用各种技术很可能减少或解决这些问题。

如果我是你，我会创建最高安全完整性级别（SIL-4）的软件。获取IEC 61513文件（适用于核工业）并遵循该文件。

使用C语言编写在这种环境中表现稳健的程序是可能的，但前提是大多数形式的编译器优化都被禁用。优化编译器旨在用“更高效”的编码模式替换许多看似冗余的编码模式，并且可能不知道当编译器知道x不可能保持任何其他值时，程序员测试x==42的原因是因为程序员想要阻止执行某些代码，而x保持某个其他值——即使在这样的情况下，它保持该值的唯一方法是系统接收到某种电气故障。

将变量声明为易失性通常很有用，但可能不是万能药。特别重要的是，注意安全编码通常需要操作具有需要多个步骤来激活的硬件联锁，并且使用以下模式编写代码：

... code that checks system state
if (system_state_favors_activation)
{
  prepare_for_activation();
  ... code that checks system state again
  if (system_state_is_valid)
  {
    if (system_state_favors_activation)
      trigger_activation();
  }
  else
    perform_safety_shutdown_and_restart();
}
cancel_preparations();

如果编译器以相对文字的方式翻译代码，并且如果全部在prepare_for_activation（）之后重复对系统状态的检查，系统可以对几乎任何可能的单一故障事件具有鲁棒性，甚至那些会任意破坏程序计数器和堆栈的程序。如果在调用prepare_for_activation（）之后发生了一个小故障，这意味着激活是合适的（因为没有其他原因prepare_for_activation（）将在故障发生之前被调用）。如果故障导致代码不正确地到达prepare_for_activation（），但如果没有后续故障事件，则代码将无法在未通过验证检查或先调用cancel_preparies的情况下到达trigger_activation（）[如果堆栈出现问题，则在调用prepare_for_activation（）的上下文返回后，执行可能会继续到trigger_active（）之前的某个位置，但调用cancel_preparations（从而使后者的调用无害。

这样的代码在传统的C语言中可能是安全的，但在现代的C编译器中却不安全。这种编译器在这种环境中可能非常危险，因为它们努力只包含通过某种定义良好的机制可能出现的情况下相关的代码，并且其结果也将得到很好的定义。在某些情况下，旨在检测和清理故障的代码可能会使情况变得更糟。如果编译器确定尝试的恢复在某些情况下会调用未定义的行为，则可能推断在这种情况下不可能出现需要恢复的条件，从而消除了检查这些条件的代码。

有一点似乎没有人提到。你说你在GCC中开发，并在ARM上交叉编译。你怎么知道你的代码中没有关于空闲RAM、整数大小、指针大小、执行某个操作需要多长时间、系统将持续运行多长时间等的假设？这是一个非常普遍的问题。

答案通常是自动单元测试。编写在开发系统上执行代码的测试线束，然后在目标系统上运行相同的测试线束。寻找差异！

还要检查嵌入式设备上的勘误表。您可能会发现“不要这样做，因为它会崩溃，所以启用编译器选项，编译器会解决它”。

简而言之，崩溃的最可能来源是代码中的错误。在你确定这不是事实之前，不要担心更深奥的故障模式。

有人提到使用较慢的芯片来防止离子同样容易地翻转比特。以类似的方式，可能使用专门的cpu/ram，它实际上使用多个位来存储单个位。因此，提供了硬件容错，因为不太可能所有的位都被翻转。所以1=1111，但需要被击中4次才能真正翻转。（4可能是一个坏数字，因为如果2位被翻转，它就已经不明确了）。因此，如果您使用8，您得到的ram将减少8倍，访问时间也会慢一些，但数据表示更可靠。您可能可以在软件级别使用专门的编译器（为所有内容分配更多的空间）或语言实现（为以这种方式分配内容的数据结构编写包装器）来实现这一点。或具有相同逻辑结构但在固件中执行此操作的专用硬件。