你的浏览器版本过低,可能导致网站不能正常访问!
为了你能正常使用网站功能,请使用这些浏览器。

单片机调试过程中的第3只眼

[复制链接]
Canly 发布时间:2020-2-25 15:17
在我们的单片机调试过程中,经常会遇到类似如下因第3只眼而导致的问题。何谓第3只眼呢?不妨先看看几个实例就知道了。
第一个案例,与ADC转换标志位有关的问题。遇到该问题是一种较为频繁的情形。
经常有人在做STM32 ADC应用,进行代码单步调试时发现,明明启动了ADC转换就是等不到转换结束的那一刻,即总是检测不到EOC等于1的时候。有时让人直急得冒汗!比方类似下面的情形,开启了ADC转换指令,然后等待ADC转换结束。

# T! \; g2 l" G  A& q6 m2 Y/ C# Q
11.png
$ M+ K! n% I% R% a3 F
在那蓝色圆圈的代码处,查询等待EOC等于1,可就是等不到它为1的时候。是怎么回事呢?
原来,STM32芯片ADC的转换结束标志EOC位,具有读清零的特性。当你调试时打开外设寄存器显示栏时,那调试组件在不停的读取它。当你单步操作去读取该标志位时往往先被调试组件读过了。即使它之前被置位过,但因调试组件的读取后又被清零。当你单步慢悠悠去读它时,结果读到的往往是0,你就查不到为1的那一刻,此时我们可能会傻傻的等和着急。

; e9 l+ W3 f; L6 T
22.png
" A; {: P( P" r; }3 A
当然,如果你将右边ADC外设寄存器显示栏关闭就不会出现上述问题了。
第二个案例,与UART状态寄存器标志位有关的问题。遇到该问题也是较为频繁的情形。
某STM32用户使用STM32F2系列芯片的UART外设及相关功能。他发现明明接收完毕,发送标志TC位也置位了,可就是不进IDLE空闲中断。当然,相关中断使能都已正常使能无误。实际情形是这样的:
STM32F205的UART5发送指令(循环发送一个字节一个字节地发)给wifi芯片,WiFi芯片会返回相应数据过来,所以,正常来讲uart5会收到一帧数据之后应该进入串口接收IDLE中断.这是客户所期望的。
他将断点打在UART中断服务程序的检查到IDLE中断请求位等于1后的入口处。就像下面截图的样子。他甚至在右边的UART寄存器显示栏都看到IDLE被置位过的痕迹了,可就是进不到相关代码里去,怎么回事呢?

! H$ H# e( b7 y3 j' k. V
33.png

' i/ |) K' ^; B6 _
因为他开启了UART寄存器显示窗口,意味着调试组件在不停帮他读了UART相关寄存器,其中包括DR和SR寄存器。当他在中断代码里再去读SR寄存器里的IDLE标志位时,读回来的结果总是0,所以中断程序没法进一步走下去。对于他这里,严格地说是响应了中断,只是没法进一步进入相关中断服务代码区。

