type
status
date
slug
summary
tags
category
icon
password
上次编辑时间
Aug 17, 2025 10:44 PM
💡
我们Debug究竟在解决什么问题？
其实主要分为两类问题。
第一类问题是解决厂商资料不全，信息缺失的问题（如何通过debug来根据元器件已获得资料来适配我们嵌入式系统（比如根据数据手册，用户手册来给MPU6050写驱动程序）。
由于嵌入式系统中每个部件都是通过采购外部器件来的，比如MCU，MPU6050等。
对于这些器件，厂家只会释放有限的资料。
即使厂家能够释放全部资料给我们，但很多内部的Know-how，是无法用文字、视频等资料全部完整的制作好，并释放给我们的，因为任何厂商都无法事无巨细的把每一个细节都给我们，这不现实，也不符合厂商的投入回报成本。
同时，另一方面，对厂商来说，每个工程师的自身水平也不相同，厂商要写文档也不可能从面向一个小学文化水平的人来写，所以厂家给出的文档只能说是一个非常有限的资料，仅仅能够参考。
当你遇到问题时，最好能找到原厂商的FAE支持。如果不能，且条件不允许，则只能通过自己设计实验来解决开发过程中的问题。
第二类问题是如何通过Debug来解决系统中的自身软件问题（你设计的软件，结果出bug了）
这类问题主要是解决系统的运行结果与我们预期的结果不同的问题，比如，串口输出乱码、定时器定时不准等等。
就拿定时器定时不准来举例，定时器的设置有很多的参数，不同的寄存器决定不同的参数，仅仅根据手册上的基础内容，我们还不能直接拿来配置寄存器，还需要通过计算来计算出所需要的分频器、重装载数、中断优先级等。其中中断优先级又会和整个操作系统的优先级定义有关系，如果定时器的中断优先级不够高，则定时器中断的响应就会有延迟，因此，定时将无法准确。但是这类问题，在设计系统时，即使是经验非常丰富的老工程师，也很难预先想到，只能做的时候发现了，才能去解决。而且，由于嵌入式是一个高度定制的行业，即使你在网上能够找到相同的解决方案，但还需要根据你的具体环境来重新分析和思考。那时就需要通过不停的实验来定位问题。
关于如何设计实验…局部验证、结果推断
设计实验过程中，但很多没有良好习惯的工程师，喜欢东测测，西测测，刚凭自己的主观意向来实验，当试完一圈后，发现解决不了问题，就会开始重复性怀疑个链条上的各个环节，比如，杜邦线是否牢靠，代码是否下载的是最新代码，数据手册是不是过时，是不是电源不稳定等等，最终像一个无头苍蝇一样东测西测，自己都把自己搞蒙了，最终极有可能任务完不成，整个人生极崩溃，相信很多时候大家都能发现，很多时候我们发现解决某个复杂问题的原因是因为一个忽略的小细节，比如，杜邦线接错，每调用初始化等。
那么，Debug流程中实验的设计应该是什么样的呢？

一、问题的描述

1. 问题的表现是怎样的？

关于问题的表现的描述，素材应尽量详细，多附上一些截图/录屏/复现文档

2. 问题的复现路径

比如：1.工程代码附上2.说明复现细节：使用串口输出还是RTT，波特率是多少

3. 正常的预期是什么？

正常的表现应该是怎么样，比如，串口应该输出"Hello world"

二、问题产生的可能原因分析

1.初步CheckList确认：

  1. 排除硬件问题：找一个确定可以运行的软件，先跑一下，确认硬件没有问题
  1. 程序可能爆栈了：在启动文件里调整下栈大小，如果是在 RTOS 里，则调整一下任务的栈大小
  1. 程序可能被过度优化：调整优化等级，建议 0
  1. 程序可能进入死循环：进入调试模式，然后全速运行程序然后按暂停，看是否进入 Hardfault，然后用栈回溯）
  1. 可能程序执行错误：打印每个相关函数的返回值！
  1. 可能指针为空：打断点到指针运行处，看指针里面的值是不是 0x00000000
  1. 可能 API 接口用错：Freertos 最好使用 Freertos 本身的 api，比如使用 queue.h 文件里面的函数，task.h 里面的函数，而不是 CMSIS_os_V2.h 里面的函数。
  1. 可能有些程序片段根本没执行到：比如按键操作如果用 polling 的方式，它运行很快，打断点不方便观察，应该在每个状态机或 if 语句里放置 printf（“1/r/n”）；printf( “2/r/n”) ; 等
  1. 可能有些线程被饿死了：在线程里面加一些 vTaskDelay（100）延时，防止有些线程被饿死。
  1. 可能有些线程没有 while（1）循环：检查是不是有些线程没有死循环，直接退出了
  1. 如果有互斥量和信号量的使用，项目卡死，则先尝试关闭它们，看会不会卡死（一般情况下是死锁），再尝试逐个成对打开。
  1. 所有的局部变量，全局变量一定要赋初值

2.提出可能的原因

比如：1.可能是任务调度造成串口打印不完全，关掉任务调度试一试

三、设计实验，验证可能的原因和猜想

详细描述修复问题的技术方案、相关示意图、流程图、时序图

四、验证实验

第一次实验

1.实验序号

1.需要注明这是第几次实验（每次都需要修改）2.实验时间（每次都需要更改）

2.实验环境

需要注明本次测试的测试环境
比如：1.相关芯片型号2.固件版本3.电源供电的的内容4.有其他实验环境也需要标注
需要附件本次实验相关的文档，比如相关的MCU/MPU的Datasheet,User manual等
比如：1.相关的MCU/MPU的Datasheet，User manual

3.实验步骤

1.需要记录下如何启动的MCU/MPU，是通过电源上下电还是按键复位等。
2.其他与本次实验相关的步骤。

4.实验结果

1.输出本次实验的结果

分析一下这次实验有什么新的发现

2.实验分析

1.对比本次实验步骤和上次实验步骤的区别。
2.对比本次实验结果和上次实验结果的区别。
3.是否解决了问题？若无，设计下一次实验
 
最后将问题文档确认好标题，归属问题范围，方便并入公司内网档案