h7 数据同步问题
本帖最后由 sharkgao 于 2019-10-1 19:53 编辑在dtcm区域，没用dma，没用cache，但数据同步问题如下：
int v = rdclock();
memset(&bl_data, v, sizeof(bl_data)); // 故意写入整块随机数，重启后还存在，没问题
// save BL parameters
bl_data.bl_stay = rebooter->bl_stay;
if(rebooter->reason!=RBT_BL){
KTRACES("fill %d", rebooter->reason);
bl_data.bl_upmode = rebooter->reason; // 此处写入的单字节数据，重启后丢失
}
__DSB();
KTRACES("\r\n%-0*h", 0x60, &bl_data); // 检查当前数据，正确，见下图
__NVIC_SystemReset(); // 重启cpu
重启前后的数据跟踪如下图
发现重启之前写入的单字节数据05，并没有真正写入sram中。
同时，写入4字节数据没发现问题。
这个跟DTCM貌似没啥关系，应该是编译器的处理机制问题。让编译器不要去管理这部分数据。
ps：
DTCM没有Cache问题，它不支持Cache，因为它的速度跟Cache速度一样，无需Cache支持。
也没有DMA问题，因为普通DMA无法访问这个空间，只有MDMA才支持。
跟编译器没关系啊，写入的单字节数据随同整个背景数据区域，都打印出来检查了，已经正确了。
但是，cpu重启后，发现背景数据正确，写入的单字节数据失踪。
要不，我把数据区换到axi区试试 严重怀疑，cpu和dtcm之间也存在某种cache或写入队列，因为：
1 只要cpu不重启，不影响写入和读出效果，仅当cpu重启时才写入队列会丢失。
2 那个单字节数据，我重复写入4遍，重启后发现成功了
sharkgao 发表于 2019-10-2 09:42
严重怀疑，cpu和dtcm之间也存在某种cache或写入队列，因为：
1 只要cpu不重启，不影响写入和读出效果， ...
单字节写入，发现写入后，延迟100ms，再重启，好了。。
诡异。
====================================
进一步测试发现，操作4字节数据（字节类数组），不可靠，程序其它位置修改下，很容易造成无法使用。
但加上延迟后，确实靠谱很多，暂时还没有失败过。
我也遇到了，在APP要复位到BOOT里前，置位了某个8bit的数据（位于DTCM），地址为0x20000029，执行NVIC_SystemReset指令前，数据都还是正常的，跳转到BOOT后，数据就被修改了 我看了您这篇帖子,https://www.armbbs.cn/forum.php?mod=viewthread&tid=95217，那复位前还需要进行延时操作嘛？目前看来不延时也是比较稳定的，定义成32bit的数据后重启就没问题了。测试了一下，重复写入楼上我说的8bit数据4次，重启后数据也未被修改
页:
[1]