I just had a very quick look into what could be done to fix the FET430 UIF firmware loading issue I wrote about before. The issue looks like it was fixed in this commit. That’s in Linux 2.6.29, which was released 6 days ago.
No work for me to do there then…
Connectors are expensive. PCB space is too. Therefore PCB designers try to reduce the number of pins on connectors and the space that they take up on the PCB. On MSP430 boards, the programming and debugging connector is very often subject to this reduction.
TI uses a 14 pin connector on basically all their demonstration boards. This has unused pins — and these immediately get sacrificed when designing real boards. The engineer may also attempt to arrange the connector so that plugging the lead in the wrong way around doesn’t do any fatal damage. This leads to different connectors pinouts being adopted by different engineers.
I got fed up of making adapters for basically every board that I came across. Keeping track of them once I’d made them was also an issue. I now have a component draw completely full of stripboard adapters. So I built a universal adapter, which I have named the “univ430”:
The 14 pin connector on the right-hand side is the connector that goes to the MSP430 programmer, and the connector on the left-hand side connects to the target board. The jumpers in the middle allow any useful signal on the 14 pin connector to be connected to any of the other connector’s 8 pins. The jumper that looks out of place at the top right of the board is for selecting whether the programmer should power the target board.
So now moving from programming/debugging one board to another is just a matter of moving some jumpers around on a board. The markings on the univ430 contain enough information for one to reconfigure the mapping given the target connector’s pinout. However, after doing this a few times and telling others how to do it with theirs, I found that this process could be a little tedious. So I wrote a utility that takes in a file containing the pinout of the target connector and outputs a diagram that looks like the one on the right.
You can grab the source from the git repository:
git clone git://gitorious.org/univ430-map/mainline.git univ430-map
Then build:
% cd univ430-map % make
Have a look at the signals that you can put in your connector map by reading the MAP file.
% cat MAP A: 1) TCK 2) TEST 3) VCC 4) GND B: 1) RST 2) TDO/TDI 3) TDI/VPP 4) TMS
Create your connector map file. I now try to put these maps in with the source code of all the msp430 projects I’m involved with, in a file called “jtag-map”. Here’s the map for the Student Robotics motor controller:
vcc tdo/tdi tck gnd
Getting the tool to generate the image is straight-forward:
./univ430-map -o map.png jtag-map
Your jumper layout will then be in map.png :-)
A Fedora RPM for this is coming soon, as is a connector for EZ430 programmers.
Just a quick note that might help some people. After the Fedora update to 2.6.27, the UIF stopped working. This is because (I think) all of binary firmwares that the kernel has in it have now been moved outside the kernel itself. The driver for the UIF looks for “ti_usb-3410.bin” which doesn’t exist. This is due to some sort of naming problem. A temporary fix to this problem is:
su -c "cp /lib/firmware/ti_3410.fw /lib/firmware/ti_usb-3410.bin"
I’ll look into whether there are any open bugs on this soon.
I spent today working on a bug in the driver for the TI UIF MSP430 programmer. It stopped initialising properly in 2.6.24, but it worked in 2.6.23. I did a git-bisect between those versions to find the commit that induced the fault. I narrowed the search a bit by telling git-bisect to work on commits only in drivers/usb/, as I hypothesized that the bug was induced somewhere in there.
About 10 builds and 20 reboots later, I found the commit in which the problem was happening, and then read some stuff about USB etc (the LWN device drivers book proved invaluable yet again) and subsequently generated a patch. I’ve sent it to (what I think are) the right places.
If you can’t wait for the next kernel release (if it passes review…), then you can rebuild the ti_usb_3410_5052 module by downloading this tarball, untarring it and then running “make” in the resulting directory, and then “make install” as root. You will need enough of your kernel’s sources hanging around to do this. In Fedora, these are provided in the kernel-devel package.
Update (5th April ’08): The patch has made its way into Linus’s tree, so I think it’ll be in 2.6.25.
Site by Rob Gilton. © 2008 - 2019