1. 概述
客户在使用 STM32G070 的时候，KEIL MDK 为编译工具，当编译优化选项设置为Level0 的时候，程序会出现 Hard Fault 异常，而当编译优化选项设置为 Level1 的时候，则程序运行正常。表面上看，这似乎是 KEIL MDK 的问题，通过分析，导致这个问题的本质原因是内存地址没有对齐引起的，下面章节将详细分析该问题的来龙去脉以及解决方法。
2. 问题描述与分析
根据客户的反馈，引起问题的代码很简单，客户定义了几个全局数组，在主程序中访问这几个数组就会出现 Hard Fault 异常，参考代码如下。
图1.导致异常的代码片段
把客户提供的代码片段移植到 NUCLEO-G070RB 开发板上，问题很容易就复现了，代码本身功能简单，写法上也没有错误，所以从代码片段本身上看，无法确定问题出在哪里，通过 KEIL 调试器，在汇编窗口单步调试下，最终发现导致 HardFault 异常的语句为下图所示语句。
图2.导致 Hard Fault 异常的语句
根据单步调试得知出现问题的语句为 LDR 指令，参考 Cortex M0 编程手册 PM0223 得知 LDR 指令的作用是从内存地址中加载一个 WORD 数据到目的寄存器 Rt 中，其中内存地址根据 Rn 或者 SP 寄存器的值以及立即数 imm 得到。
图3.LDR 指令描述
根据指令的描述，使用 LDR 指令的时候，通过 Rn 和 imm 计算得到的内存地址必须是读取字节数的倍数，LDR 每次读取一个 WORD，所以使用 LDR 指令时，内存地址必须 4字节对齐。如果地址没有对齐，则会导致 HardFault 异常。
结合 LDR 指令的描述，在调试状态下，通过查看寄存器值，图 2 出错语句中根据 Rn和 imm 计算得到的内存地址为 R0=0x2000000B,imm=4 所以内存地址为 0x2000000F,很显然这个地址不是 4 字节对齐的。
图4.内存地址不对齐
而当我们改变编译优化选项为 Level1 时，得到的内存地址为R0=0x20000000,imm=0x04 显然这个地址是按照 4 字节对齐的，所以这种情况下是不会出现 HardFault 异常的，印证了客户的问题现象。
图5.内存地址对齐
3. 问题解决
通过上一节的分析，明确了导致该问题的本质原因是内存地址没有对齐，这个内存地址实际上是代码中定义的全局变量 g_curPlaySound_app 指向的地址，也就是全局数组变量 SoundFile 的地址，在编译器不同的优化选项下，分配给 SoundFile 变量的地址是不一样的，在本案例中，编译优化选项 Level0 条件下，SoundFile 分配的地址没有按照WORD 对齐，而在优化选项 Level1 条件下，SoundFile 分配的地址是 WORD 对齐，所以在两种优化选项下，出现了不一样的运行结果。所以要保证程序不出错，当通过指针访问变量的时候，要确保指针指向的地址是 4 字节对齐的，在 Keil 环境下，可以通过__attribute__((aligned (4))) 关键字实现，如下图所示，通过该关键字，对齐了地址，也就不会出现 HardFault 异常了。
图6.确保地址对齐
4. 总结
地址未对齐是嵌入式系统中容易忽视的一个细节，忽视这点往往会导致一些奇怪的问题，所以在开发过程中，注意这些细节还是很有必要的。
参考文献
文档中所用到的工具及版本
Keil MDK V5.29
本文档参考ST官方的《【应用笔记】LAT1185+一个地址未对齐引起的+HardFault+异常》文档。
