- 188.8.131.52. 782772: Speculative Execution of LDREX or STREX Instruction After a Write to Strongly Ordered Memory Might Lead to Deadlock
- 184.108.40.206. 761320: Full Cache Line Writes to the Same Memory Region From Both Processors Might Cause Deadlock
- 220.127.116.11. 845369: Under Very Rare Timing Circumstances Transition into Streaming Mode Might Create Data Corruption
- 18.104.22.168. 751476: Missed Watchpoint on the Second Part of an Unaligned Access Crossing a Page Boundary
- 22.214.171.124. 782773: Updating a Translation Entry to Move a Page Mapping Might Erroneously Cause an Unexpected Translation Fault
- 126.96.36.199. 794072: A Short Loop Including DMB Instruction Might Cause a Denial of Service When the Other Processor Executes a CP15 Broadcast Operation
- 188.8.131.52. 794073: Speculative Instruction Fetches with MMU Disabled Might Not Comply with Architectural Requirements
- 184.108.40.206. 794074: A Write Request to an Uncacheable, Shareable Normal Memory Region Might be Executed Twice, Possibly Causing a Software Synchronization Issue
- 220.127.116.11. 729818: In Debug State, the Next Instruction is Stalled When the SDABORT Flag is Set Instead of Being Discarded
- 18.104.22.168. 757119: Some Unallocated Memory Hint Instructions Generate an UNDEFINED Exception Instead of Being Treated as a NOP
- 22.214.171.124. 771221: PLD Instructions Might Allocate Data in the Data Cache Regardless of the Cache Enable Bit Value
- 126.96.36.199. 771224: Visibility of Debug Enable Access Rights to Enable/Disable Tracking is Not Ensured by an ISB
- 188.8.131.52. 771225: Speculative Cacheable Reads to Aborting Memory Regions Clear the Internal Exclusive Monitor and May Lead to Livelock
- 184.108.40.206. 775419: PMU Event 0x0A Might Count Twice the LDM PC ^ Instruction with Base Address Register Write-Back
220.127.116.11. 794074: A Write Request to an 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 condition might happen when the write request is followed by another write into the same naturally doubleword-aligned memory region, without a DMB between the two writes.
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.
This erratum requires the following conditions:
- A write request is performed to an uncacheable, shareable normal memory region.
- Another write request is performed into the same naturally doubleword-aligned memory region. This second write request must not be performed to the exact same bytes as the first store.
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 erratum might have implications in a multi-master system where control information is passed between several processing elements in memory using a communication variable, such as a semaphore. In this type of 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. This erratum means that the clearing of such a communication variable might occur twice. This error 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 Shareable memory 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 workarounds:
- Add a DMB after clearing a communication variable:
Also, any IRQ or FIQ handler must execute a DMB at the start to ensure that the clear of any communication variable is complete.
STR r0, [r1] ;clear the communication variable DMB ;ensure the previous STR is complete
- Ensure there is no other data using the same naturally aligned 64-bit memory location as the communication variable:
ALIGN 64 communication_variable DCD 0 unsed_data DCD 0 LDR r1 = communication_variable
- Use a Store-Exclusive to clear the communication variable, rather than a non-Exclusive store.
Did you find the information on this page useful?