1. 问题描述
HA01的1_3_1的ECC Demo笔误，在 EFM_RecoveryErrorHandler 清除的是 UNRECOVERR 标志。
导致 RECOVERR 的中断标志位一直没有被清除，无限进入 EFM_RecoveryErrorHandler ，造成程序卡住。
fc596f9a-d05c-4ed1-922d-86e8afc58e1e-image.png
2. 背景
有客户在应用中使用参考1_3_1的ECC Demo，开启EFM_Recovery中断和添加中断处理代码。
当写flash掉电发生ECC 单bit错误时，由于客户并未在单bit错误中断中擦除错误sector，同时UNRECOVERR 标志未清除，最终就无限进中断导致程序卡死。
3. 详细描述
SDK对比：
62d84d34-1bac-4bf3-8aa3-3a0eb89dd13d-image.png
1_3_1流程解析：
39c79274-6b56-4ba1-9650-d2d0e905eb04-image.png
4. 测试验证
使用EFM ECC错误注入的方式模拟flash掉电发生ECC 单bit错误，可复现无限进入单bit错误中断。
e9b47a10-7b24-42b4-ad5e-c3f13ee19cb8-image.png
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 标志清除，也就不会重复进入中断。
d1e1eea0-c86d-4af4-886c-5ab17d51bdc4-image.png
1_4_1 的例程RecoveryError 中断里会及时清除标志位，但是 FLASH_LaunchCommandSequence 就不会清除全部的错误标志：
6aaf7c8f-3c76-4f29-866f-9bed766cf0d0-image.png
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
