TI中文支持网Part Number:TMS570LC4357
我使用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所在空间时应该配置为哪种权限？
Ben Qin：
你好，我需要咨询下相关工程师，一旦有回复会立即回复您。
,
user5769726：
好的，感谢，补充一下，我向bank0写入时（写最后一个sector）也会有像bank1一样的问题
,
Ben Qin：
好的
,
Ben Qin：
你好，能否分享下您的工程以供我们这边测试一下？
,
user5769726：
抱歉，由于涉及信息安全，无法提供工程
我把今天的进展描述一下，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属性有关？
,
Ben Qin：
好的，已向相关工程师跟进。
,
Ben Qin：
您是否能参考下以下例程？
3146.FAPI_TEST_LC43.zip
7331.FAPI_TEST_LC4357.zip
FAPI_TEST_LC4357_desktop.zip
