经验分享 | STM32C0 HAL 库的 SPI 驱动导致的 Hardfault 问题分析

[复制链接]

STMCU小助手发布时间：2025-8-26 16:50

技术帖
文章封面:
文章简介:	客户在项目开发中使用 STM32C071 作为主控 MCU ，驱动代码使用了版本STM32Cube_FW_C0_V1.2.0，应用程序调用 SPI HAL API 与 NFC 模块通信，SPI 工作在 Master 模式，调用 HAL_SPI_Transmit 函数发送数据的时候，出现 Hardfault 现象，同时客户反馈同样的应用程序代码在 STM32G0 平台上，没有出现类似的问题，客户不得其解。根据客户反馈的现象，本文分析其原因以及解决方法。

1. 问题描述
客户在项目开发中使用 STM32C071 作为主控 MCU ，驱动代码使用了版本STM32Cube_FW_C0_V1.2.0，应用程序调用 SPI HAL API 与 NFC 模块通信，SPI 工作在 Master 模式，调用 HAL_SPI_Transmit 函数发送数据的时候，出现 Hardfault 现象，同时客户反馈同样的应用程序代码在 STM32G0 平台上，没有出现类似的问题，客户不得其解。根据客户反馈的现象，本文分析其原因以及解决方法。

2. 问题原因
移植客户调用 SPI HAL 的代码片段到 NUCLEO_C031C6 开发板上，复现了同样的问题，经过单步调试跟踪，定位到下面语句导致了 Hardfault，如下图所示。

图1. 导致 Hardfault 的语句

跟踪汇编代码，导致 Hardfault 的指令是 LDRH，查看 Cortex-M0+编程手册，明确了目的地址不对齐，会导致 Hardfault 异常，而 LDRH 访问的是 16 位数据，所以其访问的地址必须按照双字节对齐，也就是说 hspi->pTxBuffer 的地址必须是双字节对齐。查看变量值，hspi->pTxBuffer 的地址为 0x2000014B,显然不是一个符合对齐规则的地址。

图2. Address alignment

那么问题来了，同样应用层代码，为何在 STM32G0 平台上没有出现问题，通过比较 SPI HAL 库驱动代码，STM32C0 的驱动对数据类型进行了强制转换，该操作导致了问题。

图3. STM32G0 SPI HAL

图4. STM32C0 SPI HAL

所以,基于 STM32C0 的这部分代码是存在隐患的，如果应用代码传递的数据 buffer 地址不是双字节对齐，就会导致这个问题。

3. 解决方案
针对问题原因，这里有两种解决方案。

第一种方案，要求应用程序传递的数据 Buffer 地址按照双字节对齐，这个实现起来很容易，不同的编译器有不同的关键字设置变量地址对齐属性，如 KEIL 可以使用__attribute__((aligned(2))) 关键字即可保证变量地址是双字节对齐的。

第二种方案，微调 SPI HAL 代码，避免地址不对齐，参考代码如下。

图5. 地址对齐

因为客户的应用代码有多出调用 SPI HAL 的语句，没法保证每个地方传递的数据 Buffer 地址都是按照双字节对齐的，所以最终采用了第二种方案解决其问题。

4. 注意事项
STM32C0 SPI HAL 代码的隐患导致了该问题，在使用 SPI HAL 的过程中需要注意。
————————————————
\