Sunday, January 8, 2012

Troubles with IM-ME and the GoodFET

I have been spending some time recently with my IM-ME Pretty Pink Pager and my GoodFET.  Most of this time has been unproductive, unfortunately.  I think I might finally have sorted out all the issues causing this, and I'm using this post as an opportunity to record it all so I know what to do next time, if there is a next time.  This is all running under Linux: your mileage will vary under another OS.

I came across my first hurdle some months ago.  Commands like this:
goodfet.bsl --fromweb
goodfet.monitor test
would give me this:
These messages would spit out every couple of seconds.  Now these commands don't require any kind of connection from the GoodFET to the IM-ME: the messages indicate that the laptop and my GoodFET can't communicate.  After much pulling out of hair (made more painful with the fact that my head is shaved), I discovered that my GoodFET PCB had two bad vias.  Unfortunately, these vias were under the processor, and the processor is surface mounted to the PCB.  It took some tricky soldering, but I was able to patch around these vias and get back in business.  However, it seems I needed to use the --slow parameter to goodfet.bsl to get it to work.  Whatever, I was happy.
Tricky Soldering
Then over the Christmas break, I broke out the IM-ME and the GoodFET in the hopes of getting something productive done.  No way.
This would again spit out once every couple of seconds despite the fact everything seemed to be working well the last time I'd left it.  More hair pulling ensued.  Nothing would work.  In a fit of desperation, I went back to an older version of the GoodFET client that I had on my laptop.

It worked perfectly.

I'm not sure why (maybe this?), and right now I don't care.  But a fairly recent version of the GoodFET client software was totally broken for me.  The client dating back to Feb 26th 2011 works great.  And I just checked out the lastest SVN version of the GoodFET code and that is worked great as well.  Just my luck.

So everything is working.  Fantastic.  I sit down at my laptop this afternoon to see if I can get something productive done once again.
Argh!  This time the messages were flooding across my terminal window.  Last time, they were separated by a second or two.  This seemed to be more an issue on the laptop side than the GoodFET.  I had noted that the laptop had been put to sleep since it was last working.  "Simple enough", thought I.  Something wasn't being handled coming out of sleep and all I needed to do was unplug the GoodFET's USB connection and plug it back in again.  No luck.  Taking the batteries out of the IM-ME while unplugged from USB either didn't help.  Restarting the laptop fixed the problem, but the problem would come back every time coming out of sleep.  A bit of Googling and I came across a blog post from years ago that discussed a fix for a similar problem for stuck USB memory sticks.  That particular trick didn't work for me, but this one does.  As root:
# modprobe -vr ftdi_sio
# modprobe -v ftdi_sio
The ftdi module is responsible for communicating with the USB to Serial chip (FTDI FT232RL) on the GoodFET.  Apparently, the ftdi driver has a sleep problem of some kind.  Removing and re-inserting the ftdi module sorts things out.  This is with the 3.1 Linux kernel, BTW.  Hopefully this gets fixed sometime.

I noticed that the Feb 26th version of the GoodFET client software would flood the screen with Resyncing messages after the laptop came out of sleep, but the latest version of the software does the usual message every second or two.   Dunno why this is.  Either way, the modprobe dance above fixes either version.

Finally, if you see something like this:
[dk@laptop client]$ info
  File "/usr/local/bin/", line 22
    print "# %s" %s;
SyntaxError: invalid syntax
then you are getting burned by Python versions.  Distributions like Arch Linux default to Python3, but the GoodFET client assumes Python2.  To fix this, edit the first line of the various GoodFET scripts you use from this:
#!/usr/bin/env python
to this:
#!/usr/bin/env python2
and you'll be good to go.

Now to get something useful done...

ADDENDUM: So just after posting this, what did I get?  You guessed it..
The only thing I changed this time was the USB cable.  I went from a longer, more flexible cable with a choke at the end to a shorter, stiffer cable with no choke.  Operation with this shorter, cheaper cable is definitely unreliable.  Moral of the story: try a different cable if all else fails.

1 comment:

  1. Having built more than 30 GoodFETs, I've seen this quite a bit. It usually means you still have a cold solder joint somewhere, so if you have liquid flux, apply it, and just reflow all the joints again. 75% of the time, that fixes it. The other 25% of the time, one of the chips is toast and I need to replace it.