Forum Post: TMS320F28386D: PUMPREQUEST rarely not being released when immediately followed by read

Part Number: TMS320F28386D Tool/software: Initially in our application, releasing the flash pump was a straightforward affair: __eallow(); ReleaseFlashPump(); // from f2838x_ipc_defines.h Which compiled to equally straightforward assembly code: EALLOW MOVB AL,#0 MOV AH,#23130 MOVW DP,#||Cpu1toCpu2IpcRegs||+36 MOVL @$BLOCKED(||Cpu1toCpu2IpcRegs||)+36,ACC However, we sometimes ran into issues with the semaphore not actually being released. The initial assumption was that EALLOW took a few cycles to actually take effect. Although this theory contradicts the C28x Reference Guide (SPRU430F, p. 190 showing a sequence with even more critical timing), the following change got rid of the cases where the semaphore remained claimed: __eallow(); do { ReleaseFlashPump(); } while (Cpu1toCpu2IpcRegs.PUMPREQUEST.bit.SEM != 0); Resulting in the following assembly code: 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 Note the textbook case of write-followed-by-read. This might cause some chaos, since as far as I can tell, pipeline protection is disabled by default on the device, and there is no change to it in our application. Unfortunately, I failed to find information on this in the TRM or Datasheet, despite the C28x Reference Guide pointing me there (section 4.5.3). On some devices, this has sometimes caused us issues with the release not actually happening, or at least the code being stuck within that loop for an extended amount of time (up to a minute). On an affected device, inserting essentially any instruction between the write and the read severely reduced the occasions where that scenario happened. A blunt test of inserting a RPT # 255 || NOP between the write and the read caused the issue to no longer manifest. While we can live with that workaround in our current implementation, we feel somewhat uneasy not having understood the root cause of the issue. Is there a known issue with the above write/read sequence to PUMPREQUEST, or an explanation as for why it seems to only affect a small percentage of devices?