h7 数据同步问题

sharkgao

在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字节数据没发现问题。

eric2013

这个跟DTCM貌似没啥关系，应该是编译器的处理机制问题。让编译器不要去管理这部分数据。

ps：
DTCM没有Cache问题，它不支持Cache，因为它的速度跟Cache速度一样，无需Cache支持。
也没有DMA问题，因为普通DMA无法访问这个空间，只有MDMA才支持。

sharkgao

跟编译器没关系啊，写入的单字节数据随同整个背景数据区域，都打印出来检查了，已经正确了。
但是，cpu重启后，发现背景数据正确，写入的单字节数据失踪。

要不，我把数据区换到axi区试试

sharkgao

严重怀疑，cpu和dtcm之间也存在某种cache或写入队列，因为：

1 只要cpu不重启，不影响写入和读出效果，仅当cpu重启时才写入队列会丢失。
2 那个单字节数据，我重复写入4遍，重启后发现成功了

eric2013

sharkgao 发表于 2019-10-2 09:42
严重怀疑，cpu和dtcm之间也存在某种cache或写入队列，因为：

1 只要cpu不重启，不影响写入和读出效果， ...

单字节写入，发现写入后，延迟100ms，再重启，好了。。

诡异。
====================================
进一步测试发现，操作4字节数据（字节类数组），不可靠，程序其它位置修改下，很容易造成无法使用。

但加上延迟后，确实靠谱很多，暂时还没有失败过。

Yhlr

我也遇到了，在APP要复位到BOOT里前，置位了某个8bit的数据（位于DTCM），地址为0x20000029，执行NVIC_SystemReset指令前，数据都还是正常的，跳转到BOOT后，数据就被修改了

Yhlr

我看了您这篇帖子,https://www.armbbs.cn/forum.php?mod=viewthread&tid=95217，那复位前还需要进行延时操作嘛？目前看来不延时也是比较稳定的，定义成32bit的数据后重启就没问题了。测试了一下，重复写入楼上我说的8bit数据4次，重启后数据也未被修改