I’ve been hacking away at fetproxy for the past couple of days. I’m now at this stage:
[rob@prefect fetproxy]$ msp430-gdb -n GNU gdb 6.8 Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "--host=i686-pc-linux-gnu --target=msp430". (gdb) target remote localhost:2000 Remote debugging using localhost:2000 0x0000f800 in ?? () (gdb) info r pc/r0: f800 sp/r1: 7a00 sr/r2: 0000 r3: 0000 fp/r4: 7a00 r5: ff00 r6: 7f00 r7: ff00 r8: ff00 r9: ff00 r10: bf00 r11: f700 r12: bf00 r13: ff00 r14: fd00 r15: 0000 (gdb)
That’s where it’s at right now on my machine. gdb can now read the registers of the target device. The “continue” command’s next…
Just under 3 months ago, Tom and I reverse engineered the protocol to talk to the TI FET430UIF MSP430 debugger.
We weren’t confident that we could release the source without legal repercussions. We couldn’t really afford to pay a solicitor to find out what our legal position was (I got a quote from one of £600). We gave the problem some thought.
After many discussions about what we could do, we decided to send a letter to TI to ask them whether they’d mind us releasing our code as open source. That letter is here on the right. Click on it to be able to read it. (You may notice that I’ve blacked out my address.)
Today I got a phone call from Thomas Mitnacht, who is Texas Instrument’s Development Tools Manager for MSP430 Microcontrollers and is based in Munich. After I’d explained to him why we’d reverse engineered the protocol, he said that he was happy for it to be released as open source. This is amazing. Thank you Thomas Mitnacht and TI!. I was quite surprised how quickly TI responded to this request.
He said he’d prefer for it to be under LGPL or GPL version 2 so that they could use the code, as apparently they’re not sure yet about how to deal with the patent requirements that GPLv3 has. Personally, I think the patent clauses in GPLv3 are useful and will help to make our software more free. However, given that TI could have given us a much harder time about this, I’m willing to release it under version 2.
Thomas also informed me about some important things to do with the MSP430 debugger. They’re not able to release the source code of their FET430 interface library at the moment. I think this is because of some licensing issues they have with that code. They’re working on a replacement library that will be open source and available at the end of this year. Sounds good. I’m looking forward to it.
I’m extremely happy to release the source code that Tom and I hacked together at 25C3. It’s a bit dirty at the moment, but now that we can have it out in the open we’ll definitely be putting more work into it.
Quit rambling, just give me the code!
I’ve put the code up in a git repository on gitorious. You can grab it like this:
git clone git://gitorious.org/fetproxy/mainline.git fetproxy
Several people have emailed me over the last couple of months asking me for the source. I’ve had to give them all a bit of a disappointing reply, which was “sorry, please wait”. If you’re one of those people, I hope that you understood.
P.S. Further good news: My msp430-gcc Fedora package passed its review a couple of days ago. It’ll hopefully be shipping within the next week.
After a bit of a delay, msp430-binutils, the first of my gcc packages is now part of Fedora 10. I’m now a sponsored (a.k.a. approved) Fedora packager :-D
So it can now be installed by running:
yum install msp430-binutils
Or, if you’re of PackageKit persuasion:
pkcon install msp430-binutils
msp430-binutils contains a number of tools for working with msp430 binaries. The ones that people will use the most are likely to be the assembler and linker. These are a requirement for the compiler, which I have packaged, but have yet to submit to Fedora. Hopefully I will get gcc in there over the next week — closely followed by the rest of the mspgcc toolchain.
Those who manually installed my packages will get the update through the normal Fedora update sources.
Above image derived from the Tango Desktop Project — CC-SA licence.
Update (5/2/2009): I forgot to mention that this is part of the toolchain required to build the software for the Formica robots!
I rebuilt the mspgcc packages for Fedora 10:
- msp430-binutils 2.18
- msp430-gcc 3.2.3
- msp430-libc (from CVS on 2008-08-28)
- msp430-gdb 6.8
- msp430-gdbproxy 0.7 (includes udev rule).
Once again, you’ll find the specfiles and source RPMs in the same directory.
You can install them all by running:
su -c "rpm -Uvh http://users.ecs.soton.ac.uk/rds/rpm/mspgcc/msp430-binutils-2.18-1.fc10.i386.rpm \ http://users.ecs.soton.ac.uk/rds/rpm/mspgcc/msp430-gcc-3.2.3-1.20080827cvs.fc10.i386.rpm \ http://users.ecs.soton.ac.uk/rds/rpm/mspgcc/msp430-libc-0-1.20080828cvs.fc10.noarch.rpm \ http://users.ecs.soton.ac.uk/rds/rpm/mspgcc/msp430-gdb-6.8-1.fc10.i386.rpm \ http://users.ecs.soton.ac.uk/rds/rpm/mspgcc/msp430-gdbproxy-0.7.1-1.fc10.i386.rpm"
Update (13/02/2009): msp430-binutils is now in Fedora (as I wrote in this post).
Tom has been around here for the past few days working on the new Student Robotics kit with me. We got to the point where Tom needed to use msp430-gdb so he could debug the firmware for the msp430 on the power board. I’ve previously packaged the compiler, mspgcc, but I hadn’t got around to packaging gdb.
I decided that my time would be better invested if I finished packaging msp430-gdb rather than performing another source install on someone else’s machine. Whilst I was at it, I also packaged msp430-gdbproxy and the udev rule required to get the UIF to work.
Now all the mspgcc packages are available for Fedora 9:
- msp430-binutils 2.18
- msp430-gcc 3.2.3
- msp430-libc (from CVS on 2008-08-28)
- msp430-gdb 6.8
- msp430-gdbproxy 0.7 (includes udev rule).
You’ll find the specfiles and source RPMs in the same directory.
You can install them all by running:
su -c "rpm -Uvh http://users.ecs.soton.ac.uk/rds/rpm/mspgcc/msp430-binutils-2.18-1.fc9.i386.rpm \ http://users.ecs.soton.ac.uk/rds/rpm/mspgcc/msp430-gcc-3.2.3-1.20080827cvs.fc9.i386.rpm \ http://users.ecs.soton.ac.uk/rds/rpm/mspgcc/msp430-libc-0-1.20080828cvs.fc9.noarch.rpm \ http://users.ecs.soton.ac.uk/rds/rpm/mspgcc/msp430-gdb-6.8-1.fc9.i386.rpm \ http://users.ecs.soton.ac.uk/rds/rpm/mspgcc/msp430-gdbproxy-0.7.1-1.fc9.i386.rpm"
I’m still waiting for someone to review my request to get binutils for msp430 into Fedora. :-/
2012-08-10 Edit: These packages have been in the Fedora repositories for a long time now. This neutered post is here just for kicks.
I got fed up with having to run through the build procedure for mspgcc with others. I think I must have done it four times now. So, I’ve packaged it into some RPMs that I’ve built for Fedora 9. I’m trying to get them into the Fedora repositories, but for now you can download them from here. These include the patches for the msp430f2xx, and the other patches that the mspgcc guys recommend.
I haven’t done GDB yet, but hope to over the next few days.
Update (13/12/2008): I’ve since built these RPMs for Fedora 10. Find them here.
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