Could not read ID via SWD with Arduino

Question

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);
}

Please post an explanation of how the ARM-MCU pins are only driven to 3.3V, and not 5V. I assume it is correct, and have only examined the software in my answer. However, it would be helpful to be sure about the pins. — gbulmer
– gbulmer, Commented Dec 30, 2015 at 18:39
Your concern is correct, but it seems like both ARM chips I used (LPC and STM32) have 5v tolerant inputs. On the other side when 3.3V logic signal is feeded to TTL input it is also higher than threshold value so it works all right. Seems like chip manufacturers take these precautions to save people from inventing interfacing circuits... — Alumashka
– Alumashka, Commented Dec 31, 2015 at 7:33
I haven't read LPC specs closely, so them having 5V tolerant SWD pins is very useful to know (it might even be worth updating your question to mention this). I am interested in your results. Have you got this working? — gbulmer
– gbulmer, Commented Jan 6, 2016 at 18:47

gbulmer · Accepted Answer · 2015-12-30 23:43:16Z

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.

Thank you for elaborate answer! I'll try to answer step by step. SWD Request is 8 bits, yes, but the last bit "should not be driven by host on swdio", i.e. at this point host should disable output and simply send another clock. I assume this is performed inside clockIn(5). That is the reason why I have 5 here - I want to send several clocks so that any parking bit, turnaround bit and ack is clocked at once. If any other value than 0x1F will come I hope I can guess where is the ACK in it... — Alumashka
– Alumashka, Commented Dec 31, 2015 at 7:39
As about 0xE79E - I believe it is not a part of SWD protocol at all, just some magic sequence to switch from JTAG to SWD (and there is a back switching sequence). I have no idea whether these chips need it so I've tested with and without it. Anyway, you see, I myself know almost nothing of SWD - I only started reading manuals a couple days ago... So of course I could be wrong in anything or everything. Also thank you for valuable style/design recommendations! — Alumashka
– Alumashka, Commented Dec 31, 2015 at 7:42

Stack Exchange Network

Could not read ID via SWD with Arduino

1 Answer 1

Your Answer

Hot Network Questions

Could not read ID via SWD with Arduino

1 Answer 1

Your Answer

Sign up or log in

Post as a guest

Related

Hot Network Questions