【技术支持案例】S32K146的hard fault问题处理

1. 案例背景

最近有个客户使用S32K146的产品在量产之后出现了三个售后件，ABBA测试之后的结果表明失效现象跟着S32K146走；同时客户反馈说试着将其中一个售后件重新烧录程序，S32K146又正常工作了。结合这两种情况，S32K146应该是没有损坏的，那就需要从软件程序方面排查了。

然后和客户的软件工程师交流了一下，使用Attaching to Running Target的方式发现程序卡死在HardFault。因为是量产产品出问题，客户强烈要求去现场处理问题，特地记录下这次处理S32K146的hard fault问题的过程，希望对读者有帮助。

2. 方案准备

在这之前，笔者还没有处理过S32K1系列发生HardFault的问题，所以需要先对S32K1系列发生HardFault的原因进行了解。推荐如下这篇文章，讲的非常细致。

• S32K1xx系列MCU的常见内核异常(Fault Exception)及处理详解(以S32K144为例介绍)

结合上面这篇文章以及ARM官方的M4内核文档Cortex -M4 Devices Generic User Guide，笔者简要整理了下S32K1发生HardFault的可能原因以及排查方式，如下文所述。

2.1 HardFault（硬件错误异常）

• HardFault的可能原因
  1. 停止调试关闭时发生了调试事件；
  2. UsageFault、BusFault、MemManage Fault未使能（Coretex-M4F内核默认状态）时发生了相应的错误导致错误升级到HardFault；
  3. 异常处理过程中取内核中断向量表读操作错误。
• HardFault的原因排查
  造成HardFault的原因，可通过SCB模块的硬件错误状态寄存器（HFSR）进行排查，如下所示：
  • 原因1引起的，DEBUGEVT bit置1；
  • 原因2引起的，FORCED bit置1；
  • 原因3引起的，VECTTBL bit置1。

2.2 UsageFault（用法错误异常）

• UsageFault的可能原因
  1. 执行未定义指令，即非法指令；
  2. 指令执行状态错误；
  3. 异常返回错误；
  4. 尝试访问关闭或者不可用的协处理器；
  5. 非对齐地址访问（需要先通过SCB模块的CCR寄存器进行使能）；
  6. 除零操作（需要先通过SCB模块的CCR寄存器进行使能）。
• UsageFault的原因排查
  造成UsageFault的原因，可通过SCB模块的用法错误状态寄存器（UFSR）进行排查，如下所示：
  • 原因1引起的，UNDEFINSTR bit置1；
  • 原因2引起的，INVSTATE bit置1；
  • 原因3引起的，INVPC bit置1；
  • 原因4引起的，NOCP bit置1；
  • 原因5引起的，UNALIGNED bit置1；
  • 原因6引起的，DIVBYZERO bit置1。

2.3 BusFault（总线错误异常）

• BusFault的可能原因
  1. Crossbar总线矩阵slave端口返回错误响应，当：
     • a. 异常/中断入口压栈；
     • b. 异常/中断返回出栈；
     • c. 预取指；
     • d. FPU lazy state现场保护；
  2. 精确总线错误；
  3. 不精确总线错误。
• BusFault的原因排查
  造成BusFault的原因，可通过SCB模块的总线错误状态寄存器（BFSR）进行排查，如下所示：
  • 原因1.a引起的，STKERR bit置1；
  • 原因1.b引起的，UNSTKERR bit置1；
  • 原因1.c引起的，IBUSERR bit置1；
  • 原因1.d引起的，LSPERR bit置1；
  • 原因2引起的，PRECISERR bit置1；
  • 原因3引起的，IMPRECISERR bit置1。

2.4 MemManage Fault（存储器管理错误异常）

• MemManage Fault的可能原因
  1. 尝试加载和储存内核MPU保护的地址；
  2. 从内核MPU保护的地址取指；
  3. 由MPU违规引起的压栈和出栈（函数调用或者中断/异常处理）错误；
  4. 硬件FPU lazy state保护触发的MPU存储器保护违规。
