I phoned the Texas Instruments European Product Information Centre (that’s what I think EPIC stands for). I told them that I couldn’t find the specification of the MSP430 debugging interface on their website. I asked them where I could find it. The woman I spoke to passed my query onto the EPIC MSP430 guy, who, after trying to sell me a USB programming/debugging tool (which would not have solved my problem), understood what my question was. His answer can be summarised quite succinctly: “no, TI will not give you any information about the MSP430 debugging interface”.
Great.
So reverse engineering it is. I think (and hope) this shouldn’t be too challenging. I think running strace on the available binary blob will provide lots of interesting and useful information. I’ll look into the legality of reverse engineering things and making the findings public first…
Why do I want to go to such lengths? At the moment, the binary blob debugger/programmer loads data into the MSP430 at a blinding speed of ~100 bits per second. Yes, you read that correctly. I think that the largest MSP430 flash that’s available is 60Kb. That means it would take around 80 minutes to program the device if one used all of the flash. Of course, that’s if the debugger doesn’t randomly “lose control” of the MSP430 in the process! Ah yes, and during that process the machine it’s running on gets hammered because the software uses almost all CPU.
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.
Today was MSP430 timer day. I spent an hour or two programming the MSP430. I first got timer B running off the watch crystal. Worked fine.
Then it became apparent that this would only allow the MSP430 to be asleep for 8 seconds at a time. If I want to be really low power this wasn’t a good thing. So I thought for a moment and then realised that, using the timer peripheral’s insane output module, I could get Timer A to generate a 0.5Hz (or lower) clock that I could then use to clock Timer B. The net result of this is that the MSP430 can stay asleep for about 97 days without waking up to increment the timestamp :-) I got this setup working, so now it can sleep for extraordinary amounts of time!
Thought about I2C for a short period as well, and came to the following conclusions:
- The gumstix will be the bus master when talking to the gumsense. This way, the MSP430’s lack of known-frequency instruction clock isn’t a problem because the gumstix will be doing all the clocking.
- The MSP430 may need to communicate with some I2C devices to take samples. This would mean that the MSP430 would have to switch to being the bus master whilst the gumstix is asleep. However, this could prove problematic for the “take a sample” now command that the gumstix can issue to the gumsense. Perhaps the solution is to have an extra IO line between the MSP430 and gumstix that states when it’s OK for the gumstix to use the I2C. That way, the “take a sample” now command would actually be a “start taking a sample now” and then there would be another command for reading the results of that sample.
I’ll work on the I2C code next I think. I’ll need to have a bus master for it to communicate with, so I’ll set up the gumstix to communicate with it. In order to make sure that I know what I’m doing when it comes to I2C and linux I’ll plug in a PCF8574 IO expander onto the bus first.
Things that have happened since yesterday:
- I powered up the MSP430 with a watch crystal attached to it. Sticking a scope on the crystal showed that it was oscillating.
- Built a small board for adapting between the TI parallel port JTAG tool (not quite sure what it’s called – possibly a Parallel port FET tool?) and a breadboard
- Bought a power supply.
- Discovered that there’s some problem with the gdbproxy tool that comes in the cdk4msp rpms, which means that it works with only some MSP430s – it worked with the MSP430 development board that I’ve got (MSP430F436), but not the MSP430F169 that I’m using. The binaries from the mspgcc project worked correctly.
- Wrote a (very) small test program. Probably could be considered as the “hello world” of microcontroller programmers – toggled an output pin’s status continuously.
- Danced.
Haven’t written much over the last few weeks (been busy with train usage and other things). Last wednesday I made a pcb for adapting between a 64 pin LQFP and DIP. On sunday I destroyed it by being incompetent. Today I remade it (in about 1 hour 15 minutes) and soldered an MSP430F169 onto it with no problems. Here’s the result:
Next stage: connect it up. That’ll happen tomorrow.
| << Newer Posts | Older Posts >> |
Site by Rob Gilton. © 2008 - 2019