STM32 CubeMX开发 超详细MDK在线Debug教程
- 1 CubeMX配置
- 2 Debug设置
- 3 Debug功能演示
- 3.1 断点调试
- 3.2 单步调试
- 3.3 变量监视
- X 往期文章
本教程在上一期呼吸灯的基础上增加在线debug讲解，通过变量监视完成代码调试
1 CubeMX配置
这里以stm32f103为例，在它的开发手册里我们可以找到SWJ调试端口的定义及其对应引脚
我们可以选择不同的模式，不同的模式占用引脚情况不相同
在CubeMX中的SYS项中我们可以选择debug模式，选择好模式后会自动使能相关引脚
SW串行模式
4针脚的JTAG模式
5针脚的JTAG模式
其他的模式是一些带Trace的调试模式，我们一般的开发用不到，想要详细了解的可以参考对应芯片的手册对TPIU模块的介绍
我一般选择SW串行模式（占用引脚最少）就可以进行调试，选择好Debug后生成工程
2 Debug设置
生成工程后我们先编译一次，没有报错后，在debug选项卡中选择你的调试下载器，我使用的是STlink，如果你有Jlink等下载器选择对应的即可
确认是否可以识别到
点击Setting进入二级窗口，查看是否检测到 （确保芯片已经上电，下载器、开发板及电脑连接正确）
可以在二级窗口的Flah Download里修改烧写规则
设置完成后点击确定即可
3 Debug功能演示
我们在日常的代码调试中用到最多的就是断点、单步调试以及变量监视
这里有个点需要注意，我们在调试前最好把代码编译一遍。不编译直接点调试按钮，如果芯片内的代码和你的代码不一致是没法调试的，如果你确定芯片里的代码就是你现有的代码可以不重新编译直接进入Debug模式。编译后直接点击Debug按钮，MDK会自动把新编译的代码下载并进入Debug模式并停止在main函数的开始
如下图即进入了Debug模式，可以看到程序停在了main函数的起始处等待我们下一步操作
3.1 断点调试
我们有时需要程序在调试时能够停在某处，以便我们进行单步调试、变量监视或是验证我们的代码逻辑是否正确。这就要设置断点（也叫打断点），打断点的操作可以在进入Debug前也可以在进入Debug后，但最好在进入Debug后再打断点，下面你就会看到原因
退出Debug模式后，这些深灰色的块就消失了
所以最好在进入Debug后设置断点，并且在进入Debug模式后，如果你发现你想要打断点的地方并没有变为深灰色，那么一种情况是你的这句代码或者整个函数并没有被调用（逻辑上出了问题），另一种情况是编译器在编译时做了优化，编译器认为你的这句话没必要执行根本就没有编译。第一种情况排插逻辑和调用错误，第二种情况需要修改编译器优化等级，因为编译优化只是一些固化的算法，也会有BUG
在此处可以修改优化等级，数字越大优化越多，我一般选0级，因为我开发的工程不是很大不需要优化，有时候优化反而会给我带啦麻烦（比如While（condition）无法break）
进入Debug后在深灰色区域单击鼠标左键就可看到多出一个红点，这就是断点
打好断点，点击run，程序停在了断点处
若果程序一直没有停在断点，而你觉得程序应该停在断点，那你又可以检查逻辑错误了
3.2 单步调试
单步调试的优点在于我们可以一步一步执行代码，观察变量的变化，检查是否存在逻辑上的错误和函数调用上的问题，前提是得先让代码停下来，也就是打上断点，然后从断点处一步一步的运行
跳入跳出程序块（if while 或函数）
单步运行
如果想让变量都回到起始状态点击reset即可
3.3 变量监视
在调试的时候我们有时候想看一些变量的值是否正确，在Debug模式下，选中变量右键，添加到监视窗口中（在程序stop和run时都可以添加）
可以看到变量及其值已经在监视窗口显示
也可以将监视移除或修改显示形式（程序stop时才可以移除）
在这里把实时更新的勾勾打
点击run可以看到监视窗口中的值在随程序的运行而变化，值在更新时背景会变为这种蓝绿色
X 往期文章
鸿蒙（HMOS）开发基础篇（三）开发工具特性介绍
STM32 CubeMX开发 F1通用定时器
鸿蒙（HMOS）开发基础篇（二）开发初体验-多设备协同
鸿蒙（HMOS）开发基础篇（一）环境搭建 & Helloworld
今天，我是数据库的BOS(读者-写者问题
哲学家不会吃饭了，我们快来帮帮他们（C语言、进程通信）
Python+OpenCV+imutils的简单图片处理（放缩、翻转、旋转、灰度RGB提取）
python手写K-means实现二维聚类
如果文中有误，还请在评论区指正。这里是海小皮，我们一同进步！！！
