|
1. 问题描述 客户反馈,使用STM32H563的data flash(high-cycle data flash),在还没有写入任何数据之前去读取data flash,会触发hardfault异常。 2. 问题分析 我们尝试在NUCLEO-H563ZI板上重现问题,直接使用STM32CubeH5包内的示例工程:STM32Cube_FW_H5_V1.4.0\Projects\NUCLEOH563ZI\Examples\FLASH\FLASH_EDATA_EraseProgram。 此示例代码的大体流程如下: 1> 系统启动后,初始化系统时钟。 2> 配置OB,将FLASH bank1的最末尾的8个sector配置为high-cycle flash。如下红框所示:
▲ 图1. 配置末尾8个sector为data flash 3> 擦除所有8个high-cycle data flash扇区。 4> 往8个data flash扇区写入数据0xAA55(半字)。 5> 最后读出8个data flash扇区的数据进行检查。 这里有一个细节,每次编程只写半字数据,为什么是半字呢?那是因为data flash区域每16bit对应一个6位的ECC校验。当然你要是写一个32bit的字也是可以的。 为了模拟客户的问题,我们将第4>步骤跳过,即在擦除扇区后,直接读取扇区内数据。最终重现了问题:
▲ 图2. 触发了NMI异常 此时查看FLASH的FLASH_ECCDETR寄存器:
▲ 图3. FLASH_ECCDETR寄存器 从寄存器内容可看出,此时触发了EDATA_ECC double error错误。刚擦除了data flash不能立即读取吗?于是在参考手册上找到如下对应内容:
如上图参考手册内容所描述,当data flash为virgin word时(比如刚擦除完,还未写入任何数据),此时若去访问它,当触发ECC错误,只有编程后(no more virgin),ECC错误才会消失。 至于读取data flash时,触发ECC错误时,寄存器中显示的内容为什么是0xf000?这个在参考手册中也能找到对应内容:
可见,FLASH_ECCDETR寄存器的ADDR_ECC中显示的地址并不是简单地将flash地址直接显示,而是有一定的规则。代码中访问的是0x09000000U位置就触发了data flash ECCD错误,它对应的是Data area sector 7的起始位置,如上表所示,对应0xF000,此扇区对ECC错误记录范围为0xF000~0xF1FF。 3. 解决方法 知道了原因,再去解决就比较容易了。解决方法有两个: 1> 确保代码中每次读取data flash之前必须先写入数据。 2> 屏蔽ECC错误在读取data flash之前,执行如下代码:如此一来,虽ECC错误仍然存在(已忽略),但不再触发NMI中断。 4. 其它 与data flash具体类似特性的还有OTP,它也是若写任何数据前就去读取其内容也会触发ECCD错误,从而导致NMI异常。 另外,对于data flash,访问它要关闭其对应的缓存属性。这个在示例中也有相关代码,比如:
若不如此做,则当访问data flash时,将触发hardfault中断。
▲ 图4. 若不关闭缓存属性,访问data flash将触发hardfault 与这个类似的还有OTP,和readonly data(比如芯片UID)。若对应地址没关闭缓存直接读取也会触发hardfault。 |
【STM32H5 评测】MNIST 数字识别
【STM32H5 评测】3、STM32H5 Lwip 移植、官方例程和UDP发送数据
【STM32H5 评测】+开发板拆箱介绍
【STM32H5 评测】4、移植CoreMark
【STM32H5 评测】ADC 电压表
【STM32H5 评测】基础硬件加密与随机数性能 - STM32H5E5实测硬件AES加解密、HASH运算、TRNG真随机数输出速率与稳定性
【STM32H5 评测】基于NUCLEO_H5E5ZJ+Zephyr数字电源
【STM32H5 评测】NUCLEO-H5E5ZJ 使用 TrustZone 安全分区系统实践测试
【STM32H5 评测】CPU核心性能 - STM32H5E5跑 RTOS,观察任务切换速度、中断响应快慢
【STM32H5 评测】内存读写性能 - STM32H5E5实测Flash,SRAM读写速度,用DMA搬运大块数据
微信公众号
手机版