You may remember Fetproxy, a free software alternative to msp430-gdbproxy.
Fetproxy never really got beyond the quick hack that Tom and I threw together in the 25C3 hack-centre at the end of 2008. The next stage was going to be a massive upheaval of its architecture, but I never found the time to do this. Enter Daniel Beer with his excellent MSPDebug utility. Daniel has found the time to work on this tool, and has made several releases so far. I’ve tested it with a couple of boards that I had lying around, and it appeared to work quite well.
Go and use it. Its source code is quite legible too, so you should hack on it too ;)
I’ve packaged mspdebug for Fedora, and you’ll find the package in this directory. Maybe I’ll jump through the hoops of getting it included in the repositories soon.
2010-11-04 Update: mspdebug has been in the Fedora repositories for a while now. Install it using:
pkcon install mspdebug
Jeff and I have just announced that we’ve made Formica 2 kits available for order. You can pre-order them in the newfangled xGoat webshop, and this will guarantee that the kits are shipped to you by the 22nd of February. The kits come with all the surface mount components already soldered on the PCB, so you can get to programming your robots as fast as possible. Some soldering is still required to attach the motors, battery, antennae and photodiodes.
You’ll also find the protopack in the webstore, which is a backpack (an extension board which plugs into the new hack connector on top of Formica 2) with a 1.27mm prototyping area on it. This will be useful for quickly hacking together extensions for your Formica robots.
Luckily I managed to get in at the right time and bought all the MSP430F2274 microcontrollers that we need for these chips. There’s some kind of international shortage of these at the moment. If you are in desperate need of these chips, email me and I might be able to sell some to you.
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…
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.
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’m releasing the PCB designs for the univ430 under a Creative Commons Attribution-Non-Commercial-Share Alike license.
Why non-commercial? I used a freeware version of EAGLE to design the board, which comes with the condition that designs made with it are used in non-profit applications. Any moment now I will start using gEDA — I promise. When gEDA gets to the top of my project stack again, I will migrate!
You can download the tarball containing the PCB designs here.
univ430 adapter by Robert Spanton is licensed under a Creative Commons Attribution-Non-Commercial-Share Alike 2.0 UK: England & Wales License.
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
% 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.
Tom and I have been working on some code to replace msp430-gdbproxy, which is a piece of closed source software that we regularly use to program and debug MSP430 microcontrollers. The atmosphere at 25C3 encouraged the continuation of this effort, and we can now successfully reprogram MSP430s using it. We’ll be releasing it as FOSS as soon as possible once we’ve ascertained that there are no legal issues with us doing so. I’m sure that you can understand the reasons for such caution here.
In the future, we’d like to be able to prove that we had got to this point by this date. Therefore, we’re publishing the SHA1 (160-bit) hash of the source code right now, and will later publish the code that it goes with. That hash is:
And in order to remind myself which git commit this maps to in my repository, it’s commit: 894dde86e14b824e16540908e9138ee944abafcf.
I’ve been working on some bits of software that’ll allow the firmware of an MSP430 to be updated via I2C. This will allow us to upgrade the firmware in all of the Student Robotics boards via the web. The firmware updates will be shipped out in the zip archives that our web-based IDE spits out when teams program their robots.
I got this mostly working in early September but I’ve only just got around to cleaning it up and making it usable. I’ve written a utility called “flashb” that, when configured correctly, just takes the name of the board to program and the two binaries necessary for the flashing. Here’s a demonstration screencast of it working:
In that video I’m loading new firmware into the JointIO board. I have an OSIF plugged into my laptop that is in turn connected to the JointIO board. I’ve reflashed this thing at least 50 times today without any failures, which bodes well for deployment.
“Why two binaries?” I hear you say. Each of these binaries only uses half of the MSP430’s flash. The two binaries contain the same code but one is linked to reside in the top half of flash and the other resides in the bottom half. Only one of these is executing at one particular time whilst the other can be overwritten with a later firmware version. I went for this approach for two reasons. Firstly, I’m new to writing bootloaders and so I decided to do something simple that could easily be slotted in with our existing code. Secondly, I had already written some of the code to do this for the Formica robots.
There’s still a lot of room for improvement, but I’ve almost achieved something that’s shippable. The code for the Formica robots was written so that they could gradually receive new firmware whilst still operating. Student Robotics doesn’t place this constraint on the bootloader. The firmware could stop operating and jump to a small bootloader, which would erase all flash except for itself. For now we’re not doing that. The time to consider that will be when we run into code size issues.
As with all of the Student Robotics code, the source for these things can be found in the Student Robotics subversion repository. The JointIO firmware can be grabbed by doing this:
svn co http://svn.srobo.org/boards/jointio/firmware/trunk/
Similarly, the flashb code can be accessed like so:
svn co http://svn.srobo.org/slug/utils/flashb/trunk/
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).
|Older Posts >>|
Site by Rob Gilton. © 2008 - 2019