This might happen when the write request is followed by another write into the same naturally aligned double-word memory region, without a DMB between the two writes. The second write request must not be performed to the exact same bytes as the first store. The repetition of the write usually has no impact on the overall behavior of the system, unless the repeated write is used for synchronization purposes.
A write request to Normal memory region is treated as Uncacheable in the following cases:
This behavior might have implications in a multi-master system where control information is passed between several processing elements in memory using a communication variable, for example a semaphore. In such a system, it is common for communication variables to be claimed using a Load-Exclusive/Store-Exclusive, but for the communication variable to be cleared using a non-Exclusive store. Due to this malfunction, the clearing of such a communication variable might occur twice. This might lead to two masters apparently claiming a communication variable, and therefore might cause data corruption to shared data.
A scenario in which this might happen is:
MOV r1,#0x40 ; address is double-word aligned, mapped
; in Normal Non-cacheable Shareablememory
Loop: LDREX r5, [r1,#0x0] ; read the communication variable CMP r5, #0 ; check if 0 STREXEQ r5, r0, [r1] ; attempt to store new value CMPEQ r5, #0 ; test if store succeeded BNE Loop ; retry if not DMB ; ensures that all subsequent accesses ; are observed when gaining of the ; communication variable has been observed ; loads and stores in the critical region can now be performed MOV r2,#0 MOV r0, #0 DMB ; ensure all previous accesses are observed ; before the communication variable is cleared STR r0, [r1] ; clear the communication variable with normal store STR r2, [r1,#0x4] ; previous STR might merge and be sent again, which might ; cause undesired release of the communication variable.
This scenario is valid when the communication variable is a byte, a half-word, or a word.
There are several possible work-arounds:
STR r0, [r1] ; clear the communication variable
DMB ; ensure the previous STR is complete
Also, any IRQ or FIQ handler must execute a DMB at the start to ensure as well the clear of any communication variable is complete.
ALIGN 64 communication_variable DCD 0 unused_data DCD 0
LDR r1,= communication_variable
|Work-around:||There are several, refer to Detailed Work-arounds.|
|Configurations Affected:||Systems that use the CPUs.|
|Device Revision(s) Affected:||All. No plan to fix. Refer to (Xilinx Answer 47916) - Zynq-7000 AP SoC Silicon Revision Differences.|
05/16/2013 - Initial release