BMOW title
Floppy Emu banner

Atmel ICE Wiring Horror

The Atmel ICE programmer/debugger has its SWD connector pins reversed from the standard ARM Cortex debug connector. Arghh… why? It’s the same physical connector (5×2 0.05 inch polarized male), but the pins are rotated 180 degrees from the standard, as if the cable were plugged in backwards. Incredibly, it also ships with a 180-degree reversing cable, so it works – as long as you use their cable. It’s not a mistake: the product is actually designed around a reversed connector with an un-reversing cable.

WHO BUILDS A PRODUCT THIS WAY?? I shake my fist at you, Atmel hardware designer. This is like designing an electric outlet where 110V and ground are swapped from their normal locations, but bundling it with an appliance cord that unswaps them.

The problem began when I grew tired of Atmel’s tiny 4-inch cable, and decided to get a replacement cable. Naturally I used a standard 10-pin ribbon cable with 5×2 0.05 inch connectors on each end: Adafruit’s purpose-made SWD cable for ARM development. I couldn’t understand why it didn’t work, and why strange things happened when it was plugged in.

After scratching my head for a while, I noticed something odd. The title photo shows both the original cable and the Adafruit cable connected to the Atmel ICE. Notice how one has the red stripe on the right, and the other on the left? Ouch!

From looking at the original Atmel cable, it’s not at all obvious that the pins are reversed. It looks like a straight-through cable, because each connector is crimped straight on to the 10-pin ribbon, with no crossing wires. But a more careful inspection reveals that one of the connectors is crimped on so it’s facing the opposite direction of the other, resulting in a 180-degree rotation of the pin assignments. It violates the rule of the cable’s red wire indicating the location of pin 1. (Ignore the extra 6-pin header, which is used for other devices)

The good news is that there’s no permanent damage to my ARM board. The bad news is that I still need a replacement cable, but now I need to build a reversing one.

Read 7 comments and join the conversation 

7 Comments so far

  1. Andrew H June 13th, 2018 9:08 pm

    You should be able to pop the IDC connector off the end of the cable you got from Adafruit, flip the connector 180 degrees, then either press it into the exact same position it was just in, or trim the cable about 5/16″ and press it back in.

    That, or just trim the alignment peg off one of the connectors. Standard-density IDC connectors are nice and simple to reposition on ribbon cables 🙂

  2. savant June 14th, 2018 1:13 am

    looks like, that some idiot doesn’t reverse connector when tracing pcb, no one finds it, *k boards are manufactured, just trash it? no way, order cables and sell it!

  3. Steve June 14th, 2018 6:42 am

    Yup, I suspect Savant is right about how this happened! Andrew’s method of flipping the connector worked for me, although it was a decent dexterity challenge to release the lock tabs and separate the two halves of the IDC connector. These 0.050 connectors are one-eighth the size of normal connectors.

  4. Steve June 14th, 2018 11:26 am

    Hmm, after yesterday’s backwards cable episode, I’m now getting frequent “Verifying Flash…Failed!” errors when programming the chip. It’s the same with the new or old cable. But it’s strange: it’s always at the same address, with the same expected vs actual value, repeatable 100% of the time if I keep trying it, even if I slow the programmer’s interface clock way down. But if I make a small change to my code, and try programming again, it will often succeed. Then after more code changes the verify error will reappear at a new address, but with the same expected vs actual value.

  5. Steve June 14th, 2018 1:22 pm

    Curious… Atmel Studio 7 generates both an .elf and a .hex file for programming. When you open the Device Programming dialog, the .elf is the default, and it works for programming the ARM, but depending on the program code it also sometimes results in a “Verifying Flash…Failed!” error. If I program the same code to the device using the .hex file, it works fine with no verifying errors. I’m not sure what’s going on here, but it doesn’t seem to be a damaged chip.

    Edit: seems to be a bug in Atmel Studio 7, or somewhere in Atmel’s software toolchain:

  6. opal June 20th, 2018 3:02 am

    Try if erasing the flash makes any difference to the rate of successful/failed programming attempts.

  7. opal June 20th, 2018 3:07 am

    I know it is very suspicious that it started happening when you built the other cable, but give that you see the same behavior with an old cable too – it might very well be a coincidence.

    Set “Project Properties->Tools->Programming Settings: Erase Entire Chip”. And set the “Preserve EEPROM” checkbox (just in case you have some calib, stat or settings data there).

Leave a reply. Comments may not be monitored regularly. For product support questions, visit the Contact page.