More tea please.

Gumsense Photos

Some photos of the Gumsense:

Bottom of the Gumsense:Bottom of the Gumsense

Top of the Gumsense:Top of the Gumsense

The Gumsense with Gumstix and wifi card:Gumsense with Gumstix and wifi card

The Gumsense with Gumstix:Gumsense with Gumstix

Posted at 10:31 pm on Tuesday 10th April 2007

Buildroot for Gumsense

I’ve git-svn’d the Gumstix buildroot, and put it in my ECS filestore. It’s accessible to the world by http:

git clone http://www.ecs.soton.ac.uk/~rds204/gumsense/.git

I’ve moved it into git because it’s allowing me to easily share my patches to buildroot with others (i.e. the people who want to use the gumsense in the future) and it also allows me to track my changes locally on my laptop without being connected to the net.

I did try creating it in the webserver space for my project on ECS Forge, but I couldn’t get git to push to it (without running it through sshfs, which slowed it down a lot).

Posted at 5:43 pm on Tuesday 10th April 2007

Dancing around my first kernel driver.

Four days ago I started working on getting the Gumsense to turn the Gumstix supply rail off when Linux has shutdown. I started writing a blog post containing all the things that I had examined. I’m still writing that post; it’s getting pretty long, and will arrive soon.

During that process, I realised that I was going to have to write a kernel driver for the Gumsense. I’ve now written that driver. It’s the first kernel driver I’ve written. It’s a relatively simple driver, but it represents a big increase in my knowledge of Linux internals, and I’m pretty pleased with it. It’s an I2C chip driver and hooks into the Gumstix platform code (which I also had to slightly modify so that I could hook into it).

Posted at 5:12 pm on Monday 9th April 2007

And then there were three

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:

  1. 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.
  2. 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.
  3. 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.
  4. 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.

Posted at 6:55 pm on Friday 30th March 2007
One Comment

Python shared library configure option

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.

Posted at 4:16 pm on Monday 26th March 2007

Squishing Python

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:

Disk usage with python.


Posted at 2:32 am on Monday 26th March 2007

Hirose Connector

Attempting to source Hirose connector.

Read datasheet from Hirose website.  The part number of the connector I want for a gumstix daughterboard is DF12#3.0-60DP-0.5V.  The ‘#’ needs either deleting or replacing with a “B”, a “D” or an “E”.  These make it either “fitting” or “bossed”.

I had no idea what “fitting” or “bossed” meant in the context of this connector, and so rang Hirose.  Apparently:

Fitting: Short for “metal fitting”. Means that the connector has metal brackets on the sides for soldering to the PCB.

Bossed: The connector has a plastic peg for interfacing with the PCB.  This makes sense, since “bossed” apparently has something to do with studs.

I asked about where I could get the connector in the UK – in a relatively small quantity.  They would have shipped me a sample (presumably after monetary transaction) had they got it in stock.  They hadn’t.  They’ll ring me back later with some details of where I can get them.

Posted at 11:47 am on Tuesday 12th December 2006

MSP430 Backup Battery

Since my MSP430 is being my RTC, it probably needs a reliable source of power.

I am considering connecting it to a button cell battery and the external power supply through diodes. However, this means that the supply rail would change voltage when the external power failed. I wasn’t sure how this would affect the MSP430, so I did an experiment.

I constructed a circuit that allowed me to switch the applyed voltage rail. I started the code running on the MSP430 and set the gumstix to continuously read the time register over I2C. I switched the voltage rail from 3.3V to 2.7V. The MSP430 reset. I realised that this could be because my testing arrangement isn’t exactly perfect… there is almost certainly a period during the switch where there’s no applyed voltage…

So I stuck a 100uF cap on the MSP430 rail. I couldn’t get it to reset after that.  I tried switching between 3.3V and 1.8V.  Worked fine.  Could only read the time when the supply voltage was 3.3V though, which isn’t really a problem.
A further experiment is required. One where the two rails are connected to the MSP430 through diodes, as they will be (if this experiment is successful) on the gumsense.

Posted at 4:54 am on Saturday 9th December 2006

More I2C Joy

I now have an MSP430 which communicates with the gumstix successfully over I2C.

I think I’ll aim for the device to be SMBus compliant, since it seems sensible. The CRC part definitely seems sensible.
Spent many hours today trying to tease out a bug where reading an SMBus register from the device worked the first time that the read happened after the MSP430 had been reset, but not after. The register position counter never got reset because the code that I’ve got in the “own address” I2C interrupt handler wasn’t getting called (attempting toggling a port pin from it showed that it wasn’t).
Read more of the MSP430x1xx family user guide, to find that the value of the I2CIV register (the register one uses to determine what type of I2C interrupt has occurred) is reset upon any form of access to the register. Looked at disassembly listing. For some reason gcc was accessing the register twice in the ISR. So I modified the ISR to store the value of the I2CIV upon entry and use that copy. Everything started working.

