This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
我使用F021 api对片内flash进行擦写,流程如下:
擦除bank1——向bank1写入0xaa——读取bank1空间检验是否全部写为0xaa——擦除bank1——向bank1写入0x55——读取bank1空间检验是否全部写为0x55
在上面流程中,第一次擦除、写入、读取都正常;第二次擦除,写入正常,无报错,但读取时候发现有一部分空间未被写为0x55,仍然是0xaa
对于bank7未出现上面问题
若我在启动阶段不调用CacheEnable,上述问题消失;
若我在启动阶段调用CacheEnable,在每次写完flash后调用_dCacheInvalidate_,通过串口打印发现在调用_dCacheInvalidate_的函数执行完之后无法继续执行;
请问这种情况可能是什么原因?我应该如何解决?
另外,我在mpu模块中配置flash bank0/1/7所在空间时应该配置为哪种权限?
抱歉,由于涉及信息安全,无法提供工程
我把今天的进展描述一下,TI本身提供的_dCacheInvalidate_函数是将整个cache全部invalid掉,我根据r5手册重新实现了按照cacheline粒度进行invalid的接口(MCR P15, #0, R0, C7, C6, #1),在每次写入flash后对改地址所在cacheline进行invalid,这样就解决了我提到的第二次读取错误的问题
虽然问题不再出现,但对于产生问题的原因我们还不是很清楚,所以还想咨询以下两个问题:
1、为什么cache中会保留上次写入的数据没有刷新?我们的mpu对BANK0/1的配置是NORMAL_OIWTNOWA_NONSHARED
我们的猜想是:第一次擦除与写入是通过api完成的,没有经过cache,读取是直接通过地址读的,cache会缓存第一次读到的数据;第二次擦除写入同样不经过cache,但第二次读取时,部分数据读到的实际上是cache中缓存的第一次数据
2、为什么调用_dCacheInvalidate_会导致程序挂死无法继续执行?是否跟sram空间被mpu配置为write_back属性有关?