芯耀
746
問題描述
有客戶反饋，他最近在做一個項目用到 STM32L051 這款單片機(jī)。平常的 USART 串口傳輸是 8 位數(shù)據(jù)，但是他的項目需要用串口傳輸 9 位數(shù)據(jù)。當(dāng)設(shè)置為 8 位數(shù)據(jù)時，串口響應(yīng)中斷正常。但是，當(dāng)設(shè)置為 9 位數(shù)據(jù)時，串口就不產(chǎn)生中斷了。USART2 的 ISR 寄存器 RXNE 位被置1，RDR 寄存器接收到了數(shù)據(jù)，就是不產(chǎn)生中斷，數(shù)據(jù)也讀不出來。請問是不是 HAL 庫函數(shù)哪里出了 bug？另外，客戶還補(bǔ)充說，使用 STM32CubeMX 進(jìn)行配置并創(chuàng)建的工程代碼。
問題分析
客戶表達(dá)的意思就是說，他使用 8 位數(shù)據(jù)格式進(jìn)行 USART 通信時一切 OK，UART 中斷也正常，說明人家對這個模塊的使用還是熟悉的。但使用 9 位數(shù)據(jù)格式時發(fā)生異常了。大致意思是說使用 9 位數(shù)據(jù)格式后數(shù)據(jù)貌似也收到了，RXNE 也置位了，就是基本的中斷沒法產(chǎn)生。落腳點就是懷疑 ST 的相關(guān) HAL 庫函數(shù)是不是有 Bug。
說實話，本人之前也沒有使用 USART 的 9 位數(shù)據(jù)格式做過工程或驗證測試?，F(xiàn)在客戶的重點是懷疑庫的 Bug 問題。先打開相應(yīng)庫函數(shù)，掃了幾眼并未能看出代碼有什么不妥的地方。然后，打開手冊，看看 L05X 系列芯片的 USART 到底支不支持 9 位數(shù)據(jù)格式的傳輸。
問題驗證
既然這樣，手冊明確了芯片的 USART 支持 9 位數(shù)據(jù)格式。趕緊找一塊跟客戶同一個系列的開發(fā)板 32L053DISCOVERY 做針對性的測試驗證。
因為客戶使用的是 USART2，所以我開始也是使用 STM32L051 的 USART2 進(jìn)行測試，巧的是，測試結(jié)果似乎不如人意，接收都成問題。結(jié)合方才閱讀各個系列的手冊得知，STM32 系列的 USART 都支持 9bit 數(shù)據(jù)格式。剛好手邊有塊 STM32G4 系列的板，任意選了個片上的USART 進(jìn)行測試，也是采用中斷方式進(jìn)行收發(fā)。這次很順利，收發(fā)正常。這個驗證可以初步肯定我們的相關(guān)庫代碼是沒問題的，因為 HAL 庫針對公共功能的代碼是一樣的。
然后我再回過來基于 32L0538DISCOVERY 開發(fā)板進(jìn)行驗證，發(fā)現(xiàn)原來是這塊開發(fā)板上的 USART2 所使用的GPIO 已作他用，有兩個跳線焊盤沒有連接，所以并沒有實際連接到排針上，所以使用前檢查一下電路圖很重要。這次我干脆就用其兄弟 USART1 來進(jìn)行測試，這次非常順利。同時也比較了USART1 和 USART2 的特性，這個地方二者沒有差別。斷定問題出在客戶的配置或應(yīng)用代碼上，我們的庫沒有問題.
驗證演示
相信并不是很多人使用過這個 USART 的 9 位數(shù)據(jù)通信格式，應(yīng)用或許有點小眾。越是涉及這種相對小眾的應(yīng)用功能，我們在開發(fā)過程若遇到不順時，往往可能懷疑自己用得對不對，或者說這玩意到底能不能用?；谶@個想法，我也順便將 STM32 USART 9 位數(shù)據(jù)格式基于 HAL 庫的實現(xiàn)分享出來，包括中斷方式和 DMA 方式。
問題小結(jié)
這里基于客戶的咨詢，將整個驗證測試過程整理分享出來，希望給未來首次涉及相關(guān)應(yīng)用的同仁有個參考，并提供強(qiáng)有力的開發(fā)信心。