So, I can now write the current timestamp into the MSP430 via I2C. I can then later read the time out of it, and see that it has changed :-D

I’m very suspicious that gcc was creating code that accessed I2CIV twice, especially after reading the header file (usart.h) to find that it is declared volatile. Will get on the mailing list later.

At the moment, the debugging procedure is relatively painful (yet less painful than the ICD2 experience (TM)) because:

  1. The thing programs so unbelievably slowly. (Seriously slowly: it reports 183 bits/second)
  2. The debugger uses near 100% of my CPU whilst programming. This is apparently due to msp430-gdbproxy busy waiting.
  3. I can generate kernel panics on the gumstix fairly easily by setting up a breakpoint in the MSP430’s I2C interrupt routines.

Numbers 1 and 2 are, in my opinion, both as a result of the closed source part of the system. msp430-gdbproxy is calling gettimeofday() (via a shared library). Something which appears to be completely insane. Why would a microcontroller debugger need to know what time it is? Oh right. Yes. That would be because it’s been written by someone who’s well on their way to being classified as completely insane. I can think of a couple of reasons why it could be doing this:

I think the latter is most likely. The msp430 debugging software comes with three binary blobs:

  1. msp430-gdbproxy, a program to get around having to release any “top secret” information under the GPL.
  2. libHIL.so
  3. libMSP430.so

The two shared object files are the interesting ones. They contain the gubbins that performs the hardware interfacing. Perhaps, one day, I’ll consider reverse engineering what they’re doing so that I don’t have to suffer any more.

I’ve decided that ‘being an engineer’ also means ‘becoming more and more annoyed at proprietary things’.

Posted at 3:22 am on Wednesday 6th December 2006

On mystical linking errors, CPU bugs and userspace I2C

Excellent, I have xgoat back! There was a lack of re-registration, and so it went slightly out of control…

Now I can write about the last week of project work:

Saturday 25th Nov

Spent first part of the day building my own msp430 toolchain, since the version that cdk4msp presents has a bug that got me.
I started checking that the scheduler code I’d written worked. There was a bug in it that resulted in a job being executed more often than it should have been. My scheduled jobs simply toggle pins at regular intervals at the moment, and the pin of a 1 second job that I was running appeared to be running when it should(actually every 2 seconds, but I’ll come to that in a moment). However, every 5 seconds or so, it would look like it got run twice because the pin would flick twice in quick sucession.

I stepped through the program with gdb. I found that the function responsible for adding a job to the table was receiving odd arguments. The arguments going in were ok, but when it reached the function, they just appeared to be random numbers (there was some regularity in them, but that didn’t really mean anything).

I checked that this wasn’t an artefact of the debugger, by sending the function arguments to the output pins of the msp430. However, I didn’t have any method of checking that the msp430 was actually getting programmed correctly.

I spent a while reading a disassembled listing of my code. I couldn’t find any problems.

I began to worry more that it was my programmer.

Then I thought “Wait. Microchip publish huge erratas on bits of their microcontrollers that don’t work. I bet TI do too” . Searched the mspgcc-users mailing list. Found a link to the errata. Read the relevant msp430 device page on the ti website, and found that there were indeed several problems with the MSP430F169.
The “CPU4” bug affects only push instructions that use the literal generator to push 4 or 8. Workaround: don’t use the literal generator for these numbers.

The errata also said that this was worked around in the TI assembler. I thought, why doesn’t binutils do it!? Looked at what version of binutils I was using; 2.14. Latest is 2.17. Downloaded 2.17. Installed. Rebuilt gcc. Tried compiling gdb. gdb compilation failed. Moved down to binutils 2.16. gcc and gdb built. Rebuilt msp430 code. Bug no longer there.

I wouldn’t have found this problem had I not got a job with 4 second period in my test code. Ahh.

All of the above took much time, and I was v. late to bed.

Sunday 26th November

Today I tackled the problems that I was having with the job running at odd intervals.  Wasn’t too long to fix this one.  The timer interrupt happens a clock cycle after the compare register has reached its target, which meant that a 1 second job was taking 2 seconds and a 2 second job was taking 3 seconds, because the timer clock was 1Hz.

I upped the timer clock to 2Hz and altered the compare value so that it would be reached a clock cycle before the wake up.  Worked fine.

More recently

Posted at 8:11 pm on Friday 1st December 2006

Site by Rob Gilton. © 2008 - 2019