拿到這樣的需求,我們當(dāng)然是先得保證通訊正常。于是我找了一個USB例程與一個CAN例程,分別調(diào)試驗證。
經(jīng)過幾番折騰已經(jīng)保證了USB與上位機(jī)能正常通訊了,也能保證了CAN的正常收發(fā)(拿了兩塊開發(fā)板做驗證)。
兩頭都沒有問題了,再加上一些數(shù)據(jù)處理就差不多完成了。USB與CAN我都是第一次用,沒想到那么順利,美滋滋,正準(zhǔn)備放松的時候,問題就來了。這是一個整體的東西,最終都要把這兩部分集合起來吧。
我把CAN工程里關(guān)于CAN的部分移到USB工程里,這時候CAN竟然用不了了。這時候我就開始在懷疑自己是不是手賤誤刪了哪里了,于是重新來一遍,發(fā)現(xiàn)還是不行。
查了代碼很久也沒找出什么錯誤了,于是決定先不找錯誤了,進(jìn)度要緊,這時候覺得應(yīng)該是工程哪里有問題了,先想其它辦法避過這個問題。
于是乎我就換著來,我把USB的工程里關(guān)于USB的部分移到CAN工程里。大家猜一猜發(fā)生了什么?USB竟然打都打不開!要炸了。。但是這時候已經(jīng)很明確肯定不是移植問題了。CAN部分首先想到了波特率是不是對不上了,USB部分首先想到USB的時鐘是從哪來的,之前沒用過也沒仔細(xì)看。帶著這兩個問題去查看了參考手冊與代碼,果然,STM32F429的USB的時鐘還真有點特殊(不知道其它芯片是不是也是這樣),其來自于PLL輸出,而不是我們熟知的APB1、APB2:
從時鐘樹中我們可以看出:(1)的輸出是系統(tǒng)時鐘,(2)的輸出是USB時鐘。相關(guān)公式:
當(dāng)然(2)的輸出不僅僅是給USB提供時鐘,還給RNG與SDIO提供時鐘:
這一部分對應(yīng)的代碼在system_stm32f4xx.c中。下面看看USB工程、CAN工程中該文件的差別:
可見,問題找出來了。在USB工程中,CAN通訊不正常是因為系統(tǒng)時鐘降為168MHz,導(dǎo)致APB1時鐘變?yōu)?2MHz,而代碼中是用APB1=45MHz來計算CAN的波特率的,所以導(dǎo)致波特率對應(yīng)不上導(dǎo)致CAN通訊錯誤。
在CAN工程中,系統(tǒng)時鐘為180MHz,USB OTG FS時鐘變?yōu)?1MHz,超過了正常的48MHz,導(dǎo)致USB不能正常工作。
所以,每當(dāng)用到USB,都得單獨配置PLLCLK = 168MHz了,這樣的話其他外設(shè)可能得改變原有的配置,比如這里的CAN就得用APB1=42MHz來計算波特率了,否則就會出錯。這很不方便。。
正如野火火哥說的,這是ST的一個奇葩設(shè)計。
所以,大家以后再使用USB的時候當(dāng)心這個陷阱!
-
usb
+關(guān)注
關(guān)注
60文章
7976瀏覽量
265514 -
CAN
+關(guān)注
關(guān)注
57文章
2764瀏覽量
464110 -
STM32
+關(guān)注
關(guān)注
2270文章
10921瀏覽量
356995
發(fā)布評論請先 登錄
相關(guān)推薦
評論