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.
11 responses to “UIF Fixing”
Site by Rob Gilton. © 2008 - 2019
Thanks for this. Do you have to change the udev rule as well? Mine doesn’t seem to work any more…
I’ve just realised that I hadn’t updated the udev rule I was using. It’s now:
Thanks again. As is the way of things, I stumbled on the right rule before you answered. gdbproxy now works fine. All that’s lacking is a command line tool to program the flash – the linux ones all seem restricted to the parallel port, as far as I can make out.
msp430-gdbproxy is actually for the parallel port programmer and the USB programmers. You invoke it like this:
Or if you’re using a spy-bi-wire thing:
Sorry Rob, I wasn’t clear. I know about gdbproxy – and I have used it already both with parallel and usb versions. What I meant is I’d like a single command that just programs the flash – that I can run from a Makefile. That’s how I used to do things with my trusty old parallel port programmer and the msp430-jtag utility (“mp430-jtag -eEpv foo.elf”). Plug in the jtag lead, “make” to build, “make program” to program to flash, job done. You can’t do that with gdbproxy. But msp430-jtag seems to be parallel port only. Maybe if I delve into the gdbproxy code I could figure out how to write such a utility…
Any chance of the newer programming tools that come with the ez430-rf2500 working with this driver? or possibly any in the future? I got a kit at 430 day but haven’t been able to use it yet :(
hey, i was directed this way by stephen. ive mad the tarball from the source provided above, and copied the .ko file to /lib/modules/…. ive created my udev rule, but when i plug in the uif, or an ez430, i still get the failed with error -5 issue, and i cannot do the echo to bConfigurationValue trick, it says permission denied, even when using sudo… any ideas?
You’ll need to run “make install”, rather than copying the .ko file into /lib/modules. That way, modules.dep will be sorted out properly etc.
So i cleaned everything up, and ran make, make install. I also changed my udev rule to match above. however i still get the -5 error, and no /dev/ttyUSB0. and I cant manually echo 2 to bConfigurationValue. could it be a problem with sysfs? are you running on a 32 or 64 bit machine?
A 32-bit machine, but I don’t think that should affect this. What kernel version are you building this on? Have you unloaded the old module before using the new one?
I installed this fix on Ubuntu Hardy, and it worked with my eZ430-F2013 rev 2.0. Once.
The next time I tried to use it, it wouldn’t get through device enumeration. Sometimes I get an address assignment, and sometimes I don’t. It’s also not recognized on a Windoze box.
There are log messages indicating that the driver “changed” the firmware. Unfortunately, it appears to have been “changed” into a brick.