- Y( b( f. {, p# h: D3 W
其实,对于stm32f2芯片UART的IDLE中断请求标志位的清零会遵循一个访问序列,即读DR寄存器,然后读SR寄存器就可将IDLE位清零。

8 r) b+ i2 P. C1 N9 G
44.png
% W* D( h% R, t/ L
当然,解决上面问题的办法也很简单,调试跟踪时,将右边UART的外设寄存器显示栏关闭就好。

% x' E. G9 c* q
第三个案例,与读取RTC日历有关的问题。一个较为隐蔽而容易误导人的问题。
/ y1 K+ l1 @) N' }' M: ^6 ]( u( G
曾有人反馈说STM32F4和STM32L4的RTC脱机运行跑不起来,不运行。具体表现就是日历时间不动、不更新。奇怪的是,调试时候不论单步还是全速运行,查看日历寄存器都显示正常运行,数据也正确。
可当烧录代码到芯片后,通过调试助手查看日历的数据则原地不动了,感觉RTC没有运行。客户用STM32F4和STM32L4的板都测试过,出现同样问题。怀疑STM32F4和L4芯片的RTC是否有BUG【反正找不到原因了就想芯片bug】。
查看其测试代码,就是读RTC的日历,很简单。如下:
while (1)
{
HAL_RTC_GetTime(&hrtc,&rtcTime,RTC_FORMAT_BIN);
printf( ...... );
HAL_Delay(1000);
}
从上面代码不难看出就是不停地去读当前的时、分、秒时间。STM32参考手册在关于RTC日历读取操作部分有相关描述。为了读取时间的一致性,读取日历操作要求先读时分秒然后还得读日期,这样做为一个完整的操作。所以在读取TIME【时分秒】后,硬件会将当前日历值锁住,直到读取了日期寄存器。否则当你读了TIME而不读DATE的话,再去读TIME时还是原来的值维持不变。显然,客户这里的代码只有读取TIME时间的语句,没有读取DATE日期的代码。这是问题根本原因之所在。
但是,为什么同样代码在调试情况下又能正常运行呢?那是因为他在调试时打开着RTC寄存器外设显示窗口,虽然用户代码没去读DATE,但调试组件帮忙读了DATE寄存器,所以感觉上一切风调雨顺,也就没能及时发现问题,一直到程序烧进芯片后才发现异常症状。

- Y% r: B3 D' R9 r' h: r* Z
55.png

3 @) g' U' G1 ?0 Z8 U% o* u" C
到此,结合上述3个案例的分享介绍,我们应该明白了那个第3只眼了,即调试组件。个别寄存器或寄存器位具有“读则变”或“读有效”的特性。我们在调试时候要注意类似细节,调试时也不必时刻将那个外设寄存器显示栏开启挂在那里。其实,除了这个寄存器显示栏外,我们还可以利用其它输出,比方示波器、printf,或者WATCH窗口等来辅助观察运行状态或结果。
- d- o2 f! U% U; X( d% U9 X
既然这里把调试组件称之为第3只眼,那另外两只眼呢?这个不难想到CPU和DMA。

9 C- X( i7 ~# K1 c+ e; a% H8 r* k' A1 s; ~, u, Q0 a9 t7 v

# z# w; b4 l+ A  P) v) K& K& {2 a

评分

参与人数 1 ST金币 +3 收起 理由
子曰好人 + 3 赞一个!

查看全部评分

收藏 2 评论3 发布时间:2020-2-25 15:17

举报

3个回答
慎微 回答时间:2020-2-25 15:28:40
感恩分享!
踮起脚摘苹果 回答时间:2020-2-25 19:24:37
楼主,正好我今天也调试过ADC,问题大概是这样的:5 F( L$ e% w2 J+ _! _* S
while(!ADC_GetFlagStatus(ADC1,ADC_FLAG_EOC));
6 c2 q4 f& A0 N8 d% H0 p6 p! \" l' I$ O( g/ D7 j0 H
断点一直卡在这行,之前我的RCC时钟配置的写法是把GPIO和ADC1分开分成两行写且放在两个函数里面分开调用,就出错了,到那时如果是这样:
( e% H6 O/ T9 @/ W& H0 ~/ M) U- x4 Z. G
        RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOA | RCC_APB2Periph_ADC1,ENABLE);
( d3 O2 e( i8 B3 \2 e4 E  L! a1 {4 U2 Y% }, @, `0 w8 o& M: C4 _/ |3 m
放在一起用"|"一行写就可以了 或者放在同一个函数下分两行写也可以
byronsong 回答时间:2020-2-25 20:49:26
感谢分享

所属标签

相似分享

关于意法半导体
我们是谁
投资者关系
意法半导体可持续发展举措
创新和工艺
招聘信息
联系我们
联系ST分支机构
寻找销售人员和分销渠道
社区
媒体中心
活动与培训
隐私策略
隐私策略
Cookies管理
行使您的权利
关注我们
st-img 微信公众号
st-img 手机版