user15972: So I'm trying to read a bit of data via SWD. I've tried two chips as target - LPC1110 and STM32F030F4 (the first of them I used for other schematic, but I've reset the flash to make sure the pins are not configured improperly).
I use Arduino as a host. I wire D3 to SWCLK and D4 to SWDIO (with pull-up to 3.3V line). I fail miserably with both chips - i.e. when I expect some ACK be read - it only shows HIGH state on the line all the time.
Here is my code. Could anyone have a look and tell where I went wrong:
int swdck = 3;
int swdio = 4;

void setup() {                
  pinMode(swdck, OUTPUT);
  digitalWrite(swdck, HIGH);
  pinMode(swdio, INPUT);
  digitalWrite(swdio, HIGH);
  Serial.begin(9600);
}

// write some bits from X (least significant first) to SWD
void clockOut(int x, int bits) {
  pinMode(swdio, OUTPUT);
  while (bits > 0) {
    digitalWrite(swdck, LOW);
    digitalWrite(swdio, (x & 1) ? HIGH : LOW);
    delay(1);
    digitalWrite(swdck, HIGH);
    delay(1);
    bits--;
    x >>= 1;
  }
  pinMode(swdio, INPUT);
  digitalWrite(swdio, HIGH);
}

// read some bits from SWD, least significant first
int clockIn(int bits) {
  pinMode(swdio, INPUT);
  digitalWrite(swdio, HIGH);
  int i, res;
  res = 0;
  for (i = 0; i < bits; i++) {
    digitalWrite(swdck, LOW);
    delay(1);
    if (digitalRead(swdio) == HIGH) {
      res += (1 << i);
    }
    digitalWrite(swdck, HIGH);
    delay(1);
  }
  return res;
}

void loop() {
  int x;
  // unlock sequence though it probably is not needed
  clockIn(26); clockIn(26); // more than 50 clocks
  clockOut(0xE79E, 16); // command to switch to SWD
  clockIn(26); clockIn(26);

  clockOut(0x25, 7); // 0b0100101 - request to read Debug-port-0, i.e. ID
  x = clockIn(5); // there should be ACK bits somewhere... but I get 0x1111
  clockIn(26); clockIn(26); // perform more readings for case anything is returned
  Serial.println(x);
  delay(1000);
}


user3493: I am not a SWD expert; it is several years since I read the spec. So I apologise if you are way ahead of me.
I believe ARM's SWD documentation, e.g. "ARM® Debug Interface v5 Architecture Specification" (ARM IHI 0031A) says that transfers are fixed length, starting with an 8 bits request.
The code:
void clockOut(int x, int bits) {
  pinMode(swdio, OUTPUT);
  while (bits > 0) {
    ...
    bits--;
    ...
  }
  ...
}

is invoked with clockOut(0xE79E, 16)
A packet request is 8 bits, followed by a response from the target. So this doesn't appear to follow the protocol.
Similarly clockOut(0x25, 7) appears to send 7 bits, which also looks wrong, and may explain why the read fails.
Further, there should be a 'turnaround bit' after sending the packet.
This code:
void clockOut(int x, int bits) {
  pinMode(swdio, OUTPUT);
  ...
  pinMode(swdio, INPUT);
  digitalWrite(swdio, HIGH);
}

looks like it is setting up to do that, however, it also needs to signal another clock pulse, e.g.:
void clockOut(int x, int bits) {
  pinMode(swdio, OUTPUT);
  ...
  pinMode(swdio, INPUT);
  digitalWrite(swdio, HIGH);
  /* signal a clock pulse */
  digitalWrite(swdck, LOW);
  delay(1);
  digitalWrite(swdck, HIGH);
  delay(1);
 }

A SWD read should return 33 bits, so x = clockIn(5); looks a bit fragile.
Even so, it should get the three ACK bits. It should leave another pile of bits unread, which is what I mean by fragile. 
However, x = clockIn(5); might be incorrect because of the short clockOut(0x25, 7) and lack of a turnaround bit.
Small points:  

I'd change that clockOut while loop to be a for loop like clockIn to make it clear that it is running for a specific 'count' (bits) of bits to be transferred.
delay(1) seems to be a long time between bits. I don't remember any
timing restrictions. However, I would expect the transfers to run
10-100x faster.
IMHO clockIn(26); clockIn(26); seems to be an unnecessarily obscure way
to generate the 50 cycle connection/reset sequence. I'd probably have
a slightly simpler function than clockIn which only generates the
connection/reset sequence.

Edit:
The statement res += (1 << i); in clockIn works. 
However, I had to read it a couple of times to recognise that it is assembling a binary value, and not doing some tricky arithmetic. It is more common to use bitwise operators to assemble a binary value. It is only a small point of style, however res |= (1 << i); might be more clearly constructing a binary value, than res += (1 << i); because it can only ever effect one bit, and never many bits.

15972: <p>So I'm trying to read a bit of data via SWD. I've tried two chips as target - LPC1110 and STM32F030F4 (the first of them I used for other schematic, but I've reset the flash to make sure the pins are not configured improperly).</p>

<p>I use Arduino as a host. I wire D3 to SWCLK and D4 to SWDIO (with pull-up to 3.3V line). I fail miserably with both chips - i.e. when I expect some ACK be read - it only shows HIGH state on the line all the time.</p>

<p>Here is my code. Could anyone have a look and tell where I went wrong:</p>

<pre><code>int swdck = 3;
int swdio = 4;

void setup() {                
  pinMode(swdck, OUTPUT);
  digitalWrite(swdck, HIGH);
  pinMode(swdio, INPUT);
  digitalWrite(swdio, HIGH);
  Serial.begin(9600);
}

// write some bits from X (least significant first) to SWD
void clockOut(int x, int bits) {
  pinMode(swdio, OUTPUT);
  while (bits &gt; 0) {
    digitalWrite(swdck, LOW);
    digitalWrite(swdio, (x &amp; 1) ? HIGH : LOW);
    delay(1);
    digitalWrite(swdck, HIGH);
    delay(1);
    bits--;
    x &gt;&gt;= 1;
  }
  pinMode(swdio, INPUT);
  digitalWrite(swdio, HIGH);
}

// read some bits from SWD, least significant first
int clockIn(int bits) {
  pinMode(swdio, INPUT);
  digitalWrite(swdio, HIGH);
  int i, res;
  res = 0;
  for (i = 0; i &lt; bits; i++) {
    digitalWrite(swdck, LOW);
    delay(1);
    if (digitalRead(swdio) == HIGH) {
      res += (1 &lt;&lt; i);
    }
    digitalWrite(swdck, HIGH);
    delay(1);
  }
  return res;
}

void loop() {
  int x;
  // unlock sequence though it probably is not needed
  clockIn(26); clockIn(26); // more than 50 clocks
  clockOut(0xE79E, 16); // command to switch to SWD
  clockIn(26); clockIn(26);

  clockOut(0x25, 7); // 0b0100101 - request to read Debug-port-0, i.e. ID
  x = clockIn(5); // there should be ACK bits somewhere... but I get 0x1111
  clockIn(26); clockIn(26); // perform more readings for case anything is returned
  Serial.println(x);
  delay(1000);
}
</code></pre>
 3493: <p>I am not a SWD expert; it is several years since I read the spec. So I apologise if you are way ahead of me.</p>

<p>I believe ARM's SWD documentation, e.g. "ARM® Debug Interface v5 Architecture Specification" (ARM IHI 0031A) says that transfers are fixed length, starting with an 8 bits request.</p>

<p>The code:</p>

<pre><code>void clockOut(int x, int bits) {
  pinMode(swdio, OUTPUT);
  while (bits &gt; 0) {
    ...
    bits--;
    ...
  }
  ...
}
</code></pre>

<p>is invoked with <code>clockOut(0xE79E, 16)</code></p>

<p>A packet request is 8 bits, followed by a response from the target. So this doesn't appear to follow the protocol.</p>

<p>Similarly <code>clockOut(0x25, 7)</code> appears to send 7 bits, which also looks wrong, and may explain why the read fails.</p>

<p>Further, there should be a 'turnaround bit' after sending the packet.</p>

<p>This code:</p>

<pre><code>void clockOut(int x, int bits) {
  pinMode(swdio, OUTPUT);
  ...
  pinMode(swdio, INPUT);
  digitalWrite(swdio, HIGH);
}
</code></pre>

<p>looks like it is setting up to do that, however, it also needs to signal another clock pulse, e.g.:</p>

<pre><code>void clockOut(int x, int bits) {
  pinMode(swdio, OUTPUT);
  ...
  pinMode(swdio, INPUT);
  digitalWrite(swdio, HIGH);
  /* signal a clock pulse */
  digitalWrite(swdck, LOW);
  delay(1);
  digitalWrite(swdck, HIGH);
  delay(1);
 }
</code></pre>

<p>A SWD read should return 33 bits, so <code>x = clockIn(5);</code> looks a bit fragile.</p>

<p>Even so, it should get the three ACK bits. It should leave another pile of bits unread, which is what I mean by fragile. </p>

<p>However, <code>x = clockIn(5);</code> might be incorrect because of the short <code>clockOut(0x25, 7)</code> and lack of a turnaround bit.</p>

<p>Small points:  </p>

<ul>
<li>I'd change that <code>clockOut</code> <code>while</code> loop to be a <code>for</code> loop like <code>clockIn</code> to make it clear that it is running for a specific 'count' (bits) of bits to be transferred.</li>
<li><code>delay(1)</code> seems to be a long time between bits. I don't remember any
timing restrictions. However, I would expect the transfers to run
10-100x faster.</li>
<li>IMHO <code>clockIn(26); clockIn(26);</code> seems to be an unnecessarily obscure way
to generate the 50 cycle connection/reset sequence. I'd probably have
a slightly simpler function than <code>clockIn</code> which only generates the
connection/reset sequence.</li>
</ul>

<p>Edit:<br>
The statement <code>res += (1 &lt;&lt; i);</code> in <code>clockIn</code> works. </p>

<p>However, I had to read it a couple of times to recognise that it is assembling a binary value, and not doing some tricky arithmetic. It is more common to use bitwise operators to assemble a binary value. It is only a small point of style, however <code>res |= (1 &lt;&lt; i);</code> might be more clearly constructing a binary value, than <code>res += (1 &lt;&lt; i);</code> because it can only ever effect one bit, and never many bits.</p>
