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

基于STM32高精度定时器中single-shot计数模式不工作

[复制链接]
STMCU小助手 发布时间:2023-8-18 13:13
1. 问题提出
" w# K9 K0 Y9 @' d+ G
客户使用STM32G474的高精度定时器,基于CubeMX进行外设设置和代码生成,将某个子定时器的计数方式设置为retriggerable single shot方式,发现该子定时器无PWM输出,在调试模式下发现该子定时器的计数器一直为0,即计数器一直没有启动,但如果将计数方式修改为continuous模式,其他保持不变,定时器工作正常
! g6 l/ @1 o& j) f' N5 q
2. 问题描述
( {$ x3 B+ v% |& J, b. x
检查客户提供的CubeMX配置文件,客户使能了Master Timer与Timer B,Master Timer的比较器事件2触发Timer B复位与运行,并配置了Timer B的PWM输出,使用该工程文件直接生成代码,并添加高精度定时器计数使能与输出使能函数,如下:
, U& B2 Z; V7 ^0 M
微信图片_20230818131317_2.png
; c3 I' Q, ?3 y' n
进入调试模式观察,发现Master Timer正常计数,但是Timer B的计数器一直保持0,按照客户的描述,将Timer B的计数方式修改为“continous”后,Timer B恢复正常计数。对比Timer B在“retriggerable single shot”与“continous”两种工作模式下的相关寄存器的值进行对比,发现除了计数模式不同之外,其他所有状态都相同。
! X% w7 }2 @  j3 q  M
莫非真是“retriggerable single shot”存在问题?这明显不可能,此前多次使用过该模式并没有发现问题,于是将以前设计的能成功工作的例程拿来与该“问题”工程进行对比。经过比对分析发现,工程设置中使用的寄存器更新方式存在不同,如下图所示:

' n6 O/ E4 S$ i& A: H  W6 }
微信图片_20230818131317_1.png
图1.正常工作工程中的寄存器更新配置
" [" J: Y0 }+ H# l5 l" ?3 U
微信图片_20230818131317.png
图2.“问题”工作工程中的寄存器更新配置

8 K+ A4 f0 M, N# Z8 Y+ n
“问题”工程配置中使用Master Timer的更新作为触发寄存器更新触发源,并且更新要等到本定时器的下一次的Reset/Roll-over事件出现时才生效。通过将“Update taken into account on the following Reset/Roll-over event”修改为“Update taken into account immediately”,定时器也可以正常运行了,问题的原因就是由于该配置引起的。

& x6 o4 O, ?8 u4 s& P* l( I
查看该配置对应的寄存器说明:

1 V0 q0 U2 ]2 q6 j5 ^
微信图片_20230818131318_4.png

* k* G3 p+ G- ?; ~8 T3 o  O' t
当配置“Update taken into account on the following Reset/Roll-over event”对应于该位置“1”,即更新事件,无论是来自相邻定时器的还是软件产生的,都需要等到下一个Reset/Roll-over event才生效。

9 i0 i( d2 c9 H9 ]# r
在直接使用CubeMX产生的HAL底层配置代码且配置中使能了预加载的情况下,该寄存器更新配置方式会导致Timer B的初始化配置无法生效。

, M! _, w0 p$ G# M+ M* H; {. M
如图3/4/5所显示的,因为在CubeMX直接生成的代码中,Timer B参数的配置通过调用函数HAL_HRTIM_WaveformTimerConfig()写入寄存器,然后在该函数中调用软件更新函数HRTIM_ForceRegistersUpdate()的方式让配置生效,那么在目前的配置下,软件触发更新也必须等待Reset/Roll-over event的出现。而在retriggerable single shot计数模式下,定时器不能自动启动计数,必须等待来自Master Timer的Reset事件(即前文提到的比较器事件2)
. G! j5 ]& L3 w5 m$ B, K7 }6 V
微信图片_20230818131318_3.png
图3.“问题”工程中的寄存器更新与定时器Reset配置

" ~0 [8 J' |. I! D% s
微信图片_20230818131318_2.png
图4.“问题”工程产生的Timer B初始化代码

/ C! A6 b6 X( w5 h" G, `
微信图片_20230818131318_1.png
图5.Timer B初始化代码中调用软件触发更新
- H3 o: h4 G  c, B7 D
综上,虽然正确地配置了Reset事件,Master Timer也正常计数且产生了比较事件2,但问题在于在运行了初始化代码后,该配置仅仅是写到了preload寄存器中,而没有写入active寄存器中,即Timer B的复位源没有生效,带来的后果就是Timer B的计数器不运行,一直保持0,且所有带有预加载特性的寄存器的值也没有生效。

  R" }( U. a5 ~6 t# E) Z1 N7 p
作为对比,当配置为“Update taken into account immediately”时,调用软件触发更新函数HRTIM_ForceRegistersUpdate()函数,将使所有配置立即生效,定时器可正常工作。

: H& M- \& L8 ?
3. 解决方法
0 z/ z7 Q6 z) i' B. C
基于以上分析,造成该问题的主要原因时CubeMX基于HAL库自动生成的初始化代码中没有考虑不同的寄存器更新配置方式,只是单一的采用软件更新的方式来触发寄存器更新。要解决以上问题,需要修改代码中的定时器初始化的时序,在配置寄存器更新方式为“Update taken into account on the following Reset/Roll-over event”前,让其他的配置先生效,基本逻辑如下,该逻辑在客户自己编写初始化代码时也需要遵循。

/ Q5 G8 Q0 a' ?" B& y8 A
微信图片_20230818131318.png
3 ~- t' Y2 R& K" J0 h2 c3 N
4.小结

6 ]4 \1 e6 _* J2 E
解决客户提出的高精度定时器中的子定时器在retriggerable single shot计数模式下无法工作的问题,原因在于该计数模式下,当更新配置方式为“Update taken into account on the following Reset/Roll-over event”时,使用CubeMX生成的原始初始化代码出现了定时器配置无法生效,从而导致问题的出现。通过对初始化代码的逻辑进行简单修改,问题得以解决。当然,STM32CubeMX的未来版本应会就这个地方做针对性地完善。

. P! R' s/ K& m5 N# R9 K
转载自: STM32单片机
如有侵权请联系删除
9 v0 f% N0 O0 W7 |4 K

9 X8 p6 l) y; c, \

$ ~9 p) Q+ u6 K  q9 u
赞 收藏 评论1 发布时间:2023-8-18 13:13

举报

1个回答
bitterheart 回答时间:2023-8-30 09:07:10

学习了

所属标签

相似技术帖

关于
我们是谁
投资者关系
意法半导体可持续发展举措
创新与技术
意法半导体官网
联系我们
联系ST分支机构
寻找销售人员和分销渠道
社区
媒体中心
活动与培训
隐私策略
隐私策略
Cookies管理
行使您的权利
官方最新发布
人形机器人运动控制、感知与智能配电
半导体创新技术与应用方向
EE架构与软件定义汽车
12V/48V 汽车智能配电(SPD)
区域控制单元(ZCU)与分区架构
关注我们
st-img 微信公众号
st-img 手机版