391
1、問題描述
客戶在項(xiàng)目開發(fā)中使用 STM32C071 作為主控 MCU，驅(qū)動(dòng)代碼使用了版本STM32Cube_FW_C0_V1.2.0，應(yīng)用程序調(diào)用 SPI HAL API 與 NFC 模塊通信，SPI 工作在Master 模式，調(diào)用 HAL_SPI_Transmit 函數(shù)發(fā)送數(shù)據(jù)的時(shí)候，出現(xiàn) Hardfault 現(xiàn)象，同時(shí)客戶反饋同樣的應(yīng)用程序代碼在 STM32G0 平臺(tái)上，沒有出現(xiàn)類似的問題，客戶不得其解。根據(jù)客戶反饋的現(xiàn)象，本文分析其原因以及解決方法。
2、問題原因
移植客戶調(diào)用 SPI HAL 的代碼片段到 NUCLEO_C031C6 開發(fā)板上，復(fù)現(xiàn)了同樣的問題，經(jīng)過單步調(diào)試跟蹤，跟蹤匯編代碼，導(dǎo)致 Hardfault 的指令是 LDRH，查看 Cortex-M0+編程手冊(cè)，明確了目的地址不對(duì)齊，會(huì)導(dǎo)致 Hardfault 異常，而 LDRH 訪問的是 16 位數(shù)據(jù)，所以其訪問的地址必須按照雙字節(jié)對(duì)齊，也就是說 hspi->pTxBuffer 的地址必須是雙字節(jié)對(duì)齊。查看變量值，hspi->pTxBuffer 的地址為 0x2000014B,顯然不是一個(gè)符合對(duì)齊規(guī)則的地址。
那么問題來了，同樣應(yīng)用層代碼，為何在 STM32G0 平臺(tái)上沒有出現(xiàn)問題，通過比較 SPIHAL 庫(kù)驅(qū)動(dòng)代碼，STM32C0 的驅(qū)動(dòng)對(duì)數(shù)據(jù)類型進(jìn)行了強(qiáng)制轉(zhuǎn)換，該操作導(dǎo)致了問題。所以,基于 STM32C0 的這部分代碼是存在隱患的，如果應(yīng)用代碼傳遞的數(shù)據(jù) buffer 地址不是雙字節(jié)對(duì)齊，就會(huì)導(dǎo)致這個(gè)問題。
3、解決方案
針對(duì)問題原因，這里有兩種解決方案。
第一種方案，要求應(yīng)用程序傳遞的數(shù)據(jù) Buffer 地址按照雙字節(jié)對(duì)齊，這個(gè)實(shí)現(xiàn)起來很容易，不同的編譯器有不同的關(guān)鍵字設(shè)置變量地址對(duì)齊屬性，如 KEIL 可以使用__attribute__((aligned(2))) 關(guān)鍵字即可保證變量地址是雙字節(jié)對(duì)齊的。
第二種方案，微調(diào) SPI HAL 代碼，避免地址不對(duì)齊因?yàn)榭蛻舻膽?yīng)用代碼有多出調(diào)用 SPI HAL 的語句，沒法保證每個(gè)地方傳遞的數(shù)據(jù) Buffer 地址都是按照雙字節(jié)對(duì)齊的，所以最終采用了第二種方案解決其問題。
