SWD interface changing phase from send to receive?

[Andrew Lentvorski]

Is there a more thorough documentation of the SWD interface as implemented on the nRF chips?

I'm seeing something I regard as strange when I look at things on a scope.

In order to make my nRF51822 accept a command (IDCODE for instance) I have to send the 0xA5 such that SWDIO changes on a falling SWDCLK but samples on the rising edge.

However, when the chip sends me back data that appears to change and the nRF chip changes SWDIO on a rising SWDCLK and I have to sample it on the falling edge.

That very definitely does NOT match any of the diagrams from ARM I have seen. The diagrams NEVER demonstrate a change of phase.

In addition, all of the diagrams indicate that data should change on rising edge and sample on falling edge. This is not what the nRF chips seem to be doing during the sending of the command.

However, there is a common convention in SPI that diagrams are meant to represent the transition from active to idle and is normally controlled by the Polarity and Phase bits. What is NOT common convention is changing the phase mid-transaction.

Am I missing something? I really tried to RTFM. But I'm perfectly willing to accept that I missed something that's actually documented--just point me at it.

Thanks.

(The use case here is that I need multiple programmers that can be located at the manufacturing line and that can program and can do a bit of functional test so that we can fail defective units at the line where they can be inspected in more detail and possibly reworked.)

[RK]

Having researched this properly and read the documentation again, I'll move it from comment to answer.

The debug unit is a standard ARM one and all the documentation for it is the standard ARM documentation.

The description of the SWD wire protocol is at infocenter.arm.com/.../DUI0499J_arm_ds5_arm_dstream_reference_guide.pdf section 2.1.2 where it has a useful figure and a table.

The table confirms what you see. Both the probe and the target read data on a rising SWDCLK, however the target writes data on a rising SWDCLK but the probe writes data on a falling SWDCLK.

I didn't instantly see how the probe could read and the target write on a rising CLK, wouldn't the data be changing, however it makes sense when you realise that the probe is generating the clock, and the target is detecting the clock.

So when the probe reads, it does so when the CLK line is low, just before it sets it high, ie just before it generates the rising edge. So as soon as the target detects the rising edge, it can write new data, the probe has already read it, guaranteed. However when the target has data to read it also does it on a rising edge, but it needs to detect the edge, hence the probe has to raise the CLK to high and then leave the data valid for long enough for the target to read it, it gives the target 1/2 a cycle, while the CLK is high and after it puts it back low, then it writes the next bit of data while it's low, then repeats the cycle.

This gives the target one complete cycle to write new data and a 1/2 cycle to detect the clock rising edge and read data.

[Andrew Lentvorski]

Upvoted. Thanks for an actual reference with edges in it. You'd think ARM would put this in their other documentation somewhere.

Yeah, the turnaround looks stupid from an outside point of view, but after thinking about it for a while it makes sense when you consider that that target has no running clock other than what is being provided by the debug probe.

On target receive, the target has to 1) Sample on clock rising edge and then 2) do something with that sample on the clock falling edge. On target transmit, the target has to 1) Prepare something on clock falling edge and then 2) put that something on the line on the clock rising edge.

And that's why the turnaround cycles are where they are. That way the system has an extra clock cycle to do something when it has to.

Sigh. All this effort to avoid using 3 signals (SCK, SDO, SDI) instead of two (SCK, SDO/SDI) when most people would rather have the ability to use a dedicated SWO-like signal anyway.