STM32C0 HAL 庫的 SPI 驅(qū)動導(dǎo)致的 Hardfault 問題分析

1、問題描述

客戶在項目開發(fā)中使用 STM32C071 作為主控 MCU，驅(qū)動代碼使用了版本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ù)的時候，出現(xiàn) Hardfault 現(xiàn)象，同時客戶反饋同樣的應(yīng)用程序代碼在 STM32G0 平臺上，沒有出現(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+編程手冊，明確了目的地址不對齊，會導(dǎo)致 Hardfault 異常，而 LDRH 訪問的是 16 位數(shù)據(jù)，所以其訪問的地址必須按照雙字節(jié)對齊，也就是說 hspi->pTxBuffer 的地址必須是雙字節(jié)對齊。查看變量值，hspi->pTxBuffer 的地址為 0x2000014B,顯然不是一個符合對齊規(guī)則的地址。

那么問題來了，同樣應(yīng)用層代碼，為何在 STM32G0 平臺上沒有出現(xiàn)問題，通過比較 SPIHAL 庫驅(qū)動代碼，STM32C0 的驅(qū)動對數(shù)據(jù)類型進行了強制轉(zhuǎn)換，該操作導(dǎo)致了問題。所以,基于 STM32C0 的這部分代碼是存在隱患的，如果應(yīng)用代碼傳遞的數(shù)據(jù) buffer 地址不是雙字節(jié)對齊，就會導(dǎo)致這個問題。

3、解決方案

針對問題原因，這里有兩種解決方案。

第一種方案，要求應(yīng)用程序傳遞的數(shù)據(jù) Buffer 地址按照雙字節(jié)對齊，這個實現(xiàn)起來很容易，不同的編譯器有不同的關(guān)鍵字設(shè)置變量地址對齊屬性，如 KEIL 可以使用__attribute__((aligned(2))) 關(guān)鍵字即可保證變量地址是雙字節(jié)對齊的。

第二種方案，微調(diào) SPI HAL 代碼，避免地址不對齊因為客戶的應(yīng)用代碼有多出調(diào)用 SPI HAL 的語句，沒法保證每個地方傳遞的數(shù)據(jù) Buffer 地址都是按照雙字節(jié)對齊的，所以最終采用了第二種方案解決其問題。