嵌入式软件关于难以重现的固件错误最常见的根本原因的指南

发现和消除嵌入式软件中的潜在错误非常困难。从观察到的崩溃、挂起或其他计划外的运行时行为中追踪根本原因通常需要大量的工作和昂贵的工具。嵌入式开发人员经常放弃寻找罕见异常的原因——因为它们不能在实验室中轻易复制——并将它们视为“用户错误”或“故障”，但是，这些潜在的机器危机仍然存在。

因此，这里有一个关于难以重现的固件错误的最常见根本原因的指南。

1.堆碎片

嵌入式软件开发人员并未广泛使用动态内存分配 – 原因之一是堆碎片问题。

由 C 的 malloc() 标准库例程或 C++ 的 new 关键字创建的所有数据结构都存在于堆上。堆是具有预定最大大小的特定 RAM 区域。最初，堆中的每个分配都会将剩余的“空闲”空间减少相同的字节数。

可以通过调用 free() 或使用 delete 关键字将不再需要的数据结构的存储返回到堆中。理论上，这使得该存储空间在后续分配期间可重用。但是分配和删除的顺序通常至少是伪随机的——导致堆变成一堆更小的碎片。

2.堆栈溢出

每个程序员都知道堆栈溢出是一件非常糟糕的事情。但是，每次堆栈溢出的影响各不相同。损害的性质和不当行为的时间完全取决于哪些数据或指令受到损害以及它们是如何使用的。重要的是，堆栈溢出与其对系统的负面影响之间的时间长度取决于使用损坏位之前的时间长度。

不幸的是，在嵌入式开发中，堆栈溢出对嵌入式系统的影响远远超过台式计算机。这有几个原因，包括：

嵌入式系统通常只依赖少量的 RAM；

通常没有可依赖的虚拟内存（因为没有磁盘）；

基于 RTOS 任务的固件设计利用多个堆栈（每个任务一个），每个堆栈都必须足够大中断函数可重入是什么，以确保没有唯一的最坏情况堆栈深度；

中断处理程序可能会尝试使用这些相同的堆栈。

3.缺少“volatile”关键字

未能使用 C 的“volatile”关键字标记某些类型的变量可能会导致系统出现许多症状，这些症状只有在编译器的优化器设置为低级别或禁用时才能正常工作。在变量声明期间使用 volatile 限定符来防止对该变量的读写优化。

请注意，除了确保对给定变量进行所有读取和写入之外，使用 volatile 还会通过添加额外的“序列点”来限制编译器。对多个 volatile 的访问必须按照它们在代码中的写入顺序执行。

4.比赛条件

竞争条件是指两个或多个执行线程（可以是 RTOS 任务或 main() 加 ISR）的组合结果根据每条指令交错的确切顺序而变化的任何情况。

例如，假设嵌入式开发人员有两个执行线程，其中一个定期递增全局变量 (g_counter += 1;)，另一个偶尔重置它 (g_counter = 0;)。如果增量不能总是以原子方式执行（即，在单个指令周期中），则此处存在竞争条件。计数器变量的两次更新之间的冲突可能永远不会或很少发生。但是当它发生时，计数器实际上并没有在内存中重置。这种影响可能会对系统产生严重后果，尽管它可能要等到实际碰撞很久之后才会发生。

最佳实践：可以通过包围必须以适当的抢占限制行为以原子方式执行的代码的“关键部分”来防止竞争条件。为了防止涉及 ISR 的竞争条件，在其他代码的关键部分必须至少禁用一个中断信号。在 RTOS 任务之间竞争的情况下，最佳实践是创建一个特定于该共享对象的互斥体中断函数可重入是什么，每个任务必须在进入临界区之前获取该互斥体。请注意，依赖特定 CPU 的功能来确保原子性并不是一个好主意，因为这只会在编译器或 CPU 更改之前防止出现竞争条件。

5.不可重入函数

从技术上讲，不可重入函数问题是竞态条件问题的一个特例。出于这个原因，由不可重入函数引起的运行时错误是相似的，并且不会以可重现的方式发生——这使得它们同样难以调试。不幸的是，与其他类型的竞争条件相比，不可重入函数在代码审查中也更难发现。

使函数可重入的关键是暂停对外围寄存器、全局变量（包括静态局部变量）、持久堆对象和共享内存区域的所有访问的抢占。嵌入式开发人员可以通过禁用一个或多个中断或通过获取和释放互斥体来做到这一点，共享数据类型的细节通常决定了最佳解决方案。