最近某項目需要用到USB與CAN：

拿到這樣的需求，我們當然是先得保證通訊正常。于是我找了一個USB例程與一個CAN例程，分別調試驗證。

經過幾番折騰已經保證了USB與上位機能正常通訊了，也能保證了CAN的正常收發（拿了兩塊開發板做驗證）。

兩頭都沒有問題了，再加上一些數據處理就差不多完成了。USB與CAN我都是第一次用，沒想到那么順利，美滋滋，正準備放松的時候，問題就來了。這是一個整體的東西，最終都要把這兩部分集合起來吧。

我把CAN工程里關于CAN的部分移到USB工程里，這時候CAN竟然用不了了。這時候我就開始在懷疑自己是不是手賤誤刪了哪里了，于是重新來一遍，發現還是不行。

查了代碼很久也沒找出什么錯誤了，于是決定先不找錯誤了，進度要緊，這時候覺得應該是工程哪里有問題了，先想其它辦法避過這個問題。

于是乎我就換著來，我把USB的工程里關于USB的部分移到CAN工程里。大家猜一猜發生了什么？USB竟然打都打不開！要炸了。。但是這時候已經很明確肯定不是移植問題了。CAN部分首先想到了波特率是不是對不上了，USB部分首先想到USB的時鐘是從哪來的，之前沒用過也沒仔細看。帶著這兩個問題去查看了參考手冊與代碼，果然，STM32F429的USB的時鐘還真有點特殊（不知道其它芯片是不是也是這樣），其來自于PLL輸出，而不是我們熟知的APB1、APB2：

從時鐘樹中我們可以看出：（1）的輸出是系統時鐘，（2）的輸出是USB時鐘。相關公式：

當然（2）的輸出不僅僅是給USB提供時鐘，還給RNG與SDIO提供時鐘：

這一部分對應的代碼在system_stm32f4xx.c中。下面看看USB工程、CAN工程中該文件的差別：

可見，問題找出來了。在USB工程中，CAN通訊不正常是因為系統時鐘降為168MHz，導致APB1時鐘變為42MHz，而代碼中是用APB1=45MHz來計算CAN的波特率的，所以導致波特率對應不上導致CAN通訊錯誤。

在CAN工程中，系統時鐘為180MHz，USB OTG FS時鐘變為51MHz，超過了正常的48MHz，導致USB不能正常工作。

所以，每當用到USB，都得單獨配置PLLCLK = 168MHz了，這樣的話其他外設可能得改變原有的配置，比如這里的CAN就得用APB1=42MHz來計算波特率了，否則就會出錯。這很不方便。。

正如野火火哥說的，這是ST的一個奇葩設計。

所以，大家以后再使用USB的時候當心這個陷阱！