The JTAG Tiny hack.
Annoyingly, our replacement JTAG programmer (for the Driver Controls Unit, we have a $7 programmer for the BMUs, Neville) had not arrived for EV day. We did however have the replacement CP2102 USB-to-UART chip, which was obviously fried. I arrived late, and Weber had valiantly soldered in the 28 pin replacement chip.
We didn't think that just replacing the chip would work, but for $3 and a bit of fiddling, we thought it would be worth a try. Well' it didn't work, the programming software said it could not connect.
Something prompted me to check the Device Manager; sure enough, there was an unfamiliar new device with the yellow warning triangle. I tried to reinstall the driver, but Windows said it could not find the driver. I recall we had a lot of trouble installing the driver last time.
Weber recalled that he thought it was odd that there were so few pins of the chip that seemed to connect anywhere, so let's check the datasheet. Right away he notices something I had missed: the chip contains an EEPROM for storing the VID (Vendor ID), PID (Product ID), and device identifier that you will want to customise for your driver. Of course! Every USB device should respond with these unique IDs, so Windows knows what software to use to drive it. "We're screwed" was approximately his comment. (You can see the EEPROM at the bottom of the above block diagram; I somehow missed this on first seeing the datasheet.)
[ Edit: the unused pins were normal. About 12 pins are simply unused, and half a dozen were to support unneeded RS232 functions, such as Data Terminal Ready. ]
I must say I was inclined to agree that we're screwed. However, I still saw a faint hope.
The chip that had the original data from that EEPROM is long fried, and is in any case desoldered. But I reasoned that the magic numbers (VID, PID, etc) had to be in the Windows registry somewhere; after all, that's where Windows looks for device driver information when a new USB device is plugged in. So on the kitchen table I fired up trusty old regedit (a registry editor that comes with Windows), and did a search on "Olimex" (the JTAG programmer manufacturer). Sure enough, we must have used the JTAG Tiny with this machine, as I soon found a string with "USB\Vid_15ba&Pid_0002&Rev_0100" and another with a LocationInformation set to "OLIMEX MSP430 JTAG TINY". But how to get this data into the EEPROM on the chip?
I read in the datasheet that manufacturers can download from Silicon Labs a "stand alone utility" that would program this EEPROM. This sounded hopeful, and I soon found the tools page on the
silabs.com website. There were a dozen or so downloads: some starting with AN which I took to be application notes, drivers for Linux, Mac, and Windows. I downloaded the most promising looking ones, especially the two with version numbers, but while some looked promising (e.g. a wizard of some sort), none seemed to be the utility to program the EEPROM. Oh well, I guess if you are a real manufacturer, you'll know who to talk to and will get access through some sort of technical grape vine. I'd about given up at this point.
However, Weber spotted a clue in the datasheet that the programming tool was in application note AN144; it seems that the files in the tools section starting with AN weren't the actual application notes; these were in the document section. When we looked inside AN144sw.zip (duh, the sw might stand for SoftWare), we found an executable program. Soon, we had up a big dialog box that asked us for VID, PID, and device description.
We plugged the values from the registry into the programmer form, decided that the power capabilities and a few other things could stay at default values, and decided we had nothing to lose from pressing the "Update device" button.
We did this, and a second later Windows popped up a window complaining that it didn't know how to deal with the new hardware. Hmmm... that didn't sound good. Though it was hopeful in a way, since Windows seemed to be aware of new hardware, which means that surely the device actually did get programmed (over its own USB port... USB is kind of nifty that way). So just maybe, if we plugged the JTAG programmer into the netbook in the car that we were using for actual programming, it might just work.
Ok, down to the car, we plug everything in, and attempt to verify the DCU software with the latest binary image we had compiled.... success! It verified true! Immediately Weber had ideas of cancelling the order of the new JTAG programmer... clearly we didn't need to buy a new one after all! I cautioned that we hadn't attempted to actually program with the repaired programmer, or indeed use it for debugging yet.
So I reconfigured for debugging, pressed the "debug without downloading" button and... "cannot access the device" (or similar). Damn! To have come so far! There was an error message about not being able to access the VCP (Virtual Communications Port). I hunted for the VCP port setting, and suddenly realised that I had unplugged the USB cable for some reason... D'Oh!
I plugged it back in, and it was working as normal. I was able to download and flash a newly compiled image as well.
Wow, what a hack. At about this point, Weber felt the urge to check the letterbox to see if maybe there was a card waiting there saying that there was a missed delivery and perhaps we could have picked up the unit by now anyway! Well, there was no card. Instead, the actual programmer had arrived, presumably some time while we were mucking about with the replacement chip or attempting to program it.
Heh.
Now we have a spare JTAG programmer. It's marked "V2", so maybe it will have some amazing new features. I guess we'll find out some day if we actually plug it in and use it.
For what it's worth, I felt that our "communications glitches" are looking more and more like they might be straight errors in the DCU code (the parts we've modified for talking to the BMUs). The last thing we discovered before I had to rush off to a Christmas dinner was that we are transmitting a bunch of nulls after our voltage command. (This is after a few rearrangements of the code). Or at the very least, these bugs are another thing we have to fix before we can use the DCU code to provoke the real communications glitches, if they actually exist.
However, Weber pointed out to me that this can't be the case; we had everything working reliably on the bench. It's just that we rewrote the interrupt routines to use proper circular buffers and separate copies of these buffers in the mainline code, and are merely seeing the effects of all the new bugs that this major change brought with it.
[ Edit: moved the discovery of magic numbers from registry earlier to reflect the true order of events. ]