AR# 52034


Zynq-7000 SoC, APU - A write request to Uncacheable, Shareable normal memory region might be executed twice, possibly causing a software synchronization issue


Under certain timing circumstances specific to the Cortex-A9 microarchitecture, a write request to an Uncacheable, Shareable Normal memory region might be executed twice causing the write request to be sent twice on the AXI bus.


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:

  • The write request occurs while the Data Cache is disabled.
  • The write request is targeting a memory region marked as Normal Memory Non-Cacheable or Cacheable Write-Through.
  • The write request is targeting a memory region marked as Normal Memory Cacheable Write-Back and Shareable, and the CPU is in AMP mode.

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.

Detailed Work-arounds:

There are several possible work-arounds:

1) Add a DMB after clearing a communication variable:

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.

2) Ensure there is no other data using the same naturally aligned 64-bit memory location as the communication variable:

communication_variable DCD    0
unused_data            DCD    0
                       LDR    r1,= communication_variable

3) Use a Store-Exclusive to clear the communication variable, rather than a non-Exclusive store.


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 SoC Silicon Revision Differences.

Revision History

05/16/2013 - Initial release

Linked Answer Records

Master Answer Records

Answer Number Answer Title Version Found Version Resolved
47916 Zynq-7000 AP SoC Devices - Silicon Revision Differences N/A N/A
AR# 52034
Date 06/14/2018
Status Active
Type Design Advisory
People Also Viewed