嵌入式分享合集72

去了一天环球太累了 转天又换暖气 太累了 太乏 就随便写俩个

一、怎么定位bug

一、问题复现

    稳定复现问题才能正确的对问题进行定位、解决以及验证。一般来说，越容易复现的问题越容易解决。

1.1 模拟复现条件

    有的问题存在于特定的条件下，只需要模拟出现问题的条件即可复现。对于依赖外部输入的条件，如果条件比较复杂难以模拟可以考虑程序里预设直接进入对应状态。

1.2 提高相关任务执行频率

    例如某个任务长时间运行才出现异常则可以提高该任务的执行频率。

1.3 增大测试样本量

    程序长时间运行后出现异常，问题难以复现，可以搭建测试环境多套设备同时进行测试。

二、问题定位

    缩小排查范围，确认引入问题的任务、函数、语句。

2.1 打印LOG

    根据问题的现象，在抱有疑问的代码处增加LOG输出，以此来追踪程序执行流程以及关键变量的值，观察是否与预期相符。

2.2 在线调试

    在线调试可以起到和打印LOG类似的作用，另外此方法特别适合排查程序崩溃类的BUG，当程序陷入异常中断(HardFault，看门狗中断等)的时候可以直接STOP查看call stack以及内核寄存器的值，快速定位问题点。

2.3 版本回退

    使用版本管理工具时可以通过不断回退版本并测试验证来定位首次引入该问题的版本，之后可以围绕该版本增改的代码进行排查。

2.4 二分注释

    二分注释即以类似二分查找法的方式注释掉部分代码，以此判断问题是否由注释掉的这部分代码引起。

    具体方法为将与问题不相干的部分代码注释掉一半，看问题是否解决，未解决则注释另一半，如果解决则继续将注释范围缩小一半，以此类推逐渐缩小问题的范围。

2.5 保存内核寄存器快照

    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、通信时序错误

例如电源管理芯片Isl78600，假设现在两片级联，当同时读取两片的电压采样数据时，高端芯片会以固定周期通过菊花链将数据传送到低端芯片，而低端芯片上只有一个缓存区.

    如果单片机不在规定时间内将低端芯片上的数据读走那么新的数据到来时将会覆盖当前数据，导致数据丢失。此类问题需要仔细分析芯片的数据手册，严格满足芯片通信的时序要求。

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 硬件问题

• 晶振未起振

• 供电电压不足

• 复位引脚拉低

3.2 .2 复位

3.2.2.1 软件问题

1、看门狗复位

    除了喂狗超时导致的复位以外，还要注意看门狗配置的特殊要求，以Freescale KEA单片机为例，该单片机看门狗在配置时需要执行解锁序列（向其寄存器连续写入两个不同的值），该解锁序列必须在16个总线时钟内完成，超时则会引起看门狗复位。此类问题只能熟读单片机数据手册，注意类似的细节问题。

3.2.2.2 硬件问题

• 供电电压不稳

• 电源带载能力不足

四、回归测试

    问题解决后需要进行回归测试，一方面确认问题是否不再复现，另一方面要确认修改不会引入其他问题。

五、经验总结

    总结本次问题产生的原因及解决问题的方法，思考类似问题今后如何防范，对相同平台产品是否值得借鉴，做到举一反三，从失败中吸取经验。  whaosoft aiot http://143ai.com

二、状态机编程的优点

提高CPU使用效率

    话说我只要见到满篇都是delay_ms()的程序就会头疼，动辄十几个ms几十个ms的软件延时是对CPU资源的巨大浪费，宝贵的CPU时间都浪费在了NOP指令上。那种为了等待一个管脚电平跳变或者一个串口数据，让整个程序都不动的情况也让我非常纠结，如果事件一直不发生电平跳变，你要等到世界末日么？

    如果应用状态机编程思想，程序只需要用全局变量记录下工作状态，就可以转头去干别的工作了，当然忙完那些活儿之后要再看看工作状态有没有变化。只要目标事件(定时未到、电平没跳变、串口数据没收完)还没发生，工作状态就不会改变，程序就一直重复着“查询—干别的—查询—干别的”这样的循环，这样CPU就闲不下来了。

    这种处理方法的实质就是在程序等待事件的过程中间隔性地插入一些有意义的工作，好让CPU不是一直无谓地等待。

逻辑完备性

    逻辑完备性是状态机编程最大的优点。

    不知道大家有没有用C语言写过计算器的小程序，我很早以前写过，写出来一测试，那个惨不忍睹啊！当我规规矩矩的输入算式的时候，程序可以得到正确的计算结果，但要是故意输入数字和运算符号的随意组合，程序总是得出莫名其妙的结果。

    后来我试着思维模拟一下程序的工作过程，正确的算式思路清晰，流程顺畅，可要碰上了不规矩的式子，走着走着我就晕菜了，那么多的标志位，那么多的变量，变来变去，最后直接分析不下去了。

    很久之后我认识了状态机，才恍然明白，当时的程序是有逻辑漏洞的。如果把这个计算器程序当做是一个反应式系统，那么一个数字或者运算符就可以看做一个事件，一个算式就是一组事件组合。对于一个逻辑完备的反应式系统，不管什么样的事件组合，系统都能正确处理事件，而且系统自身的工作状态也一直处在可知可控的状态中。反过来，如果一个系统的逻辑功能不完备，在某些特定事件组合的驱动下，系统就会进入一个不可知不可控的状态，与设计者的意图相悖。

    状态机就能解决逻辑完备性的问题。

    状态机是一种以系统状态为中心，以事件为变量的设计方法，它专注于各个状态的特点以及状态之间相互转换的关系。状态的转换恰恰是事件引起的，那么在研究某个具体状态的时候，我们自然而然地会考虑任何一个事件对这个状态有什么样的影响。这样，每一个状态中发生的每一个事件都会在我们的考虑之中，也就不会留下逻辑漏洞。

    这样说也许大家会觉得太空洞，实践出真知，某天如果你真的要设计一个逻辑复杂的程序，会觉得状态机真香！

