在嵌入式软件中发现并消除潜在的bug是一件困难的事情。要从观察到的崩溃、挂起或其他计划外运行时行为追溯到根本原因，通常需要付出巨大的努力和昂贵的工具。嵌入式开发工程师们常常放弃寻找罕见异常的原因——因为这些异常无法在实验室中轻易重现——而将其视为“用户错误”或“小故障”，然而，机器中的这些潜在危机仍然一直存在。
因此，这里有一个关于难以重现的固件错误最常见的根本原因的指南。
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.不可重入函数
从技术上讲，不可重入函数的问题是竞争条件问题的一个特例。 出于这个原因，由不可重入函数引起的运行时错误是相似的，也不会以可重现的方式发生——这使得它们同样难以调试。 不幸的是，与其他类型的竞争条件相比，不可重入函数在代码审查中也更难发现。
使函数可重入的关键是暂停对外围寄存器、全局变量(包括静态局部变量)、持久堆对象和共享内存区域的所有访问的抢占。嵌入式开发人员可以通过禁用一个或多个中断或通过获取和释放互斥锁来完成，共享数据类型的细节通常决定了最佳解决方案。
