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…
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.
I picked up 7 cables for $2.67 each with free (slow) shipping by mail…
From Hong Kong.
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.
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.
It took a bit of careful carving to get the shell open.
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…
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.
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.
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.
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).
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.
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).
Then I tied the TX and RX together in a loopback so that whatever was sent out of the dongle should come back.
That worked! I was getting double characters here because I had local echo turned on in Hyperterminal. So TX and RX confirmed.
I hooked up my trusty Saleae Logic to 8 of the pins to see how that worked.
Here’s a TX signal I generated by pressing D while in Hyperterminal.
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:
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.
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
Using some wiring headers gathered from old PC’s I crazy-glued 2 1×3 female headers together to make a 1×6.
And then inserted the wires back into the shell in the correct order.
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.
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.
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…