程序结构清晰

    用状态机写出来的程序的结构是非常清晰的。

    程序员最痛苦的事儿莫过于读别人写的代码。

    如果代码不是很规范，而且手里还没有流程图，读代码会让人晕了又晕，只有顺着程序一遍又一遍的看，很多遍之后才能隐约地明白程序大体的工作过程。有流程图会好一点，但是如果程序比较大，流程图也不会画得多详细，很多细节上的过程还是要从代码中理解。

    相比之下，用状态机写的程序要好很多，拿一张标准的UML状态转换图，再配上一些简明的文字说明，程序中的各个要素一览无余。程序中有哪些状态，会发生哪些事件，状态机如何响应，响应之后跳转到哪个状态，这些都十分明朗，甚至许多动作细节都能从状态转换图中找到。可以毫不夸张的说，有了UML状态转换图，程序流程图写都不用写。

三、STM32单片机的堆栈

学习STM32单片机的时候，总是能遇到“堆栈”这个概念。分享本文，希望对你理解堆栈有帮助。

    对于了解一点汇编编程的人，就可以知道，堆栈是内存中一段连续的存储区域，用来保存一些临时数据。堆栈操作由PUSH、POP两条指令来完成。而程序内存可以分为几个区：

• 栈区（stack）

• 堆区（Heap）

• 全局区（static）

• 文字常亮区程序代码区

    程序编译之后，全局变量，静态变量已经分配好内存空间，在函数运行时，程序需要为局部变量分配栈空间，当中断来时，也需要将函数指针入栈，保护现场，以便于中断处理完之后再回到之前执行的函数。
    栈是从高到低分配，堆是从低到高分配。
普通单片机与STM32单片机中堆栈的区别
    普通单片机启动时，不需要用bootloader将代码从ROM搬移到RAM。

    但是STM32单片机需要。

    这里我们可以先看看单片机程序执行的过程，单片机执行分三个步骤：

• 取指令

• 分析指令

• 执行指令

    根据PC的值从程序存储器读出指令，送到指令寄存器。然后分析执行执行。这样单片机就从内部程序存储器去代码指令，从RAM存取相关数据。

    RAM取数的速度是远高于ROM的，但是普通单片机因为本身运行频率不高，所以从ROM取指令慢并不影响。

    而STM32的CPU运行的频率高，远大于从ROM读写的速度。所以需要用bootloader将代码从ROM搬移到RAM。

    使用栈就象我们去饭馆里吃饭，只管点菜（发出申请）、付钱、和吃（使用），吃饱了就走，不必理会切菜、洗菜等准备工作和洗碗、刷锅等扫尾工作，他的好处是快捷，但是自由度小。使用堆就象是自己动手做喜欢吃的菜肴，比较麻烦，但是比较符合自己的口味，而且自由度大。

    其实堆栈就是单片机中的一些存储单元，这些存储单元被指定保存一些特殊信息，比如地址（保护断点）和数据（保护现场）。

    如果非要给他加几个特点的话那就是：

• 这些存储单元中的内容都是程序执行过程中被中断打断时，事故现场的一些相关参数。如果不保存这些参数，单片机执行完中断函数后就无法回到主程序继续执行了。

• 这些存储单元的地址被记在了一个叫做堆栈指针（SP）的地方。

结合STM32的开发讲述堆栈

    从上面的描述可以看得出来，在代码中是如何占用堆和栈的。可能很多人还是无法理解，这里再结合STM32的开发过程中与堆栈相关的内容来进行讲述。

    如何设置STM32的堆栈大小？

    在基于MDK的启动文件开始，有一段汇编代码是分配堆栈大小的。

     这里重点知道堆栈数值大小就行。还有一段AREA（区域），表示分配一段堆栈数据段。数值大小可以自己修改，也可以使用STM32CubeMX数值大小配置，如下图所示。

    STM32F1默认设置值0x400，也就是1K大小。

Stack_Size EQU 0x400

    函数体内局部变量：

void Fun(void){ char i; int Tmp[256]; //...}

    局部变量总共占用了256*4 + 1字节的栈空间。所以，在函数内有较多局部变量时，就需要注意是否超过我们配置的堆栈大小。

    函数参数：

void HAL_GPIO_Init(GPIO_TypeDef *GPIOx, GPIO_InitTypeDef *GPIO_Init)

    这里要强调一点：传递指针只占4字节，如果传递的是结构体，就会占用结构大小空间。提示：在函数嵌套,递归时，系统仍会占用栈空间。

    堆（Heap）的默认设置0x200（512）字节。

Heap_Size EQU 0x200

    大部分人应该很少使用malloc来分配堆空间。虽然堆上的数据只要程序员不释放空间就可以一直访问，但是，如果忘记了释放堆内存，那么将会造成内存泄漏，甚至致命的潜在错误。

MDK中RAM占用大小分析

    经常在线调试的人，可能会分析一些底层的内容。这里结合MDK-ARM来分析一下RAM占用大小的问题。在MDK编译之后，会有一段RAM大小信息：