Some photos of the Gumsense:
Bottom of the Gumsense:
Top of the Gumsense:
The Gumsense with Gumstix and wifi card:
The Gumsense with Gumstix:
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).
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).
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.
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:
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.
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.
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:
- The thing programs so unbelievably slowly. (Seriously slowly: it reports 183 bits/second)
- The debugger uses near 100% of my CPU whilst programming. This is apparently due to msp430-gdbproxy busy waiting.
- 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:
- Changing the functionality of the software according to the day of the week or time of the day. This would remove the deterministic nature of the debugger, thus making the whole experience much more exciting for the engineer.
- The busy waiting. The software may be continuously monitoring the time in a tight loop until it changes.
I think the latter is most likely. The msp430 debugging software comes with three binary blobs:
- msp430-gdbproxy, a program to get around having to release any “top secret” information under the GPL.
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’.
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.
- Built a gumstix fs with i2c-core, i2c-pxa and i2c-dev modules.
- Connected a PCF8574 to the gumstix I2C bus. Used the pcf8574 kernel driver to use it. That was particularly good, since it presents a sysfs interface, which means that the pins can be read/written from the shell.
- Moved to using the i2c-dev module so that I could access the bus from userspace. Drove the pcf8574 from that using write().
- Attempted to use i2c_smbus_write_byte() to write to the pcf8574, but had problems linking. Turned out that I hadn’t read the kernel documentation file properly. The problem was that I was #including
when I should have been using i2c-dev.h from the lm-sensors project. The header file in the kernel is only for stuff that’s within the kernel.
- Written some I2C code on the MSP430, but yet to connect it to the gumstix. Doing that now!
|<< Newer Posts||Older Posts >>|
Site by Rob Gilton. © 2008 - 2019