After a surprisingly straightforward and pleasing construction and debugging session, the Gumstix is now on the Gumsense mark 2 :-) The Gumstix powers up fine and communicates with the MSP430 successfully.
So far I’ve found two mistakes and two slight annoyance on the board:
- I’d missed a ground connection to the output capacitor and diode of the Gumstix switchmode supply. Easily fixed by a short piece of thin blue wire soldered between the diode and a nearby grounded via.
- I’d done something weird in the Eagle schematic editor. Eagle has an annoying feature that allows two unconnected wires on the schematic to become part of the same net. That’s not so bad – normally I promote using netnames to connect different parts together. The problem is that in this case, only one of those tracks is labelled. So, I ended up with the MSP430 supply being connected straight to the voltage regulator rather than going through a schottky diode first. This meant that the button cell initially didn’t do anything. Fixing this required the cutting of 4 tracks and the addition of 2 very short pieces of blue wire.
- The first slight annoyance is that I’ve put a dual diode (BAT54C) too close to a capacitor. It all fits, it’s just a little tight.
- I neglected to put a decoupling/resevoir capacitor on the MSP430 internal reference output pin. The datasheet recommends this. I’d written it down in my list of things to do before the board went off to made too. For some reason, I just completely ignored it.
So, the blue wire count is now three. Analogue section next.
I just downloaded the vala source. When I went to untar it I found that it was exactly two months ago (to within the hour) that I downloaded it:
[rob@prefect downloads]$ ls -lu vala-0.0.*.bz2 -rw-r--r-- 1 rob rob 632114 Jan 28 22:58 vala-0.0.5.tar.bz2 -rw-r--r-- 1 rob rob 691498 Mar 28 22:22 vala-0.0.8.tar.bz2 [rob@prefect downloads]$
Perhaps i’ll download the source again in two months time.
I’m currently:
- Running linux on a gumstix
- Running gdbserver on that gumstix.
- Debugging a program on the gumstix using gdb on my laptop (which is running linux)
- Remotely debugging the msp430 that’s connected to the gumstix I2C bus
Oh, but wait, msp430-gdbproxy and friends aren’t free. Arrrrgh. I can feel my soul dissolving.
If I ignore the dissolving for now, it’s all amazing. So much debugging.
Particularly uninteresting for anyone but me. I need to log this for my project, you see.
Just created a patch for optionally building the python shared library.
Getting python onto the gumstix requires some work. By selecting python, the file system goes from 4 Mb (4131692 bytes to be exact) to 11Mb (11495444 bytes). That’s OK for the 16Mb gumstix boxes, but seems a little wasteful. After close inspection with the help of baobab, I find that a lot of it’s taken up by the python libraries:
args = re.sub( r"/usr/lib/libpng12.so", "", args )
s = subprocess.Popen( "/home/rob/ecssr/proj-svn/slug/init-br/build_armeb/staging_dir/bin/armeb-linux-uclibc-g++-orig " + args ,
stdout=subprocess.PIPE,
shell = True )
[rob@prefect bin]$ pkg-config
PPPPPPPPPPPPPPPPPPPPPPIIIIIIIIIIIIIIIIIIIEEEEEEEEEEEEEEEEES
[rob@prefect bin]$
Just found an interesting article on Circuit Cellar about a guy who linked an XBee to one of those Microchip ethernet chips. Nice.
Since a couple of days ago, when I wrote about the kernel patches that I generated to get the UIF working, I have had a response on the mspgcc-users mailing list. The problem has already been fixed in 2.6.20, so my patches aren’t required.
The reason that I previously thought that the fix hadn’t found its way into the kernel was that it had been fixed in a different, and better way – thus the code changes I was looking for weren’t there. The fix that’s in the kernel is a much more sane approach than the method I copied off the mspgcc-users mailing list. So I’m now running 2.6.20, and the UIF (and presumably the EZ430 – I don’t have that here at the moment) works fine.
One thing that may slightly irritate people when first installing the UIF is that you need to add a rule to udev. This rule is: (edit: you probably don’t want to use the rule below now – see further below)
SUBSYSTEM=="usb_device" ACTION=="add" SYSFS{product}=="MSP-FET430UIF JTAG Tool" \
SYSFS{bNumConfigurations}=="2" \
SYSFS{bConfigurationValue}=="1" \
RUN+="/bin/sh -c 'echo 2 > /sys%p/device/bConfigurationValue'"
And then it works (remember to reload udev rules with “udevcontrol reload_rules“). I’m not 100% sure what it does, but from looking at the rule and driver code, it would seem that the TI USB->UART chip in the debugger can has more than one configuration, and that affects what firmware gets loaded into the USB->UART chip. The udev rule associates the device description string (“MSP-FET430UIF JTAG Tool”) with the correct config value (2).
Edit: Things have changed in udev since I wrote this post. The rule I now use is:
SUBSYSTEM=="usb" ACTION=="add" ATTR{product}=="MSP-FET430UIF JTAG Tool" \
ATTR{bNumConfigurations}=="2" \
RUN+="/bin/sh -c 'echo 2 > /sys%p/bConfigurationValue'"
Edit (27/03/2008): Things have changed even more. Now I use this rule (with udev 118):
SUBSYSTEM=="usb", ACTION=="add", ATTR{product}=="MSP-FET430UIF JTAG Tool", \
ATTR{bNumConfigurations}=="2", ATTR{bConfigurationValue}="2"
I just finished sorting out using the toolchain for the PWM board. Problem with the toolchain that I had was that the binutils I had installed (2.16) doesn’t support the MSP430F2013. After some searching around I found the patch I needed to apply to binutils in mspgcc CVS – and then managed to find a post about it on the mailing list.
Once the toolchain was built I ran a simple program that toggled the output pins continuously:
#include <msp430x20x3.h>
static int i = 0;
int main( void )
{
WDTCTL = WDTHOLD | WDTPW;
P1SEL = 0;
P1DIR = 0xFF;
while(1)
{
P1OUT ^= 0xFF;
}
}
The program ran correctly, and the level translation between the MSP430 and the servo outputs worked nicely. Good. Only motor controller to go now, and then we’ll be living in a softwarey world. Ah yes – the TI USB UIF interface seems to be working perfectly in spy-bi-wire mode :-)
| Older Posts >> |
Site by Rob Gilton. © 2008 - 2019