嵌入式开发常见问题排查
嵌入式开发问题排查
很多人认为嵌入式开发很难，主要是因为在这个过程中常常会遇到各式各样的问题。这些问题的复杂性和多样性使得许多人感到困惑和无所适从。然而，如果将这些问题逐一拆解，实际上大部分都可以归结为相对简单的小问题。接下来，我们将讨论一些嵌入式开发中常见的问题及其解决方法。
一、问题复现
要有效解决问题，首先需要能够稳定地复现它。一般来说，容易复现的问题也相对容易解决。
- 模拟复现条件
某些问题只在特定环境下发生。通过模拟这些条件，就能成功复现问题。如果外部输入条件复杂，可以考虑在程序中预设某些状态来直接触发问题。
- 提高相关任务执行频率
如果某个任务运行时间较长后才出现异常，可以提高该任务的执行频率，以便更快地观察到问题。
- 增大测试样本量
当程序长时间运行后才出现异常时，单一设备的测试可能不够，可以搭建多个设备的测试环境，从而提高发现问题的概率。
二、问题定位
在复现问题的基础上，接下来要缩小排查范围，以确认引发问题的具体任务、函数或代码语句。
- 打印LOG
在可疑代码段增加LOG输出，可以帮助追踪程序的执行流程及关键变量的值，观察这些值是否符合预期。
- 在线调试
在线调试能够与打印LOG类似地追踪问题，特别适合于排查程序崩溃类的错误。当程序进入异常状态（如HardFault或看门狗中断）时，可以直接暂停程序，查看调用栈和寄存器的值，从而快速定位问题。
- 版本回退
使用版本管理工具（如git）时，可以通过逐步回退代码版本并进行测试，来定位首次引入问题的版本，之后再围绕该版本的改动进行排查。
- 二分注释
这种方法类似于二分查找，通过注释掉一部分代码来判断问题是否由被注释的部分引起。具体做法是分批注释代码，逐步缩小范围，直到找到引发问题的代码段。
通过上述方法，可以有效解决嵌入式开发中的常见问题，从而降低开发的难度感。
- 保存内核寄存器快照
Cortex M内核陷入异常中断时会将几个内核寄存器的值压入栈中，如下图：我们可以在陷入异常中断时将栈上的内核寄存器值写入RAM的一段复位后保留默认值的区域内，执行复位操作后再从RAM将该信息读出并分析，通过PC、LR确认当时执行的函数，通过R0-R3分析当时处理的变量是否异常，通过SP分析是否可能出现栈溢出等。
结合问题现象以及定位的问题代码位置分析造成问题的原因。
3.1 程序继续运行
3.1.1 数值异常
3.1.1.1 软件问题
1、数组越界
写数组时下标超出数组长度，导致对应地址内容被修改。如下：
此类问题通常需要结合map文件进行分析，通过map文件观察被篡改变量地址附近的数组，查看对该数组的写入操作是否存在如上图所示不安全的代码，将其修改为安全的代码。
2、栈溢出
在分析栈溢出问题时，结合map文件的内容是非常重要的。假设栈是从高地址向低地址增长的，当发生栈溢出时，g_val的值可能会被栈中的其他值覆盖。为了有效分析栈的最大使用情况，需要注意以下几点：函数调用层数过多、中断服务函数中进行额外的函数调用，以及在函数内声明较大的临时变量，都可能导致栈溢出。
为了解决这些问题，可以采取以下措施：
- 合理分配内存资源：在设计阶段，应为栈设置合适的大小，以预防栈溢出。
- 使用静态变量：对于函数内较大的临时变量，可以使用static关键字将其转化为静态变量，或者通过malloc()动态分配内存，将其放置在堆上。
- 优化函数调用结构：降低函数的调用层数，以减少栈的使用深度。
通过以上方法，可以有效降低栈溢出的风险，保障程序的稳定性。
3、判断语句条件写错
判断语句的条件容易把相等运算符“==”写成赋值运算符“=”导致被判断的变量值被更改，该类错误编译期不会报错且总是返回真。建议将要判断的变量写到运算符的右边，这样错写为赋值运算符时会在编译期报错。还可以使用一些静态代码检查工具来发现此类问题。
4、同步问题
例如操作队列时，出队操作执行的过程中发生中断(任务切换)，并且在中断(切换后的任务)中执行入队操作则可能破坏队列结构，对于这类情况应该操作时关中断（使用互斥锁同步）。
5、优化问题
如上图程序，本意是等待irq中断之后不再执行foo()函数，但被编译器优化之后，实际运行过程中flg可能被装入寄存器并且每次都判断寄存器内的值而不重新从ram里读取flg的值，导致即使irq中断发生foo()也一直运行，此处需要在flg的申明前加“volatile”关键字，强制每次都从ram里获取flg的值。
3.1.1.2 硬件问题
1、芯片BUG
芯片本身存在BUG，在某些特定情况下给单片机返回一个错误的值，需要程序对读回的值进行判断，过滤异常值。
2、通信时序错误
3.1.2 动作异常
3.1.2.1 软件问题
1、设计问题
设计中存在错误或者疏漏，需要重新评审设计文档。
2、实现与设计不符
代码的实现与设计文档不相符需要增加单元测试覆盖所有条件分支，进行代码交叉review。
3、状态变量异常
例如记录状态机当前状态的变量被篡改，分析该类问题的方法同前文数值异常部分。
3.1.2.2 硬件问题
1、硬件失效
目标IC失效，接收控制指令后不动作，需要排查硬件。
2、通信异常
与目标IC通信错误，无法正确执行控制命令，需要使用示波器或逻辑分析仪去观察通信时序，分析是否发出的信号不对或者受到外部干扰。
3.2 程序崩溃
3.2.1 停止运行
3.2.1.1 软件问题
1、HardFault
以下情况会造成HardFault：
- 在外设时钟门未使能的情况下操作该外设的寄存器；
- 跳转函数地址越界，通常发生在函数指针被篡改，排查方法同数值异常；
- 解引用指针时出现对齐问题：
以小端序为例，如果我们声明了一个强制对齐的结构体如下：
此时a.val1的地址为0x00000001，如果以uint16_t类型去解引用此地址则会因为对齐问题进入HardFault，如果一定要用指针方式操作该变量则应当使用memcpy()。
2、中断服务函数中未清除中断标志
中断服务函数退出前不正确清除中断标志，当程序执行从中断服务函数内退出后又会立刻进入中断服务函数，表现出程序的“假死”现象。
3、NMI中断
调试时曾遇到SPI的MISO引脚复用NMI功能，当通过SPI连接的外设损坏时MISO被拉高，导致单片机复位后在把NMI引脚配置成SPI功能之前就直接进入NMI中断，程序挂死在NMI中断中。这种情况可以在NMI的中断服务函数内禁用NMI功能来使其退出NMI中断。
3.2.1.2 硬件问题
1、晶振未起振
2、供电电压不足
3、复位引脚拉低
3.2 .2 复位
3.2.2.1 软件问题
1、看门狗复位
除了喂狗超时导致的复位以外，还要注意看门狗配置的特殊要求，以Freescale KEA单片机为例，该单片机看门狗在配置时需要执行解锁序列（向其寄存器连续写入两个不同的值），该解锁序列必须在16个总线时钟内完成，超时则会引起看门狗复位。此类问题只能熟读单片机数据手册，注意类似的细节问题。
3.2.2.2 硬件问题
1、供电电压不稳
2、电源带载能力不足
四、回归测试
问题解决后需要进行回归测试，一方面确认问题是否不再复现，另一方面要确认修改不会引入其他问题。