Understanding processor halt when SWDIO/SWCLK are pulled high/low respectively

RE: Understanding processor halt when SWDIO/SWCLK are pulled high/low respectively

Håkon Alseth — Fri, 20 Jan 2023 14:47:19 GMT

Hi,

[quote user="nwl_at_whisper"]Is there any documentation about the internal SWD debug handling in the nRF? The provided documentation does not seem to explain why this resulted in the processor being halted.[/quote]

We implement the standard component from ARM. The specification is available from ARMs website:

https://developer.arm.com/documentation/ihi0031/latest

The first chapter in the previous link (although it mentions cortex m1, it applies to the whole cortex m family) can explain the behavior that you're seeing:

The serial interface to the SW-DP must use a connection sequence, to ensure that hot-plugging the serial connection does not result in unintentional transfers. 
The connection sequence ensures that the SW-DP is synchronized correctly to the header that is used to signal a connection. 
It consists of a sequence of 50 clock cycles with data = 1, that is, with the serial data signal asserted HIGH by the debugger.

This connection sequence is also used as a line reset sequence, see Protocol Error responses on page 5-13. 
The protocol requires that any run of 50 consecutive 1s on the data input is detected as a line reset, regardless of the state of the protocol.

Have you scoped the SWD pins to see how these signals behave when you get into this unwanted situation?

Kind regards,

Håkon

RE: Understanding processor halt when SWDIO/SWCLK are pulled high/low respectively

nwl_at_whisper — Thu, 19 Jan 2023 17:02:22 GMT

Hi Håkon, you're correct that I'm looking at the case where UART TX data could be muxed to a SWD line, but only one of the lines has data on it (UART TX) and the other line has a pull up (the UART RX line).

I looked through the SWD spec that you linked, but it did not explain the behavior that I saw. Specifically, pulling SWCLK high and then temporarily shorting SWDIO low does not seem to be valid according to the SWD protocol, so I'm not sure why the processor would halt.

In our design, there is no way to avoid that UART TX data could potentially end up on one of the lines, but the workaround we have is to not enable the pull-up resistor on the UART RX line, (so that SWCLK does not end up pulled high), but we need to make sure this will resolve the issue we were seeing in all situations.

Is there any documentation about the internal SWD debug handling in the nRF? The provided documentation does not seem to explain why this resulted in the processor being halted.

Thanks!

Nick

RE: Understanding processor halt when SWDIO/SWCLK are pulled high/low respectively

Håkon Alseth — Thu, 19 Jan 2023 13:09:18 GMT

Hi,

Do I understand the scenario correct that you're sending UART data into the SWD pins?

If yes, then unwanted behavior can happen, as SWD is also a serialized bus.

Please see the SW-DP specification for more information: https://developer.arm.com/documentation/ddi0413/c/debug-access-port/sw-dp/protocol-description

Kind regards,

Håkon