Bootstrap Loader MSP430F149

Tobias Langenbacher said:

i have to develop an application with a bootloader.  the requirement is that the connection to the bootloader have to go over the uart interface (uart0 pins p3.4 / p3.5). so i thought i can use the internal bootloader (bsl) of the msp430. but it doesn´t work with this pins, is it right?. because the bsl using the timer-uart (pin p1.1 / p2.2).

Correct, for the reason you cited.

Tobias Langenbacher said:

is it possible to manipulate this bsl that i can use the uart interface (uart0 pins p3.4 / p3.5)?

Unfortunately, no, on the MSP430F149, the boot strap loader is implemented in ROM which is not reprogrammable.

Tobias Langenbacher said:

or, can i replace this bsl on the msp430 by an own bootloader?

You can not replace the existing boot strap loader in ROM with your own in the same location.  But you can implement a boot loader in main flash memory for this purpose.

There are some application notes for the MSP430 that may be useful for this purpose.  There is a flash monitor application note which provides a similar functionality.

The MSPs internal bootloader uses the P1/P2 pins because of their interrupt capability. Since the DCO of the 149 has a large frequency tolerance, I guess that using a hardware UART module is not reliable. The BSL has to adapt to a large tolerance in the baudrate (actually the baudrate is fixed, but the MSPs recognition of it has a large tolerance area).

After all, even if it would use a hardware uart, since you cannot change the BSL, you cannot change its behaviour. So either it works for you (then it is unimportant whether it uses an UART or software bit-banging) or not (then it wouldn't help even if it woudl use a hardware UART).

What you can do is to implement your own, hardware UART based BSL (requires a crystal quartz for a stable operation, or a calibration of the DCO) and connect the port pins with the ones used by the BSL. Since all pins are high-impedance inputs at startup, they won't disturb each other. So you only need one connector that is either accessed by the internal BSL (provided the input sequence is done properly) or by your application BSL. Just don't use P1.1/P2.2 for something else.

When writing your own BSL, keep in mind that if the loading process is interrupted, you might end up with a nonworking system, and only the internal BSL or a JTAG connection will revive the device. You'll might want to go for a double-buffered failsafe BSL solution. This has been discussed in some other threads recently.

hi,

i have a further question. is it right that the minimum baudrate of the uart-interface of the internal bootstrap loader is 9600 baud?

i´m thinking about to connect the uart-pins with the timer-pins. but i have a special modul on my hardware which communicates with 1200 baud. if the minimum baudrate of the internal bsl is 9600, i can´t use the bsl for my purpose. in this case i have to write my own bootloader.

This is no 'miniumum baudrate'. It operates at 9600bd. Period. Some newer versions of the BSL in newer chips allow switching to 38400Bd later, but there is no 'auto baudrate detection' or such.

Also, you cannot replace the bootloader. You can write your own application that modifies the running system. Anyway, the purpose of the BSL is that it is always there, not erased by the mass erase, not affected by any buggy code, power failure during reporgramming or such. There are some few MSPs where the bootloader resides in a protected flash area instead of rom and can be replaced. Namely the 'A' series of the 54xx MSPs.

When you write your own code for downloading new firmware versions, you always risk to leave the device in an inoperable state where you can only revive it by JTAG (in case you didn't burn the JTAG fuse), using the standard bootloader through the default pins (if you have a connector for doing so) or by replacing the processor (Argh!).

I'm currently writing an updater code that will look in a spare area of the flash (the 54xx have enough) for an image of the new application software and copies it over. How the image is created depends on the (currently laoded) application software. It will never leave the device in an unstable state. The drawback is the required space for double-buffering the data (there is plenty, so I don't care) and an additional latency for entering ISRs, since the failsafe operation requires double-buffering the interrupt vector table (it must not be erased ever, along with the updater code). And it will block the flash area from 0x0fc00 to 0x0ffff. It's almost working.

If you're concerned about the two BSL pins eventually required for something else, I recommend switching to the 54xxA processors. Faster (16MHz or even 25), more I/O pins (up to 11 ports!), more UARTs (up to 4* UART and 4* I2C or up to 8 SPI), a clock system that runs without a crystal stable enough for a 115.200Bd connection and much more. And for the same price as the 149. And it runs well at amximum speed from 2.2V (no need for 3.6V anymore if you need the 8MHz). We're moving from the 1611 to the 5419 too. After all, the 1611 (and even more the 149) is quite an old product and considered outdated by many. I wouldn't use it for a new design.