Wednesday, October 28, 2009

MSP430 Info Flash

by Travis Goodspeed <travis at radiantmachines.com>

The following is a description of the MSP430F2xx Info Flash, as well as my ugly--yet reliable--hack for initializing the DCO of MSP430F2xx chips after my use of the Serial Bootstrap Loader (BSL) has destroyed the contents of that flash on the GoodFET. This ought to be of use to anyone who wishes to make an MSP430 design without a crystal, as well as for anyone who has accidentally erased info flash.

The mask-ROM bootstrap loader, BSL, of the MSP430 chips is damned handy, despite some security concerns. It allows you to very quickly program a chip by the same USB/serial converter that you use to interface it with a computer, without any of the hassles of having to flash a bootloader onto the chip. In this article, I describe the way in which the MSP430F2xx flash can be accidentally corrupted by the bootloader, as well as a method for repairing that damage by backing up the info flash while the password is left as the default.

The MSP430F2xx family has another dandy feature, that clock configuration values need not be calibrated to an external clock, such as the 32KHz crystal of the older GoodFET models. Instead, configuration data is calculated at the factory and placed into info1 flash, a region of 256 bytes at 0x1000. Using this, code that would be rather complicated can become trivially simple.

The code that configures the clock is configured on the GoodFET with MSP430F1xx chips is too complicated for me to include here. By contrast, on the MSP430F2xx chips, it becomes just
void msp430_init_dco() {
BCSCTL1 = CALBC1_16MHZ;
DCOCTL = CALDCO_16MHZ;
}


The security model of the BSL is a bit confusing. Upon connecting, you are required to present a password before reading, writing, or doing anything else that might affect the security of the device. You are, however, allowed to erase all of flash memory--including the info flash--to 0xFFFF. As this is traditionally the first command that you send upon connecting to a device, you will wipe all of the configuration data of a chip in programming it. Finding this problem is hellish, because the exact same code will work if programmed by JTAG and you quite often have not got JTAG handly if you intend to program everything by the BSL.

As part of the GoodFET project, I've forked TinyOS's tos-bsl client to add support for the MSP430F2xx. I've also implemented a "--dumpinfo" command for dumping info flash to a TI Text file. This file can be reflashed after the chip has been erased to restore its factory settings.

petite%  goodfet.bsl --dumpinfo          
MSP430 Bootstrap Loader Version: 1.39-goodfet-8
Use -h for help
Transmit default password ...
@1000
aa 55 ff 3f cd ab aa 55 34 12 ff ff aa 55
ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff b4 85 fe 16
ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff 08 10 00 80 01 00
62 7f b2 0b e8 0d 98 7f 01 07 56 08 fe 08
ff ff ff ff ff ff ff ff 01 08 7f 8f 85 8e
74 8d c2 86
q

petite%


This output is in the TI Text format, which is easily converted to Intel-hex, but is a hell of a lot easier to write. Piping it into a file allows me to restore the contents of flash after erasure, and also to extract the configuration values which are used on this chip. Because the chips are similar physically, it turns out that the calibration values for one are often sufficient to program another. So by observing the model number (in big endian at 0x0FF0), I can guess in the absence of calibration values.


//! Initialize the MSP430 clock.
void msp430_init_dco() {
if(CALBC1_16MHZ!=0xFF){
//Clear DCL for BCL12
DCOCTL = 0x00;
//Info is intact, use it.
BCSCTL1 = CALBC1_16MHZ;
DCOCTL = CALDCO_16MHZ;
}else{
//Info is missing, guess at a good value.
BCSCTL1 = 0x8f; //CALBC1_16MHZ at 0x10f9
DCOCTL = 0x7f; //CALDCO_16MHZ at 0x10f8
}
}


When I find the time, I intend to test a large quantity MSP430 chips to determine the exact tolerances of manufacturing, the variances of CALBC1_16MHZ and CALDCO_16MHZ, and the probability that a given unit will so drastically differ from these values that serial communications become impossible. For now, I've found that the hardwired values above seem to work for all recently acquired MSP430F2274, MSP430F2254, and MSP430F2618 microcontrollers when using the hardware UART at 115,200 bits per second. Further, the GoodFET firmware does not require a crystal when running on these chips.

4 comments:

xorduna said...

Hi!

That's right, I would like to know the guy who designed the bsl security of the msp430xf2!

I've had a lot of issues regarding the msp430 clock calibrations, they differ a little bit between chips. With the example code that TI provides in its website you can re-callibrate and write the clock configurations. But all the ADC calib data is erased for life (TI told me that it is impossible to recover).

So at the end I'm gessing you destroy your calibrations each time because you don't know the old password ...

Keep reading you!

andre said...

Hi Travis,
on quick comment. When initializing the DCO on 2xx devices, especially to higher speeds such as 16MHz, it is extremly important to first clear DCOCTL. Otherwise, high-frequency spikes could occur temporarily which could crash your CPU and/or freeze your DCO (in case of devices with the BCL12 bug). Please always use (and promote) the following flow of first clearing the DCOx and MODx bits before modifying the RSELx bits. Also see 2xx Family User's Guide (SLAU144E, page 646).

void msp430_init_dco()
{
DCOCTL = 0x00; /* Safe Flow */
BCSCTL1 = CALBC1_16MHZ;
DCOCTL = CALDCO_16MHZ;
}

And one more thing. While the check for the validity of the calibration constants is a good practice, I would only check BCSCTL1, and not check DCOCTL against 0xFF, since -although unlikely- 0xFF could be a valid value for that register.

Thanks, Andreas@TI

Travis Goodspeed said...

Thanks Andre,

I've updated the code examples as you suggest, as well as the GoodFET's clock code.

--Travis

Travis Goodspeed said...

For devices with serial UART connections, I now use a variant of this technique with a short list of DCO settings. By iterating through the list until a connection is made, then backing up one, I can have my UART client reset the device until the clock works, then return to that working setting on the next reset.

Be sure to make your iterator not be initialized by the C compiler.

--Travis