• MemManage Fault的原因排查
  造成MemManage Fault的原因，可通过SCB模块的存储器管理错误状态寄存器（MMFSR）进行排查，如下所示：
  • 原因1引起的，DACCVIOL bit置1；
  • 原因2引起的，IACCVIOL bit置1；
  • 原因3引起的，MSTKERR或MUNSTKERR bit置1；
  • 原因4引起的，MLSPERR bit置1；

UFSR、BFSR、MMFSR寄存器都是SCB模块中CFSR寄存器的子寄存器，包含关系如下，实际调试时查看CFSR寄存器即可。

如果要访问UFSR、BFSR、MMFSR这些子寄存器，可以按照如下的地址进行访问：

3. 现场支持

了解了引起HardFault的可能原因以及排查方式之后，就是按照该方法协助客户进行原因排查。

3.1 现场环境

客户的现场环境如下：

• 开发环境：IAR 8.30.1
• 调试器：Jlink V9
• MCU：S32K146
• SDK：EAR0.8.6

3.2 排查过程

1. 打开和异常件对应的软件工程，使用Attach方式连接上第一个异常件的主控S32K146，如下图所示：
   
2. 进入仿真界面后，暂停之后发现程序卡死在hard fault。
3. 查看S32的SCB模块，HFSR寄存器的FORCED bit置1，说明是其它错误上升到hard fault，需要查看CFSR寄存器了解更多信息。
   
4. CFSR寄存器的BFARVALID bit 和PRECISERR bit都置1，说明是精确总线错误造成bus fault并且捕捉保存了精确总线错误发生时的数据访问地址；再去查看BFAR寄存器，发生错误时数据访问的地址是0x100010E8。
   
5. 使用同样的方法排查第二个异常件的主控MCU，也是精确总线错误造成的bus fault，发生错误时数据访问的地址是0x10001128。
   
6. 接着通过IAR查看下S32K146的memory，从地址0x10001128起始的8个字节长度的flash区域数据无法查看。
   
7. 翻阅S32K1的memory相关的应用笔记AN11983: Using the S32K1xx EEPROM Functionality – Application Note，发生错误的地址属于D-Flash，如下图所示：

8. 查阅软件代码中读写DFlash中这块地址的函数，发现在写DFLASH之前虽然进行了擦写操作，但是并没有设置擦写成功之后才能写DFlash的条件，有概率出现擦写不完全的情况下写D-Flash。同时，客户查看了其他组未出问题的产品的软件代码，在写D-Flash之前添加了比较多的条件判断，包含对擦写状态的判断。至此，该问题初步得到解决，剩下的就是优化代码并跟进后续产品的表现了。

4. 异常模拟

客户的问题虽然解决了，但是笔者还是不确定连续两次对同一块区域的Flash写不同的值，中间没有擦除动作，是否会让MCU卡在HardFault，所以使用手上的S32K144开发板进行了该情况的模拟。

4.1 测试环境

• 开发环境：S32 Design Studio for ARM 2.2
• SDK：RTM 3.0.0
• 开发板：S32K144EVB-Q100

4.2 测试过程

1. 打开S32DS 2.2，选择自带的例程flash_partitioning_s32k144。
   
2. 将初始化模拟EEPROM的部分注释掉，避免D-Flash被用作模拟EEPROM的备份区从而无法进行读写测试。
   
3. 定义一套新数组并储存新的数据用于测试。
   
4. 在正常的D-Flash写之后增加写入不同数据的操作。
   
5. 编译之后进行debug，单步调试发现如果只进行写不同数据进入D-Flash，S32K144不会进入HardFault，需要再执行读D-Flash的操作，才会进入HardFault。
   

需要读取Flash地址的数据才会发生HardFault的原因，建议阅读下面这篇文章：

• S32K1xx系列MCU应用指南之存储器ECC功能使用详解(二)

6. S32DS之所以能在控制台显示比较多的MCU异常信息，是因为在调试器界面使能了异常捕捉功能，这部分功能依赖的是DEMCR寄存器，如下图所示。

更多关于DEMCR寄存器的描述，可以查看如下这篇文档：

• Armv7-M Architecture Reference Manual

---

如果觉得这篇文章对你有用，不妨给个一键三连！！！