You copied the Doc URL to your clipboard.

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

Problem/Question

Serial Wire Debug sequence fails to produce WAIT responses for wait states, then generates WDATAERR

Scenario

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.

Answer

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.

Workaround

N/A

Example

N/A

Related Information

N/A

Was this page helpful? Yes No