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:
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.
The few times I did manage to flash the firmware, the self-test went down in flames:
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.
Everyone thank Ubuntu once more for doing more than we asked or wanted it to do, screwing the advanced users yet again.
One "
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
<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.
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.
Parts list:
- GoodFET31 Board (SourceForge)
- FT232RL (Digikey $4.50)
- MSP430F2274 (Digikey $7.16)
- 2x 0.1μF capacitor (Digikey $0.08)
- 3x LED (Digikey Red, Green, Blue)
- 2x 330Ω resistor (Digikey $0.02)
- Headers for GPIO and IO pins of the gender of your choice.
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.
!), 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.
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, inmain(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.
