如果你的硬件出现故障，你可以使用机械存储来恢复它。如果你的代码库很小，并且有一些物理空间，那么你可以使用一个机械数据存储。

材料表面不会受到辐射的影响。将有多个档位。机械读卡器将在所有齿轮上运行，并且可以灵活地上下移动。向下表示为0，向上表示为1。从0和1可以生成代码库。

这是一个非常广泛的主题。基本上，您无法真正从内存损坏中恢复，但至少可以尝试立即失败。以下是您可以使用的一些技巧：

校验和常量数据。如果有任何配置数据长期保持不变（包括已配置的硬件寄存器），请在初始化时计算其校验和并定期验证。当您看到不匹配时，应该重新初始化或重置。冗余存储变量。如果你有一个重要的变量x，把它的值写在x1、x2和x3中，然后读为（x1==x2）？x2:x3。实施程序流程监控。将全局标志与从主循环调用的重要函数/分支中的唯一值进行异或。在接近100%测试覆盖率的无辐射环境中运行程序，应为您提供循环结束时标志的可接受值列表。如果看到偏差，则重置。监视堆栈指针。在主循环的开头，将堆栈指针与其预期值进行比较。偏差复位。

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

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

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

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

既然您专门要求软件解决方案，而且您使用的是C++，为什么不使用运算符重载来创建自己的安全数据类型呢？例如：

不要使用uint32_t（以及double、int64_t等），而是制作自己的SAFE_uint32-t，其中包含uint32/t的倍数（最小值为3）。重载您想要执行的所有操作（*+-/<<>>==！=等），并使重载的操作对每个内部值独立执行，即不要执行一次并复制结果。在之前和之后，检查所有内部值是否匹配。如果值不匹配，可以将错误的值更新为最常见的值。如果没有最常见的值，您可以安全地通知存在错误。

这样，即使ALU、寄存器、RAM或总线上发生损坏也无所谓，您仍然可以多次尝试并很好地捕获错误。然而，请注意，这只适用于您可以替换的变量-例如，堆栈指针仍然是易受影响的。

附带故事：我遇到了一个类似的问题，也是在一个旧的ARM芯片上。结果发现，这是一个使用旧版本GCC的工具链，与我们使用的特定芯片一起，在某些边缘情况下触发了一个错误，这会（有时）破坏传递到函数中的值。在将设备归咎于无线电活动之前，确保设备没有任何问题，是的，有时是编译器错误=）

使用循环调度程序。这使您能够增加定期维护时间，以检查关键数据的正确性。最常遇到的问题是堆栈损坏。如果您的软件是周期性的，您可以在周期之间重新初始化堆栈。不要为中断调用重用堆栈，请为每个重要的中断调用设置一个单独的堆栈。

与看门狗概念类似的是最后期限计时器。在调用函数之前启动硬件计时器。如果函数在截止时间计时器中断之前未返回，则重新加载堆栈并重试。如果在3/5次尝试后仍然失败，则需要从ROM重新加载。

将软件拆分为多个部分，并将这些部分隔离开来，以使用单独的内存区域和执行时间（尤其是在控制环境中）。示例：信号采集、预处理数据、主要算法和结果实现/传输。这意味着某一部分的失败不会导致整个程序的失败。因此，当我们修复信号采集时，其余任务将继续处理过时的数据。

一切都需要CRC。如果您在RAM中执行，甚至您的.txt也需要CRC。如果使用循环调度程序，请定期检查CRC。有些编译器（不是GCC）可以为每个部分生成CRC，有些处理器有专用硬件来进行CRC计算，但我想这将超出您的问题范围。检查CRC还会提示内存上的ECC控制器在出现问题之前修复单位错误。

使用看门狗进行启动，而不仅仅是一次操作。如果您的启动遇到问题，您需要硬件帮助。

您可能还对有关算法容错的丰富文献感兴趣。这包括旧的赋值：编写一个排序，当恒定数量的比较将失败时（或者，更糟糕的版本，当失败的比较的渐近数量为n次比较的log（n）时），正确地对其输入进行排序。

开始阅读黄和亚伯拉罕1984年的论文《矩阵运算的基于算法的容错》。他们的想法隐约类似于同态加密计算（但实际上并不相同，因为他们正在尝试在操作级别进行错误检测/纠正）。

该论文的一个较新的后代是Bosilca、Delmas、Dongarra和Langou的“基于算法的容错应用于高性能计算”。