kwartzlab makerspace

Apr
23

Reverse Engineering a Cheap Arduino Programming Cable

By

FTDI_cable_clone 048

If you remember the badges from SoOnCon in Hamilton last year, you’ll remember that the Thinkhaus crew came up with a great minimal-Arduino design based on the LilyPad. You may also recall that we needed a USB-to-TTL serial cable to upload our own custom code to these badges, since slimmed-down Arduinos often omit the onboard USB chip to cut costs.

One solution is to use a $20 cable from FTDI, which we did for SoOnCon, sharing one cable among 8 makers, but I was hoping there was a cheaper approach. When I got back to Waterloo, a little googling turned up a number of DIY’ers who had converted cheap cellphone data cables into Arduino-programming cables. This post outlines some of the 10 hours I spent getting that working. As useful as this new $2.67 cable (shown above) is, I’m hoping that more useful is a description of the methodology of reverse engineering a simple hardware device. Read on for details…

More after the break…


FTDI_cable_clone 075

The CA-42 “Nokia” cellphone data cable was shown to be a good start for an Arduino cable conversion. Recognizable IC’s with part numbers screened on. Piece of cake! Search eBay for “CA-42″ and you’ll find tons. Beware the old cheap-sale-price-expensive-shipping phenomenon.

FTDI_cable_clone 071

I picked up 7 cables for $2.67 each with free (slow) shipping by mail…

FTDI_cable_clone 070

From Hong Kong.

FTDI_cable_clone 002

First thing: take lots of photos and notes along the way. I plugged the cable in to my laptop cancelled the auto-initiated driver install process. Then I went into XP Device Manager and looked at the properties on the “Unknown” USB device. On the Details tab, under “Device Instance Id” I got “USB\VID_067B&PID_2303\5&2A97E42B&0&1″. Decoding this a bit for you, the Vendor ID (VID) is 067B. Each vendor pays a chunk of money to the certifying body to get a unique VID. The PID, 2303, is the product code. The combination of VID and PID uniquely identify a particular type of device.

Googling “USB VID 067B” gave this link to a linux-related data file of VID’s.

067b  Prolific Technology, Inc.
    0000  PL2301 USB-USB Bridge
    0001  PL2302 USB-USB Bridge
    04bb  PL2303 Serial (IODATA USB-RSAQ2)
    0610  Onext EG210U MODEM
    0611  AlDiga AL-11U Quad-band GSM/GPRS/EDGE modem
    2303  PL2303 Serial Port
    2305  PL2305 Parallel Port

This snippet of the data shows the vendor is Prolific Technology and the product is the PL2303 Serial. A little more googling leads to the drivers at the Prolific download page.

After running the driver install, the cable showed up as Prolific USB-to-Serial Comm Port (COM14). So far so good.

Then I cracked open the shell.

FTDI_cable_clone 008

Another approach to finding drivers is to google the labelled part numbers, but that can be hit and miss. VID/PID discovery is more reliable.

FTDI_cable_clone 011

It took a bit of careful carving to get the shell open.

FTDI_cable_clone 015

Not much to see on this side. Bunch of unpopulated parts (PCB pads with no parts on them). That’s pretty common when manufacturers use a single board design for multiple products. Then flipping it over…

FTDI_cable_clone 018

Oh no! The dreaded blob of black epoxy. Instead of finding nice labelled chips, I get chip-on-board! This is a cost-saving approach to volume production where the silicon die is wire-bonded straight to the printed circuit board and then gooped with epoxy for mechanical robustness. This sort of blows my whole follow-the-other-guy’s-tutorial, but it also poses an interesting challenge.

The pinout for Nokia phones is well-covered on the net, and with a continuity tester I traced back from the Nokia connector to the PCB.

FTDI_cable_clone 027

So I found that:

phone connector pin 8 (GND) –> orange wire –> PCB pad 6

phone connector pin 7 (TX) –> blue wire –> PCB pad 12

phone connector pin 6 (RX) –> red wire –> PCB pad 9

I only had 3 conductors (not 4) in this cable, no 3.3V, which is probably just cost savings. I confirmed the ground (GND) connection with my continuity tester from the USB connection back to PCB pad 6: connected! A similar test showed that the USB Vcc was connected to PCB pad 2.

FTDI_cable_clone_2010-04-12 008

Next, I soldered on some short test leads to all 12 pads and plugged the device into a USB hub. Important to use the hub as it can be replaced for $10 in the event of an accidental crossing of wires, whereas repairing a blown laptop USB port is expensive if doable at all.

