stm32H7 FLASH 写入异常

函数接口

写入接口HAL_FLASH_Program_IT(FLASH_TYPEPROGRAM_FLASHWORD, address, data_addr);

链式写入回调接口void HAL_FLASH_EndOfOperationCallback(uint32_t ReturnValue)，用来触发下一次中断写入

问题描述（偶现）

链式写入1024字节数据包，在每次回调函数中HAL_FLASH_EndOfOperationCallback读取上一次写入区域并和缓存比较判断是否写入成功，并触发下一次HAL_FLASH_Program_IT。

在上述过程中未监测到异常且未监测到写入内容FLASH字全为FF的情况下，在整包校验时读取刚才写入的1024字节内容，会出现随机位置FLASH字全为FF的异常情况。

问题根因

由于在HAL_FLASH_EndOfOperationCallback中触发下一次写入，出现写入后马上再次触发HAL_FLASH_EndOfOperationCallback导致重入写入函数，导致偏移异常随机跳过某个flash字。

你确保flash编程时遵循了相应编程及对齐方式，STM32H7系列有4字编程模式【STM32H7A/7B】 ，也有8字编程模式。

再就是注意FLASH写的时候将ICACHE关闭，写完之后再打开。

在校验时建议将Dcahce也关闭，防止DCache与实际数据不一致的问题。

可以尝试在执行擦写前设置一个按键开关。

这样发现异常时通过Stm32cubeProgrammer 去看一看是否是真的有FF字节。
从而定位问题是发生在前面写入部分还是后面全局校验部分，缩小调查范围。

测试时注意写入时，减少其他中断避免意外修改。测试次数也要有大概限制，毕竟FLASH 擦写是有寿命次数的。

感谢 @butterflyspring 和 @xmshao的关注

以下是补充说明

• 问题中描述的随机位置FLASH字全为FF的异常情况是从 Stm32cubeProgrammer 获取判断的。
• 写 FLASH 时 是做过对齐处理的。
• 目前的测试结论是 是否使用 ICACHE 对写FLASH异常问题没有改善效果。
• 由于使用 DCACHE 很容易出现一致性问题，所以从未开启过 DCACHE。

最新进展发现 freertos 多线程阻塞和抢占问题对导致这一现象，具体原因待排查。