|ARM Technical Support Knowledge Articles|
I have a peripheral in my system which generates many wait-states. I make two consecutive AP writes to these slow registers.
On a previous Cortex-M0 design, the CM0DAP returned long sequences of WAIT responses between these accesses.
On the new design, the SWJ-DP is accepting the second write without waiting for the first write to complete. When I then inspect the DP.CTRL/STAT register, I see a WDATAERR flagged.
The SWJ-DP in the Cortex-M3/M4 release has additional buffering compared with the minimal DP implementation in the CM0DAP.
For this reason, the SWJ-DP can accept the second write request while the first transfer is still pending on the internal DAP Bus. This is not a problem.
The reason for the WDATAERR is the Architectural specification that a read of the DP CTRL/STAT register is one of the three operations which is not allowed to receive a WAIT response. (The others are DP DPIDR read and DP ABORT write.) Since the CTRL/STAT read is forced to complete immediately, it cancels the pending AP write, which triggers the WDATAERR.
A sequence of AP accesses should be terminated with a stallable request before issuing a non-stallable request. The recommended action to terminate the sequence of AP accesses would be a DP RDBUFF read.
Did you find this article helpful? Yes No
How can we improve this article?