Monday, December 6, 2010

Soldering the GoodFET 31

I ordered all of the parts for two GoodFET 31 boards a few weeks ago, and the last of it finally came in today.  The GoodFET is an open source JTAG adapter, which has additional features, much like the bus pirate, allowing it to interface using several other protocols such as SPI or really any other protocol which you feel inspired to script for them.

The challenge of the GoodFET is that it isn't sold anywhere prebuilt, let alone sold as a kit, leaving the only option of ordering a board from the GoodFET team, and the rest of the parts from your standard parts supplier.  Since several of these parts are minimum quantity 10, and you only need two per board, I decided to order enough of everything else to build two complete boards.  The components and blank PCBs worked out to be about $25, which is a pretty good deal for two bus pirate like devices.
The finished boards.

Parts list:
I soldered the boards using the fairly standard solder paste and hot plate reflow technique.  Lacking a solder paste mask means that before reflowing the board, you need to spend a lot of time with a toothpick to make sure you have the amount of paste down correctly to save yourself rework later with solder wick braid and an iron.
Here is a slightly blurry picture of all of the components placed on the board with solder paste.  The exact amount of paste is an art more than a science when manually applied, so don't expect your first few attempts to turn out perfect.  I used a pair of tweezers and a few steel picks to place the parts.  You don't need to get the parts perfectly placed on the pads, but just close enough such that surface tension can do its job to pull them the rest of the way, which you can see in the video.

Reflow Video:

As you can tell, I was really excited in the video.  Unfortunately, the coffee I had while working on the first board started to kick in while I was working on the second board.  It is amazing how much caffeine can destroy your fine motor control.  I managed to drop the molten board, then flick several parts into oblivion on the second board.  The surface tension worked beautifully for this first board to pull in all the parts, but I didn't get the chips centered close enough on the second one, which then reflowed the 232 chip one pad off, which meant reflowing the board and edging it over into place.

As you can see in this (amazing) photo (thanks, prosumer camera!), the first board had a little too much solder paste on the IC pads.  This meant some manual rework with a soldering iron, flux, and copper braid to pull out the extra solder between pins.  A 30x jewelers loupe definitely helps find the less obvious bridges.

After rework, the solder bridges were all taken care of, the board checked for shorts and opens, and we're ready to plug it in to reprogram it.

I programmed these GoodFETs using my desktop running Ubuntu 10.04, and ran into some problems along the way.  The infodumps ran fine for both boards, but when it came time to program the MSP430s with the GoodFET firmware, the script kept dying.  90% of the time it gave a timeout error like the following, 7% of the time it gave a NACK error (bad password), and 3% of the time, it programmed fine.


kenneth@KWF2:~/prog/goodfet$ sudo goodfet.bsl --fromweb
MSP430 Bootstrap Loader Version: 1.39-goodfet-8
Use -h for help
Use --fromweb to upgrade a GoodFET.
Mass Erase...
MSP430 Bootstrap Loader Version: 1.39-goodfet-8
Use -h for help
Use --fromweb to upgrade a GoodFET.
Mass Erase...
Transmit default password ...
Invoking BSL...
Transmit default password ...
Current bootstrap loader version: 2.2 (Device ID: f227)
Grabbing f227 firmware.
http://goodfet.sourceforge.net/dist/msp430x2274.hex
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 33993  100 33993    0     0  46812      0 --:--:-- --:--:-- --:--:-- 80743
Program ...
Traceback (most recent call last):
  File "/usr/local/bin/goodfet.bsl", line 1750, in 
    main(0);
  File "/usr/local/bin/goodfet.bsl", line 1688, in main
    for f in todo: f()                          #work through todo list
  File "/usr/local/bin/goodfet.bsl", line 1151, in actionFromweb
    self.programData(fw, self.ACTION_PROGRAM | self.ACTION_VERIFY)
  File "/usr/local/bin/goodfet.bsl", line 925, in programData
    self.programBlk(currentAddr, seg.data[pstart:pstart+length], action)
  File "/usr/local/bin/goodfet.bsl", line 910, in programBlk
    self.verifyBlk(addr, blkout, action & self.ACTION_VERIFY)
  File "/usr/local/bin/goodfet.bsl", line 873, in verifyBlk
    blkin = self.bslTxRx(self.BSL_RXBLK, addr, len(blkout))
  File "/usr/local/bin/goodfet.bsl", line 668, in bslTxRx
    rxFrame = self.comTxRx(cmd, dataOut, len(dataOut))  #Send frame
  File "/usr/local/bin/goodfet.bsl", line 445, in comTxRx
    rxFrame = self.comRxFrame(rxNum)
  File "/usr/local/bin/goodfet.bsl", line 362, in comRxFrame
    if len(rxFramedata) != rxLengthCRC: raise BSLException("Timeout")
__main__.BSLException: Timeout


