HA01 1_3_1 SDK ECC Demo笔误

[Derrick]

1. 问题描述

• HA01的1_3_1的ECC Demo笔误，在 EFM_RecoveryErrorHandler 清除的是 UNRECOVERR 标志。
• 导致 RECOVERR 的中断标志位一直没有被清除，无限进入 EFM_RecoveryErrorHandler ，造成程序卡住。
  

2. 背景

• 有客户在应用中使用参考1_3_1的ECC Demo，开启EFM_Recovery中断和添加中断处理代码。
• 当写flash掉电发生ECC 单bit错误时，由于客户并未在单bit错误中断中擦除错误sector，同时UNRECOVERR 标志未清除，最终就无限进中断导致程序卡死。

3. 详细描述

• SDK对比：
  
• 1_3_1流程解析：
  

4. 测试验证

• 使用EFM ECC错误注入的方式模拟flash掉电发生ECC 单bit错误，可复现无限进入单bit错误中断。
  

5. 解决方案

• 参考SDK 1_4_1 在EFM_RecoveryErrorHandler 里正确清除RecoveryError标志位；
• 不处理 RecoveryError ，硬件可以纠错，不开 RecoveryError 中断。
• 列入checklist，方便客户前期规避此问题。

6. 为什么1_3_1的ECC Demo测试没问题

• 原因是1_3_1版本的falsh驱动在 FLASH_LaunchCommandSequence 操作时都会清除所有错误标志
• 而且ECC例程的处理机制就是不管是单还是双bit ECC错误都会擦除对应的sector
• 所以一旦调用 FLASH_DRV_EraseSector 就会将 RecoveryError 标志清除，也就不会重复进入中断。
  
• 1_4_1 的例程RecoveryError 中断里会及时清除标志位，但是 FLASH_LaunchCommandSequence 就不会清除全部的错误标志：
  

7. 结论

• HA01 1_3_1 SDK 的 ECC Demo笔误：EFM_RecoveryErrorHandler 清错标志（清了 UNRECOVERR 而非 RECOVERR），导致中断反复触发、程序卡死；
• 解决方案是参照 1_4_1 SDK 在 EFM_RecoveryErrorHandler 中正确清除 RecoveryError 标志，或不处理 RecoveryError、直接关闭该中断。

8. 测试软件

Flash_ECC1bit_Injict_Demo.zip