DAPLink icon indicating copy to clipboard operation
DAPLink copied to clipboard

wrong clock phase in DP_SW.c

Open nerdralph opened this issue 3 years ago • 3 comments

It looks like the template code has the clock out of phase. https://github.com/ARMmbed/DAPLink/blob/master/source/daplink/cmsis-dap/SW_DP.c#L50

The spec says: "The target writes data to SWDIO on the rising edge of SWDCLK. The target reads data from SWDIO on the rising edge of SWDCLK."

SWD_READ_BIT should be reading the SWDIO line after setting SWCLK, not before. And since SWCLK idle state is low, SW_CLOCK_CYCLE should first set, then clear SWCLK. This is how Segger J-link does it. https://interrupt.memfault.com/blog/img/debuggers/first_transaction.png

nerdralph avatar Jan 07 '21 14:01 nerdralph

Although the ARM SWD spec says, "The probe reads data from SWDIO on the rising edge of SWDCLK.", I found a better description that says the probe should read after the falling edge. https://www.cnblogs.com/shangdawei/p/4757044.html

So after the first 8 bits of the SWD write packet, the target will drive SWDIO after detecting the rising edge of SWDCLK during the turnaround cycle. The probe then needs to read that first ACK bit before driving SWDCLK high again.

Therefore I think SWD_READ_BIT should sample SWDIO, set SWDCLK high, and then set SWDCLK low again.

nerdralph avatar Jan 08 '21 19:01 nerdralph

(Sorry, I was starting to reply yesterday and got sidetracked.)

This issue should be moved to the CMSIS_5 repo. The CMSIS-DAP code in DAPLink is just the reference code from the CMSIS_5 repo with a few tiny changes unrelated to SWD or JTAG.

The ADI docs are indeed rather difficult to understand!

flit avatar Jan 08 '21 19:01 flit

The spec says: "The target writes data to SWDIO on the rising edge of SWDCLK. The target reads data from SWDIO on the rising edge of SWDCLK."

I guess you were looking at the specification from Arm (example: DSTREAM debug probe specification): DSTREAM SWD timing requirements

Although the ARM SWD spec says, "The probe reads data from SWDIO on the rising edge of SWDCLK."

Exactly. This is also how the SW_READ_BIT macro is implemented.

The macro for reading a bit in SW_DP.c: #define SW_READ_BIT(bit) \ PIN_SWCLK_CLR(); \ PIN_DELAY(); \ bit = PIN_SWDIO_IN(); \ PIN_SWCLK_SET(); \ PIN_DELAY()

SWD_READ_BIT should be reading the SWDIO line after setting SWCLK, not before.

Not really. The target will start driving the next bit on the rising edge and sampling after the rising edge might read the next bit.

Keep in mind that the macro execution can be interrupted (ISR) which would make the time between sampling and rising edge even longer.

SWCLK idle state is low

It is not really about SWCLK idle state but rather at which edge the data is driven and sampled. However the idle state would normally be high. You can see this also from the timing diagram in the previous mentioned specification.

I found a better description that says the probe should read after the falling edge.

I'm not sure about 'better'. Arm defined the specification so I would stick to the official Arm specification.

Regarding the approach that probe should read the data on the falling edge as mentioned in the quoted description: That is a possibility. It will however decrease (half) the maximum clock. The maximum clock can be achieved by sampling later (rising edge). Of course it is assumed that both SWCLK and SWDIO have similar electrical characteristic.

BTW: That same description also shows waveforms with SWCLK idle state being high.

There are a lot of CMSIS-DAP based debuggers out that are used with many different targets and there are no real problems due to the discussed sampling approach.

Also professional debuggers as DSTREAM, ULINKpro and ULINKplus.

RobertRostohar avatar Jan 22 '21 10:01 RobertRostohar