近日某工程師電話我說他在使用STM32F072芯片開發產品，發現USART2中斷無法從將芯片從STOP模式喚醒。他說也是折騰幾天了，翻來覆去都查不出問題所在，懷疑芯片是否真具有該功能。因為之前有其它客戶用到該功能，我告知確實可行，建議他再耐心檢查

一天后我們再次網絡聯絡，告知仍然無法實現USART喚醒STOP狀態。我查看其相關程序代碼，代碼是基于STM32F0系列傳統固件庫編寫的。將客戶代碼結合32f0系列的技術參考手冊來看了兩遍并未發現什么明顯問題。

因為STM32F0系列官方固件庫里有相關例程項目，打開官方例程代碼和參考手冊比對時，有個地方引起了我的注意。那就是USART是時鐘源問題。

我注意到ST官方例程里在配置USART的喚醒功能時，有條關于USART時鐘源的配置代碼，而客戶代碼里卻沒有相應代碼。從參考手冊相關描述來看，只有USART時鐘源選為HSI或LSE時才具備將芯片從STOP模式喚醒的功能。問題很可能出在這里，讓客戶在USART的配置函數里加上如下語句后再測試，結果一切正常了。

/* Configure the HSI as USART clock */

RCC_USARTCLKConfig(RCC_USART2CLK_HSI);

顯然，問題正是出在這個USART2的時鐘的配置上。下圖是STM32F072芯片的RCC時鐘樹。可以看出，USART可以有四個時鐘源。即PCLK/SYSCLK/HSI/LSE.

現在客戶代碼里沒有對USART2的時鐘源做明確配置，只是做了時鐘的使能配置。不難理解MCU硬件使用了默認值，那默認時鐘源是哪一個呢？

從相關寄存器位可以得知，USART2的默認時鐘源是PCLK，既不是HSI也不是LSE。難怪客戶死活沒法利用USART中斷將STOP模式下的STM32F072喚醒了。

可能很多人用過STM32F1系列芯片，相比之下，STM32F0系列在時鐘這塊跟F1存在諸多不一樣的地方，使用時要注意。

ST官方針對各系列的MCU都有較為完善參考固件庫，針對各外設的應用多有例程供使用者學習參考和使用。那些參考庫代碼整體上講都有很高的參考和使用價值。尤其各工程項目里的有關配置流程值得借鑒使用。

我這里順便多聊幾句。如果你對官方例程項目里的部分代碼不確定是否有用或是否需要時建議不要輕易舍棄不用，先留著，哪怕注釋在那兒也好，至少是個提醒。最好借助于參考手冊和實驗弄明白怎么回事。經常有人在并不了解部分代碼功能的前提下，直接棄掉不用而給自己帶來不必要的麻煩。

比方前面談到的32F072 USART2喚醒STOP模式的問題，參考例程里其實就有相關USART時鐘源配置代碼，而客戶工程師在自己代碼里卻不假思索地直接拿掉了。

記得前不久有位工程師利用STM32F3系列的AD功能，訴說AD取得的結果總是不準，總是找不到原因。跟著他一起看了硬件線路再看他的軟件配置代碼，結果發現有關AD校準相關代碼根本就沒有。問他為什么不參考官方例程代碼來寫，他說覺得相關代碼沒用就拿掉了。

我還依稀記得幾年前有個北方工程師用STM32F1系列開發產品，項目開發前期芯片工主頻較低，各個功能都好好的，后來發現將系統時鐘調高到72M時出現很多奇怪的問題，把時鐘調低到一定數值又運行正常。跟他一起問來問去，結果發現有關與指令預取及FLASH訪問等待周期的配置代碼被抹掉了【那是基于早期的固件庫代碼】。

還有，官方庫代碼里的有些代碼配置流程也不是亂來的，其先后順序可能影響最后的結果。還有就不多說了，拋磚引玉，算是對同仁的一些提醒。愿各位在開發過程中少點折騰之苦，多些順暢。整理：MilerShao

