|
整理：MilerShao
近日某工程師電話我說他在使用STM32F072芯片開發(fā)產(chǎn)品，發(fā)現(xiàn)USART2中斷無法從將芯片從STOP模式喚醒。他說也是折騰幾天了，翻來覆去都查不出問題所在，懷疑芯片是否真具有該功能。因?yàn)橹坝衅渌蛻粲玫皆摴δ�，我告知確實(shí)可行，建議他再耐心檢查 一天后我們?cè)俅尉W(wǎng)絡(luò)聯(lián)絡(luò)，告知仍然無法實(shí)現(xiàn)USART喚醒STOP狀態(tài)。我查看其相關(guān)程序代碼，代碼是基于STM32F0系列傳統(tǒng)固件庫(kù)編寫的。將客戶代碼結(jié)合32f0系列的技術(shù)參考手冊(cè)來看了兩遍并未發(fā)現(xiàn)什么明顯問題。 因?yàn)镾TM32F0系列官方固件庫(kù)里有相關(guān)例程項(xiàng)目，打開官方例程代碼和參考手冊(cè)比對(duì)時(shí)，有個(gè)地方引起了我的注意。那就是USART是時(shí)鐘源問題。 
我注意到ST官方例程里在配置USART的喚醒功能時(shí)，有條關(guān)于USART時(shí)鐘源的配置代碼，而客戶代碼里卻沒有相應(yīng)代碼。從參考手冊(cè)相關(guān)描述來看，只有USART時(shí)鐘源選為HSI或LSE時(shí)才具備將芯片從STOP模式喚醒的功能。問題很可能出在這里，讓客戶在USART的配置函數(shù)里加上如下語句后再測(cè)試，結(jié)果一切正常了。 /* Configure the HSI as USART clock */ RCC_USARTCLKConfig(RCC_USART2CLK_HSI); 顯然，問題正是出在這個(gè)USART2的時(shí)鐘的配置上。下圖是STM32F072芯片的RCC時(shí)鐘樹�？梢钥闯�，USART可以有四個(gè)時(shí)鐘源。即PCLK/SYSCLK/HSI/LSE. 
現(xiàn)在客戶代碼里沒有對(duì)USART2的時(shí)鐘源做明確配置，只是做了時(shí)鐘的使能配置。不難理解MCU硬件使用了默認(rèn)值，那默認(rèn)時(shí)鐘源是哪一個(gè)呢？ 
從相關(guān)寄存器位可以得知，USART2的默認(rèn)時(shí)鐘源是PCLK，既不是HSI也不是LSE。難怪客戶死活沒法利用USART中斷將STOP模式下的STM32F072喚醒了。 可能很多人用過STM32F1系列芯片，相比之下，STM32F0系列在時(shí)鐘這塊跟F1存在諸多不一樣的地方，使用時(shí)要注意。
ST官方針對(duì)各系列的MCU都有較為完善參考固件庫(kù)，針對(duì)各外設(shè)的應(yīng)用多有例程供使用者學(xué)習(xí)參考和使用。那些參考庫(kù)代碼整體上講都有很高的參考和使用價(jià)值。尤其各工程項(xiàng)目里的有關(guān)配置流程值得借鑒使用。 我這里順便多聊幾句。如果你對(duì)官方例程項(xiàng)目里的部分代碼不確定是否有用或是否需要時(shí)建議不要輕易舍棄不用，先留著，哪怕注釋在那兒也好，至少是個(gè)提醒。最好借助于參考手冊(cè)和實(shí)驗(yàn)弄明白怎么回事。經(jīng)常有人在并不了解部分代碼功能的前提下，直接棄掉不用而給自己帶來不必要的麻煩。 比方前面談到的32F072 USART2喚醒STOP模式的問題，參考例程里其實(shí)就有相關(guān)USART時(shí)鐘源配置代碼，而客戶工程師在自己代碼里卻不假思索地直接拿掉了。 記得前不久有位工程師利用STM32F3系列的AD功能，訴說AD取得的結(jié)果總是不準(zhǔn)，總是找不到原因。跟著他一起看了硬件線路再看他的軟件配置代碼，結(jié)果發(fā)現(xiàn)有關(guān)AD校準(zhǔn)相關(guān)代碼根本就沒有。問他為什么不參考官方例程代碼來寫，他說覺得相關(guān)代碼沒用就拿掉了。 我還依稀記得幾年前有個(gè)北方工程師用STM32F1系列開發(fā)產(chǎn)品，項(xiàng)目開發(fā)前期芯片工主頻較低，各個(gè)功能都好好的，后來發(fā)現(xiàn)將系統(tǒng)時(shí)鐘調(diào)高到72M時(shí)出現(xiàn)很多奇怪的問題，把時(shí)鐘調(diào)低到一定數(shù)值又運(yùn)行正常。跟他一起問來問去，結(jié)果發(fā)現(xiàn)有關(guān)與指令預(yù)取及FLASH訪問等待周期的配置代碼被抹掉了【那是基于早期的固件庫(kù)代碼】。 還有，官方庫(kù)代碼里的有些代碼配置流程也不是亂來的，其先后順序可能影響最后的結(jié)果。還有就不多說了，拋磚引玉，算是對(duì)同仁的一些提醒。愿各位在開發(fā)過程中少點(diǎn)折騰之苦，多些順暢。整理：MilerShao
近日某工程師電話我說他在使用STM32F072芯片開發(fā)產(chǎn)品，發(fā)現(xiàn)USART2中斷無法從將芯片從STOP模式喚醒。他說也是折騰幾天了，翻來覆去都查不出問題所在，懷疑芯片是否真具有該功能。因?yàn)橹坝衅渌蛻粲玫皆摴δ�，我告知確實(shí)可行，建議他再耐心檢查 一天后我們?cè)俅尉W(wǎng)絡(luò)聯(lián)絡(luò)，告知仍然無法實(shí)現(xiàn)USART喚醒STOP狀態(tài)。我查看其相關(guān)程序代碼，代碼是基于STM32F0系列傳統(tǒng)固件庫(kù)編寫的。將客戶代碼結(jié)合32f0系列的技術(shù)參考手冊(cè)來看了兩遍并未發(fā)現(xiàn)什么明顯問題。 因?yàn)镾TM32F0系列官方固件庫(kù)里有相關(guān)例程項(xiàng)目，打開官方例程代碼和參考手冊(cè)比對(duì)時(shí)，有個(gè)地方引起了我的注意。那就是USART是時(shí)鐘源問題。
我注意到ST官方例程里在配置USART的喚醒功能時(shí)，有條關(guān)于USART時(shí)鐘源的配置代碼，而客戶代碼里卻沒有相應(yīng)代碼。從參考手冊(cè)相關(guān)描述來看，只有USART時(shí)鐘源選為HSI或LSE時(shí)才具備將芯片從STOP模式喚醒的功能。問題很可能出在這里，讓客戶在USART的配置函數(shù)里加上如下語句后再測(cè)試，結(jié)果一切正常了。 /* Configure the HSI as USART clock */ RCC_USARTCLKConfig(RCC_USART2CLK_HSI); 顯然，問題正是出在這個(gè)USART2的時(shí)鐘的配置上。下圖是STM32F072芯片的RCC時(shí)鐘樹�？梢钥闯�，USART可以有四個(gè)時(shí)鐘源。即PCLK/SYSCLK/HSI/LSE.
現(xiàn)在客戶代碼里沒有對(duì)USART2的時(shí)鐘源做明確配置，只是做了時(shí)鐘的使能配置。不難理解MCU硬件使用了默認(rèn)值，那默認(rèn)時(shí)鐘源是哪一個(gè)呢？
從相關(guān)寄存器位可以得知，USART2的默認(rèn)時(shí)鐘源是PCLK，既不是HSI也不是LSE。難怪客戶死活沒法利用USART中斷將STOP模式下的STM32F072喚醒了。 可能很多人用過STM32F1系列芯片，相比之下，STM32F0系列在時(shí)鐘這塊跟F1存在諸多不一樣的地方，使用時(shí)要注意。
ST官方針對(duì)各系列的MCU都有較為完善參考固件庫(kù)，針對(duì)各外設(shè)的應(yīng)用多有例程供使用者學(xué)習(xí)參考和使用。那些參考庫(kù)代碼整體上講都有很高的參考和使用價(jià)值。尤其各工程項(xiàng)目里的有關(guān)配置流程值得借鑒使用。 我這里順便多聊幾句。如果你對(duì)官方例程項(xiàng)目里的部分代碼不確定是否有用或是否需要時(shí)建議不要輕易舍棄不用，先留著，哪怕注釋在那兒也好，至少是個(gè)提醒。最好借助于參考手冊(cè)和實(shí)驗(yàn)弄明白怎么回事。經(jīng)常有人在并不了解部分代碼功能的前提下，直接棄掉不用而給自己帶來不必要的麻煩。 比方前面談到的32F072 USART2喚醒STOP模式的問題，參考例程里其實(shí)就有相關(guān)USART時(shí)鐘源配置代碼，而客戶工程師在自己代碼里卻不假思索地直接拿掉了。 記得前不久有位工程師利用STM32F3系列的AD功能，訴說AD取得的結(jié)果總是不準(zhǔn)，總是找不到原因。跟著他一起看了硬件線路再看他的軟件配置代碼，結(jié)果發(fā)現(xiàn)有關(guān)AD校準(zhǔn)相關(guān)代碼根本就沒有。問他為什么不參考官方例程代碼來寫，他說覺得相關(guān)代碼沒用就拿掉了。 我還依稀記得幾年前有個(gè)北方工程師用STM32F1系列開發(fā)產(chǎn)品，項(xiàng)目開發(fā)前期芯片工主頻較低，各個(gè)功能都好好的，后來發(fā)現(xiàn)將系統(tǒng)時(shí)鐘調(diào)高到72M時(shí)出現(xiàn)很多奇怪的問題，把時(shí)鐘調(diào)低到一定數(shù)值又運(yùn)行正常。跟他一起問來問去，結(jié)果發(fā)現(xiàn)有關(guān)與指令預(yù)取及FLASH訪問等待周期的配置代碼被抹掉了【那是基于早期的固件庫(kù)代碼】。 還有，官方庫(kù)代碼里的有些代碼配置流程也不是亂來的，其先后順序可能影響最后的結(jié)果。還有就不多說了，拋磚引玉，算是對(duì)同仁的一些提醒。愿各位在開發(fā)過程中少點(diǎn)折騰之苦，多些順暢。 | 