Here the leads are hooked to my oscilloscope probes.

FTDI_cable_clone_2010-04-12 013

Here I was just looking for any pads that looked like outputs, i.e. if I did something to COM14 then I’d see a trace wiggle (as the bottom one shows above).

mode_command_dtr

I haven’t fooled around with COM ports for a while, so I needed some tools. In a jam, you can use the MODE command from a command line in XP. So doing a “MODE COM14 DTR=ON” and then “MODE COM14 DTR=OFF” helped me track down the DTR pad. At this point I had identified: Vcc, GND, TX, RX, DTR. 5 pads down 7 to go.

FTDI_cable_clone_2010-04-12 015

Using my digital multimeter, I measured voltages on all the pads when (a) the dongle was plugged in and then (b) when Hyperterminal had opened COM14. I suspected that the pads that were floating around 0.2V were probably inputs (versus outputs).

FTDI_cable_clone_2010-04-12 022

Then I tied the TX and RX together in a loopback so that whatever was sent out of the dongle should come back.

hyperterm_local_echo_loopback

That worked! I was getting double characters here because I had local echo turned on in Hyperterminal. So TX and RX confirmed.

FTDI_cable_clone 033

I hooked up my trusty Saleae Logic to 8 of the pins to see how that worked.

logic_TX_line

Here’s a TX signal I generated by pressing D while in Hyperterminal.

realterm_DTR_finds_DSR_set

And then Ed Blanchard, serial guru, put me on to RealTerm so I could see the status of the various pins and manual toggle the outputs. Perfect! (thanks Ed).

logic_DTR_line

Here’s the DTR output signal when I toggled that output in RealTerm. using RealTerm and the Logic I found the RTS output. That gave me all the outputs: TX, DTR, RTS. All that remained were the inputs. So using the loopback approach again, I sequentially wired DTR to each suspected input, toggled DTR, and watched the status pane in RealTerm to see what pin was toggling. So for the search engines out there, here’s the pad pinout for the PCB in this cable:

1 – n/c
2 – Vcc USB
3 – RING (input)
4 – CTS (input)
5 – n/c
6 – GND
7 – DCD (input)
8 – DSR (input)
9 – RX (input)
10 – RTS (output)
11 – DTR (output)
12 – TX (output)

Cable shell marked:
CA-42
R/N: 108382627301
M/N: CX-U8A
PCB marked:
YQW-068

FTDI_cable_clone 041

And after much reading and some confusion on the accepted 6-pin pinout for these programming cables, I had this, which is the layout of the defacto standard $20 FTDI cable. But for Arduino applications, I learned that RTS/CTS flow control isn’t used and it’s preferable to instead do a no-connect on CTS and substitute DTR for RTS. This allows the Arduino software to use DTR on the Arduino RESET pin to reboot after new code is loaded. This is said to be more reliable than using the RTS line.

FTDI_cable_clone 042

So the final cable setup is:
CA-42 dongle –> PCB pad –> wire colour –> 6-pin programming header
GND –> 6 –> black –> 1
n/c –> 4 –> brown –> 2
Vcc –> 2 –> red –> 3
TX –> 12 –> orange –> 4
RX –> 9 –> yellow –> 5
DTR –> 10 –> green –> 6

FTDI_cable_clone 044

Using some wiring headers gathered from old PC’s I crazy-glued 2 1×3 female headers together to make a 1×6.

FTDI_cable_clone 048

And then inserted the wires back into the shell in the correct order.

FTDI_cable_clone 049

Hooking this up to my SoOnCon badge led to timeouts trying to download code to the Arduino, and then Ben reminded me to set the Arduino IDE to “LilyPad” and also mentioned the bug where you have to unplug and then replug occasionally to get code downloading. That was the ticket! First new code loaded on this board since October 3, 2009.

FTDI_cable_clone 068

While the outputs on the USB dongle are 3.3V logic, they seem tolerant of this Arudino running off the 5V USB feed. The official FTDI cables come in 3.3V and 5V variants and I’m sure there’s something to think about there with level-shifting, but for now, this appears to be working.

I guess now I can use these really cheap USB-to-TTL cables to add USB capability to my other microcontroller projects too. Just need to hook the TX/RX to the microcontroller’s UART and away we go.

FTDI_cable_clone 055

And if the gods can sort out the shortage of ATMEGA328 chips, I would like to build a bunch of these low-cost Arduinos to stick them in various projects at <$15 each. Now back to our regularly scheduled projects…

Happy making,
DW