近日某工程師電話我說他在使用STM32F072芯片開發產品，發現USART2中斷無法從將芯片從STOP模式喚醒。他說也是折騰幾天了，翻來覆去都查不出問題所在，懷疑芯片是否真具有該功能。因為之前有其它客戶用到該功能，我告知確實可行，建議他再耐心檢查

一天后我們再次網絡聯絡，告知仍然無法實現USART喚醒STOP狀態。我查看其相關程序代碼，代碼是基于STM32F0系列傳統固件庫編寫的。將客戶代碼結合32f0系列的技術參考手冊來看了兩遍并未發現什么明顯問題。

因為STM32F0系列官方固件庫里有相關例程項目，打開官方例程代碼和參考手冊比對時，有個地方引起了我的注意。那就是USART是時鐘源問題。

我注意到ST官方例程里在配置USART的喚醒功能時，有條關于USART時鐘源的配置代碼，而客戶代碼里卻沒有相應代碼。從參考手冊相關描述來看，只有USART時鐘源選為HSI或LSE時才具備將芯片從STOP模式喚醒的功能。問題很可能出在這里，讓客戶在USART的配置函數里加上如下語句后再測試，結果一切正常了。

/* Configure the HSI as USART clock */

RCC_USARTCLKConfig(RCC_USART2CLK_HSI);

顯然，問題正是出在這個USART2的時鐘的配置上。下圖是STM32F072芯片的RCC時鐘樹。可以看出，USART可以有四個時鐘源。即PCLK/SYSCLK/HSI/LSE.

現在客戶代碼里沒有對USART2的時鐘源做明確配置，只是做了時鐘的使能配置。不難理解MCU硬件使用了默認值，那默認時鐘源是哪一個呢？

從相關寄存器位可以得知，USART2的默認時鐘源是PCLK，既不是HSI也不是LSE。難怪客戶死活沒法利用USART中斷將STOP模式下的STM32F072喚醒了。

可能很多人用過STM32F1系列芯片，相比之下，STM32F0系列在時鐘這塊跟F1存在諸多不一樣的地方，使用時要注意。

ST官方針對各系列的MCU都有較為完善參考固件庫，針對各外設的應用多有例程供使用者學習參考和使用。那些參考庫代碼整體上講都有很高的參考和使用價值。尤其各工程項目里的有關配置流程值得借鑒使用。

我這里順便多聊幾句。如果你對官方例程項目里的部分代碼不確定是否有用或是否需要時建議不要輕易舍棄不用，先留著，哪怕注釋在那兒也好，至少是個提醒。最好借助于參考手冊和實驗弄明白怎么回事。經常有人在并不了解部分代碼功能的前提下，直接棄掉不用而給自己帶來不必要的麻煩。

比方前面談到的32F072 USART2喚醒STOP模式的問題，參考例程里其實就有相關USART時鐘源配置代碼，而客戶工程師在自己代碼里卻不假思索地直接拿掉了。

記得前不久有位工程師利用STM32F3系列的AD功能，訴說AD取得的結果總是不準，總是找不到原因。跟著他一起看了硬件線路再看他的軟件配置代碼，結果發現有關AD校準相關代碼根本就沒有。問他為什么不參考官方例程代碼來寫，他說覺得相關代碼沒用就拿掉了。

我還依稀記得幾年前有個北方工程師用STM32F1系列開發產品，項目開發前期芯片工主頻較低，各個功能都好好的，后來發現將系統時鐘調高到72M時出現很多奇怪的問題，把時鐘調低到一定數值又運行正常。跟他一起問來問去，結果發現有關與指令預取及FLASH訪問等待周期的配置代碼被抹掉了【那是基于早期的固件庫代碼】。

還有，官方庫代碼里的有些代碼配置流程也不是亂來的，其先后順序可能影響最后的結果。還有就不多說了，拋磚引玉，算是對同仁的一些提醒。愿各位在開發過程中少點折騰之苦，多些順暢。