Serial Wire Debug sequence fails to produce WAIT responses for wait-states then generates WDATAERR
Article ID: 103489847
Published date: 13 Feb 2018
Last updated: -
Applies to: Cortex-M3, Cortex-M4
Serial Wire Debug sequence fails to produce WAIT responses for wait states, then generates WDATAERR
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 accepts 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 and Cortex-M4 releases 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.