Grant:
You may want to search the boot loader subject here on 8052.com in threads that include my name. In one you can find actual boot loader code that I posted a few years ago. I would actually discourage launching and calling the boot loader code from the actual application because this method does not adequately cover the needs for recovery in the event of upset or power glitch whilst an update is in process. As a minimum, if you do invoke from the application, you have to support a 2nd access method in case of upset. It's better to simply have a single method of access that works via a robust wakeup sequence that invokes just after device power up. The wake-up method I like is to receive some type of special handshake over the I/O interface that supports the download of code be that a UART port, I2C port, USB port, CAN port or whatever. This saves special switches, jumpers, connector pin straps or test probes.

As far as the interrupt vector table goes it is best to put your loader @ address zero and then have it own the CPU hardware supported interrupt vector table. If you use Keil tools the linker lets you put the "application" interrupt vector table at an offsetted address at say 0x1000 or 0x1800. The loader interrupt vector table simply uses LJMPs to re-vector any interrupts to the application's offsetted table. If the loader is written to use a few interrupts then these can have a test of a loader variable to support dynamic routing to the loader if the loader is active or to the application if the loader is idle.

I feel that it is very possible to build and test a robust loader that is validated to a degree that you can feel assured that it likely to not change during a product life cycle. If it does have to change the best way to do that, in my opinion, is to use a JTAG, hardware SPI, or socketed CPU method to update the loader. The boot loader itself should NEVER support the possibility to erase itself or the CPU hardware interrupt vector table. If you do not follow this rule you leave open a hole where a possible upset will render the product as so much crispy toast till it is returned back to the factory or service bureau.

I also am a firm believer in building the product code in a manner where the boot loader and the application part of the program are compiled and linked in a single build process. This makes it very easy to support and maintain factory programming images without extra steps to do double image programming. Many of the boot loaders you will see in application notes, factory web sites, and MCU forum web sites are built as two separate programs and then post merged. I do not like this approach and promote the alternate scheme mentioned above. One consideration to contend with when making a boot loader that will be used in conjunction with an application that is written in a high level language such as C is that it is rather complicated to make a boot loader that also uses the same tool set and language as the application and support the single build process. This leads to the fact that every boot loader I have ever implemented is written in assembler language. This leaves one in total control of the loader environment instead of fighting resource sharing with the application compiler.

Check out the code here:

Michael Karas