STM32调试过程中跟工具相关的几个问题

总的来讲，单片机调试是单片机开发工作必不可少的环节。不管你愿不愿意，调试过程中总会有各种不期而遇的问题出现在我们面前来磨砺我们。这里分享几点STM32调试过程中与开发工具及IDE有关的几个常见问题，以供参考。

8 Z* \" j5 I8 A6 w% L; ^" W

1、做低功耗调试时连接不上目标板

; T; b4 u" E5 C* h  e

默认情况下，当MCU进入低功耗模式后，内核时钟停止工作，调试连接将中断。不过，通过设置DBGMCU寄存器控制位，即使进入低功耗模式，还是可以进行一定程度的调试。

在保证DGBMCU控制位正确配置前提下，还需注意SWD调试脚没有被配置为【analog state】模拟输入状态。我们在具体应用时为了降低功耗可能会将芯片的包括SWD调试脚在内的GPIO配置为模拟功能，这样会到导致调试器连接不上情况。此时在连接前先做下复位，有时可能多做几次复位才连接得上。

7 B, H2 T- a+ A# s6 n7 I

当然，上面是指低功耗模式下连接不上目标板的情况。如果是一般性的连接不上，原因就更多了，比方硬件器件、连接线路、驱动程序、用户代码本身等，这些要结合具体情况来分析。关于低功耗模式的调试支持，请参考各个系列参考手册的相关描述。

2、打印输出失败

# u/ [$ h3 |$ g& X  z

通常我们可以借助于串口助手做打印输出。如果使用STM32虚拟串口，注意PC端的虚拟串口驱动程序安装正常。相应软件包编号是STSW-STM32102。

再就是注意配置UART相关参数配置时，字长是包含了校验位的。比方8位字长，它是由 7个数据位，1个校验位组成。还有，VCP不支持字长在8位以下的传输。

另外，对于那些基于ARM CORTEX M3/M4/M7内核的STM32芯片，我们可以使用SWO方式做打印输出。

这里要注意的是：

a、不是所有MCU系列都支持SWO打印输出；目前仅基于ARM Cortex M3/M4/M7内核的芯片支持；

b、目前只支持SWD模式，不支持JTAG模式；

c、在调试环境里需做适当配置和代码补充，涉及到DBG_MCU_CR寄存器的控制位。

' ~/ J, U  ?$ [0 D1 p  I

3、低功耗应用中功耗数据异常

这个原因很多，比方，测量方面的原因，不属于MCU的功耗也算进来了；有些外设及管脚没处理好，导致漏电流还在产生；或者低功耗模式选择不对，或者进了低功耗模式马上又醒了而误测误判等等。

5 U' [  n* s, q( s

这里再提醒1点：

设置进入低功耗模式后，确认是否还在调试模式。即检查DBGMCU寄存器中与低功耗调试配置有关的寄存器控制位，确保关闭了低功耗调试状态。做低功耗数据测试时，最好不要还连接着调试器，给我们带来困扰。前不久就有人反映，用别的调试器连接着STM32目标板测得功耗与用STLINK调试器连接着测得功耗大不 一样，改用STLINK就合理了。

" W+ k2 ]9 N6 a3 e9 n5 Z' d

4、在Normal/System Reset模式下SWD连接不上目标板

/ L" Q& K4 ~- ?

此时我们可以尝试换个连接模式，比如Connect Under Reset，或者换个复位模式，比如Hardware Reset 。

' a! H2 ]- Y6 r1 e) m$ t

4 Q4 g; H/ f$ V/ V

如果说借助STLINK，即使使用ConnectUnder Reset或Hardware Reset方式还连接不上呢？我们可以查看下STLINK的NRST脚与目标板上的MCU的NRST脚是否相连了。如果是nucleo板的话，还需确认下跳线SB12是否为连接状态。

& E- Z( T! k! M9 B2 G

5、MCO脚无时钟信号输出

我们在STM32调试过程中，有时需要引出主时钟进行输出监视，即将主时钟通过MCO脚引出观察。

要想正确输出，MCO做正确配置是必须的了。当然用CubeMx配置的话一般不会有啥大问题 。不过有个地方要注意，那个GPIO的输出速率参数要合适配置，不同STM32系列的GPIO最大可输出速率在数据手册上都明确出来了。当MCO输出时钟频率较高以至于超过GPIO的输出能力时，这时需要考虑先做分频后再来做观察。

一般来讲，当MCO的输出频率在1Mhz以上时，如果观察到的波形带有很严重的噪声或者扁平的小幅度信号，甚至看不到输出的时候，我们可以考虑下是否那个OSPEED参数设置得太小了；如果说看到周期较长、幅度较大带有明显上下峰值过冲情形的波形，我们可以考虑下是否那个OSPEED参数设置得太大了。

% u0 f, a& `. u1 x) W8 _6 E4 B# F

6、没法对某些变量进行计算和监控或无法设置断点

0 U5 D, J, y6 S# f% d+ d4 J8 ]

这个原因较多，具体到调试环境，很可能跟你编译环境的优化等级配置有关。

我们在MCU调试过程中，往往会用到编译器的优化功能来提升芯片的性能和精简代码空间。不过，经过代码优化，往往可能给我们调试带来些影响，主要体现在下面几个方面:

a、  设置断点方面出现障碍，有些代码行没法做断点的设置；

b、  无法对某些变量进行观察；

c、  单步调试时出现代码运行“不连续”的情形，即执行到的地方和我看到的地方不一致；

1 k$ q$ k: D, }: M8 T8 ]3 W: O  b& G# B5 e

因此，为了实现有效调试，我们在通过编译器做优化时要选择合适的优化等级。基本原则是不影响调试体验的前提下保障编译效率。一般来讲，在调试时建议将优化等级设置在较低水平。比方KEIL MDK 推荐调试时将优化等级设置在-O1, IAR 推荐调试时将优化等级设置在-None,GCC推荐调试是将优化等级设置在-Og.其实，编译器的优化等级设置越高，对代码的规范性要求以及我们对编译器的了解程度也越高。经常有人代码优化前程序运行得好好的，代码优化等级调高好程序功能变得面目全非了。

上面提到的几个问题及应对措施，都是些可能性的提示或提醒，仅供参考，毕竟调试过程中出现的一个故障现象往往可以映射出多种应用情形及具体原因。

9 G7 c0 ?' D' c0 d, T0 T6 a

文章出处： 茶话MCU