關(guān)鍵字：高精度定時(shí)器，Single-shot 計(jì)數(shù)模式

目錄預(yù)覽

1 問(wèn)題提出2 問(wèn)題分析3 解決辦法4 小結(jié)

1. 問(wèn)題提出

客戶使用STM32G474的高精度定時(shí)器，基于CubeMX進(jìn)行外設(shè)設(shè)置和代碼生成，將某個(gè)子定時(shí)器的計(jì)數(shù)方式設(shè)置為retriggerable single shot方式，發(fā)現(xiàn)該子定時(shí)器無(wú)PWM輸出，在調(diào)試模式下發(fā)現(xiàn)該子定時(shí)器的計(jì)數(shù)器一直為0，即計(jì)數(shù)器一直沒(méi)有啟動(dòng)，但如果將計(jì)數(shù)方式修改為continuous模式，其他保持不變，定時(shí)器工作正常

2.問(wèn)題描述

檢查客戶提供的CubeMX配置文件，客戶使能了Master Timer與Timer B，Master Timer的比較器事件2觸發(fā)Timer B復(fù)位與運(yùn)行，并配置了Timer B的PWM輸出，使用該工程文件直接生成代碼，并添加高精度定時(shí)器計(jì)數(shù)使能與輸出使能函數(shù)，如下：

進(jìn)入調(diào)試模式觀察，發(fā)現(xiàn)Master Timer正常計(jì)數(shù)，但是Timer B的計(jì)數(shù)器一直保持0，按照客戶的描述，將Timer B的計(jì)數(shù)方式修改為“continous”后，Timer B恢復(fù)正常計(jì)數(shù)。對(duì)比Timer B在“retriggerable single shot”與“continous”兩種工作模式下的相關(guān)寄存器的值進(jìn)行對(duì)比，發(fā)現(xiàn)除了計(jì)數(shù)模式不同之外，其他所有狀態(tài)都相同。

莫非真是“retriggerable single shot”存在問(wèn)題？這明顯不可能，此前多次使用過(guò)該模式并沒(méi)有發(fā)現(xiàn)問(wèn)題，于是將以前設(shè)計(jì)的能成功工作的例程拿來(lái)與該“問(wèn)題”工程進(jìn)行對(duì)比。經(jīng)過(guò)比對(duì)分析發(fā)現(xiàn)，工程設(shè)置中使用的寄存器更新方式存在不同，如下圖所示：

圖1.正常工作工程中的寄存器更新配置

圖2.“問(wèn)題”工作工程中的寄存器更新配置

“問(wèn)題”工程配置中使用Master Timer的更新作為觸發(fā)寄存器更新觸發(fā)源，并且更新要等到本定時(shí)器的下一次的Reset/Roll-over事件出現(xiàn)時(shí)才生效。通過(guò)將“Update taken into account on the following Reset/Roll-over event”修改為“Update taken into account immediately”，定時(shí)器也可以正常運(yùn)行了，問(wèn)題的原因就是由于該配置引起的。

查看該配置對(duì)應(yīng)的寄存器說(shuō)明：

當(dāng)配置“Update taken into account on the following Reset/Roll-over event”對(duì)應(yīng)于該位置“1”，即更新事件，無(wú)論是來(lái)自相鄰定時(shí)器的還是軟件產(chǎn)生的，都需要等到下一個(gè)Reset/Roll-over event才生效。

在直接使用CubeMX產(chǎn)生的HAL底層配置代碼且配置中使能了預(yù)加載的情況下，該寄存器更新配置方式會(huì)導(dǎo)致Timer B的初始化配置無(wú)法生效。

如圖3/4/5所顯示的，因?yàn)樵贑ubeMX直接生成的代碼中，Timer B參數(shù)的配置通過(guò)調(diào)用函數(shù)HAL_HRTIM_WaveformTimerConfig()寫入寄存器，然后在該函數(shù)中調(diào)用軟件更新函數(shù)HRTIM_ForceRegistersUpdate()的方式讓配置生效，那么在目前的配置下，軟件觸發(fā)更新也必須等待Reset/Roll-over event的出現(xiàn)。而在retriggerable single shot計(jì)數(shù)模式下，定時(shí)器不能自動(dòng)啟動(dòng)計(jì)數(shù)，必須等待來(lái)自Master Timer的Reset事件（即前文提到的比較器事件2）

圖3.“問(wèn)題”工程中的寄存器更新與定時(shí)器Reset配置

圖4.“問(wèn)題”工程產(chǎn)生的Timer B初始化代碼

圖5.Timer B初始化代碼中調(diào)用軟件觸發(fā)更新

綜上，雖然正確地配置了Reset事件，Master Timer也正常計(jì)數(shù)且產(chǎn)生了比較事件2，但問(wèn)題在于在運(yùn)行了初始化代碼后，該配置僅僅是寫到了preload寄存器中，而沒(méi)有寫入active寄存器中，即Timer B的復(fù)位源沒(méi)有生效，帶來(lái)的后果就是Timer B的計(jì)數(shù)器不運(yùn)行，一直保持0，且所有帶有預(yù)加載特性的寄存器的值也沒(méi)有生效。

作為對(duì)比，當(dāng)配置為“Update taken into account immediately”時(shí)，調(diào)用軟件觸發(fā)更新函數(shù)HRTIM_ForceRegistersUpdate（）函數(shù)，將使所有配置立即生效，定時(shí)器可正常工作。

3. 解決方法

基于以上分析，造成該問(wèn)題的主要原因時(shí)CubeMX基于HAL庫(kù)自動(dòng)生成的初始化代碼中沒(méi)有考慮不同的寄存器更新配置方式，只是單一的采用軟件更新的方式來(lái)觸發(fā)寄存器更新。要解決以上問(wèn)題，需要修改代碼中的定時(shí)器初始化的時(shí)序，在配置寄存器更新方式為“Update taken into account on the following Reset/Roll-over event”前，讓其他的配置先生效，基本邏輯如下，該邏輯在客戶自己編寫初始化代碼時(shí)也需要遵循。

4.小結(jié)

解決客戶提出的高精度定時(shí)器中的子定時(shí)器在retriggerable single shot計(jì)數(shù)模式下無(wú)法工作的問(wèn)題，原因在于該計(jì)數(shù)模式下，當(dāng)更新配置方式為“Update taken into account on the following Reset/Roll-over event”時(shí)，使用CubeMX生成的原始初始化代碼出現(xiàn)了定時(shí)器配置無(wú)法生效，從而導(dǎo)致問(wèn)題的出現(xiàn)。通過(guò)對(duì)初始化代碼的邏輯進(jìn)行簡(jiǎn)單修改，問(wèn)題得以解決。當(dāng)然，STM32CubeMX的未來(lái)版本應(yīng)會(huì)就這個(gè)地方做針對(duì)性地完善。

完整內(nèi)容請(qǐng)點(diǎn)擊“閱讀原文”下載原文檔。

長(zhǎng)按掃碼關(guān)注公眾號(hào)

更多資訊，盡在STM32

▽點(diǎn)擊“閱讀原文”，可下載原文檔