客户在使用 STM32G070 的时候，KEIL MDK 为编译工具，当编译优化选项设置为Level0 的时候，程序会出现 Hard Fault 异常，而当编译优化选项设置为 Level1 的时候，则程序运行正常。

表面上看，这似乎是 KEIL MDK 的问题，通过分析，导致这个问题的本质原因是内存地址没有对齐引起的，下面章节将详细分析该问题的来龙去脉以及解决方法。

根据客户的反馈，引起问题的代码很简单，客户定义了几个全局数组，在主程序中访问这几个数组就会出现 Hard Fault 异常，参考代码如下。

把客户提供的代码片段移植到 NUCLEO-G070RB 开发板上，问题很容易就复现了，代码本身功能简单，写法上也没有错误，所以从代码片段本身上看，无法确定问题出在哪里，通过 KEIL 调试器，在汇编窗口单步调试下，最终发现导致 HardFault 异常的语句为下图所示语句。

根据单步调试得知出现问题的语句为 LDR 指令，参考 Cortex M0 编程手册 PM0223 得知 LDR 指令的作用是从内存地址中加载一个 WORD 数据到目的寄存器 Rt 中，其中内存地址根据 Rn 或者 SP 寄存器的值以及立即数 imm 得到。

根据指令的描述，使用 LDR 指令的时候，通过 Rn 和 imm 计算得到的内存地址必须是读取字节数的倍数，LDR 每次读取一个 WORD，所以使用 LDR 指令时，内存地址必须 4字节对齐。如果地址没有对齐，则会导致 HardFault 异常。

结合 LDR 指令的描述，在调试状态下，通过查看寄存器值，图 2 出错语句中根据 Rn和 imm 计算得到的内存地址为 R0=0x2000000B,imm=4 所以内存地址为 0x2000000F,很显然这个地址不是 4 字节对齐的。

而当我们改变编译优化选项为 Level1 时，得到的内存地址为R0=0x20000000,imm=0x04 显然这个地址是按照 4 字节对齐的，所以这种情况下是不会出现 HardFault 异常的，印证了客户的问题现象。

通过上一节的分析，明确了导致该问题的本质原因是内存地址没有对齐，这个内存地址实际上是代码中定义的全局变量 g_curPlaySound_app 指向的地址，也就是全局数组变量 SoundFile 的地址，在编译器不同的优化选项下，分配给 SoundFile 变量的地址是不一样的，在本案例中，编译优化选项 Level0 条件下，SoundFile 分配的地址没有按照WORD 对齐，而在优化选项 Level1 条件下，SoundFile 分配的地址是 WORD 对齐，所以在两种优化选项下，出现了不一样的运行结果。

所以要保证程序不出错，当通过指针访问变量的时候，要确保指针指向的地址是 4 字节对齐的，在 Keil 环境下，可以通过__attribute__((aligned (4))) 关键字实现，如下图所示，通过该关键字，对齐了地址，也就不会出现 HardFault 异常了。

图6 确保地址对齐

地址未对齐是嵌入式系统中容易忽视的一个细节，忽视这点往往会导致一些奇怪的问题，所以在开发过程中，注意这些细节还是很有必要的。

参考文献：PM0223 Programming maual