Overview of last week of stuff:
- I started the week with little understanding of the Linux ARM boot process, Steve’s NSLU2 and the need to get a working Linux install on it. Tom and I spent a considerable amount of time working on getting it to work. Almost all of the problem was because for some (yet to be fully determined) reason, the kernel is passed an incorrect machine code by redboot. Whether this is because someone’s flashed the slug in the past, I don’t know. I ended the week with an understanding of the ARM MMU, linux ARM boot process and a working booting slug with functioning network adapter :-)
- I created my first RPM. :-D I spent christmas eve reading various documentation on the subject, and so have packaged my yum plugin. I’ve stuck the spec file, srpm and rpm up for public access.
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.
- libHIL.so
- 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’.
I went to (one of) Sam’s 21st birthday do(s) yesterday. It was fancy dress, a fact that I hadn’t incorporated into my mind until thursday. Kim and Naomi gave me some tinsel to wear. Then Ben suggested that I wore christmas tree lights. “Here, borrow these”. “But they’re mains powered”, I said. It was five to five at this time and so I ran to the (fairly unnecessarily, because Woolworths was open till sometime after 5) shops and bought some battery powered christmas tree lights.
I got home. Switched on the lights. They turned on, but didn’t flash, which was a little disappointing. I showed them to Jeff. Jeff and I decided that they needed to flash. I decided that it would be simple to use one of the DIP package MSP430s that I’ve got to control their flashing. I could probably munge the code from my project onto this other type of MSP430 without much hassle, which would mean that I could “schedule” a flash every second.
Unfortunately, I had trouble connecting the MSP430F2002 that I had to my PC. For some reason I couldn’t get msp430-gdbproxy to recognize it. So, that idea was scrapped.
So I built a very simple flasher, based on three NAND gates, 3 caps and 3 resistors. End result: flashing lights, and in time for the partying too.
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
- 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!
Site by Rob Gilton. © 2008 - 2019