[参考译文] TMS320F28386D：当立即执行读取操作时、PUMPREQUEST 很少无法释放

https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1499954/tms320f28386d-pumprequest-rarely-not-being-released-when-immediately-followed-by-read

工具/软件：

最初在我们的应用程序中,释放闪存泵是一件简单的事情:

__eallow();
ReleaseFlashPump(); // from f2838x_ipc_defines.h

它编译为同样简单的汇编代码：

        EALLOW
        MOVB      AL,#0
        MOV       AH,#23130
        MOVW      DP,#||Cpu1toCpu2IpcRegs||+36
        MOVL      @$BLOCKED(||Cpu1toCpu2IpcRegs||)+36,ACC

然而、我们有时会遇到信标实际上未被释放的问题。 初始假设是 EALLOW 需要几个周期才能实际生效。 尽管这一理论与 C28x 参考指南(SPRU430F、第190页、其中显示了一个时序甚至更关键的时序)相矛盾、但以下更改消除了信标仍然声明的情况：

    __eallow();
    do {
        ReleaseFlashPump();
    } while (Cpu1toCpu2IpcRegs.PUMPREQUEST.bit.SEM != 0);

生成以下汇编代码：

        EALLOW
        MOVL      XAR4,#||Cpu1toCpu2IpcRegs||
||$C$L1||:    
        MOVB      XAR1,#36
        MOVB      AL,#0
        MOV       AH,#23130
        MOVB      XAR0,#36
        MOVL      *+XAR4[AR1],ACC
        MOV       AL,*+XAR4[AR0]
        ANDB      AL,#0x03
        B         ||$C$L1||,NEQ

请注意教科书中写后读的情况。 这可能会导致一些混乱、因为据我所知、流水线保护在器件上默认处于禁用状态、并且在我们的应用中没有变化。 遗憾的是、尽管 C28x 参考指南指出了这一点(第4.5.3节)、但我还是未能在 TRM 或数据表中找到这方面的信息。

在某些器件上、这有时会导致我们出现以下问题：实际未执行发布、或者至少代码在该循环中滞留了很长时间(长达一分钟)。 在受影响的器件上、在写入和读取之间插入基本上任何指令都会大大减少发生这种情况的几率。 RPT # 255 || NOP在写入和读取之间插入的钝测试导致问题不再出现。

虽然我们可以在当前实施中采用该权变措施、但如果不了解问题的根本原因、我们会感到有些不安。 PUMPREQUEST 的上述写入/读取序列是否存在已知问题、或者说明为什么它似乎仅影响一小部分器件？