The few times I did manage to flash the firmware, the self-test went down in flames:

kenneth@KWF2:~/prog/goodfet$ goodfet.monitor test
Performing monitor self-test.
Warning: waiting for serial read timed out (most likely).
Echo test failed.
Warning: waiting for serial read timed out (most likely).
Warning: waiting for serial read timed out (most likely).
Warning: waiting for serial read timed out (most likely).
ERROR Fetched 0154, 0302
Warning: waiting for serial read timed out (most likely).
Warning: waiting for serial read timed out (most likely).
ERROR, P1OUT not cleared.
Warning: waiting for serial read timed out (most likely).
Warning: waiting for serial read timed out (most likely).
Echo test failed.
Warning: waiting for serial read timed out (most likely).
Warning: waiting for serial read timed out (most likely).
Warning: waiting for serial read timed out (most likely).
Warning: waiting for serial read timed out (most likely).
ERROR Fetched 0100, 0302
Warning: waiting for serial read timed out (most likely).
Warning: waiting for serial read timed out (most likely).
ERROR, P1OUT not cleared.
Warning: waiting for serial read timed out (most likely).
Warning: waiting for serial read timed out (most likely).
Echo test failed.
Warning: waiting for serial read timed out (most likely).
Warning: waiting for serial read timed out (most likely).
Warning: waiting for serial read timed out (most likely).
##### FOR AS LONG AS YOUR WILLING
TO WATCH IT SCROLL BY #####


This wasn't good.  I double checked the boards, but since the infodumps worked, it looks like we're looking at an intermittent software problem, which is THE WORST KIND OF PROBLEM.
Long story short, some poking around yielded that another program, upowerd, was fighting with python over control of the serial port, which was screwing the bit-banging required to program it.

kenneth@KWF2:~/prog/goodfet$ sudo lsof | grep USB
[sudo] password for kenneth: 
lsof: WARNING: can't stat() fuse.gvfs-fuse-daemon file system /home/kenneth/.gvfs
      Output information may be incomplete.
upowerd   1501          root   11u      CHR      188,0      0t0      18775 /dev/ttyUSB0
python    2389          root    3r      CHR      188,0      0t0      18775 /dev/ttyUSB0

Everyone thank Ubuntu once more for doing more than we asked or wanted it to do, screwing the advanced users yet again.

One "sudo killall upowerd" later, the boards programmed and self-tested fine.  Killing upowerd to use my GoodFET is pretty annoying though, so some more digging was in order.  Between trawling upowerd bug reports, and running /usr/lib/upower/upowerd -v, I finally figured out what the problem was.

Turns out, the problem is that there was some random device made by Watts Up, Inc., which happened to use the FTDI 232 chip (USB ID 0403:6001).  Udev then uses this very generic USB ID (try running lsusb) to identify this specific device, and screws everyone with cheap USB-to-RS232 adapters.  The fix is relatively simple, if obscure.  Delete, or comment out, the udev rule for this device, which is typically stored in /lib/udev/rules.d/95-upower-wup.rules.  Reboot or restart of upowerd later, the GoodFET works fine in Ubuntu.

<evil glare at Ubuntu />


Obviously, it's unlikely I'll ever be using two of these at once, so if anyone wants to give me their best offer, I might be able to be talked into parting with one of these babies, or even make you some more, for $40 (Parts, labor, US shipping).

Edit 2011-02-18: Alex has bought my second board, but I will certainly be willing to purchase, assemble, and ship additional boards for anyone.  You'll just suffer the additional lead-time of me not having the primary components in stock.

7 comments:

  1. I've never watched reflowing happening before; yup, that's pretty damn cool. Might have to have a go (especially since those tiny Atmega TQFPs look like a bugger to hand-solder).

    If you find another spare hotplate in your uni, I'll pay the postage to the UK :)

    ReplyDelete
  2. could you post please post the complete digikey partlist? thanks!

    ReplyDelete
  3. Hey there. I have ruined two GoodFet boards and MSP chips trying to get this working. I don't have access to a hotplate and have been trying to get the reflow working on a stove top. I am just not cut out for SMD work I guess. Are you still up for making one or perhaps selling one of your others? I would be really interested.

    Thanks,
    Alex (alexearl@gmail.com)

    ReplyDelete
  4. Hi!
    I'm developing a PCB that has an USB male connector (like this one) and I would like to know which is the PCB thickness that you are using.
    Is it 1.8 or 2.0 mm?
    Thanks very much!

    ReplyDelete
  5. Travis designed the board, so you may ping him for specific tricks, but my calipers read 2.15mm

    ReplyDelete
  6. Great Post! Loved the hot plate reflow video! I put together another parts list here if it helps anyone: http://www.reddit.com/r/netsec/comments/10g7f0/goodfetfacedancer_parts_list/

    ReplyDelete