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

目錄預(yù)覽

1. 問題提出

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

2.問題描述

檢查客戶提供的CubeMX配置文件，客戶使能了Master Timer與Timer B，Master Timer的比較器事件2觸發(fā)Timer B復(fù)位與運(yùn)行，并配置了Timer B的PWM輸出，使用該工程文件直接生成代碼，并添加高精度定時器計(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ù)。對比Timer B在“retriggerable single shot”與“continous”兩種工作模式下的相關(guān)寄存器的值進(jìn)行對比，發(fā)現(xiàn)除了計(jì)數(shù)模式不同之外，其他所有狀態(tài)都相同。

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

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

圖2.“問題”工作工程中的寄存器更新配置

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

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

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

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

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

圖3.“問題”工程中的寄存器更新與定時器Reset配置

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

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

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

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

3. 解決方法

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

4.小結(jié)

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

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

長按掃碼關(guān)注公眾號

更多資訊，盡在STM32

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