??? 07/02/10 16:24 Modified: 07/02/10 16:31 Read: times |
#177070 - Let me comment on that... Responding to: ???'s previous message |
Erik,
The one bit scheme is essential in the Interrupt Vector table switching logic. I'll fully agree to that. However the mechanism to invoke the boot loader mechanism of the software does not need to be a 1-bit decision. There can be multiple ways in a given implementation to invoke the boot loader. What is important in such implementation is that each method is an OR of the others. What you want to avoid is that there be an AND function where getting into boot loader mode is a process of DoTHis AND DoNext AND AssertThat. Where one gets into trouble is if one or more of the AND conditions gets "erased" as the application update process is in progress and there is an upset. It is also important to note that at least ONE of the boot loader invoke mechanisms needs to be code that is checked inside the fixed boot loader module itself with no dependance on the application code. If you include a bootloader launch mechanism within the application code then it is essential that you also include another one as an OR in the loader code itself. There should always be at least one separate independent mechanism(s) that are used to invoke boot loader mode. There can be several if you so choose to implement them. However once in boot loader mode use, as Erik says, a single bit to show that you are in boot loader mode or not. The 8051 has the hardware bit variables that work nicely for this purpose. Use this same bit to re-direct the interrupt service routines that the boot loader may choose to use over to the application when in application mode. Two schemes to launch boot loaders are common due to the need to conceptually support "auto update modes" where some fancy host control programs will be checking for updates off on some web server and want to be able to send a command to the embedded MCU to start boot loader mode from within the application. However even within the auto launched update there is still the possibility of upset in the update process and then there needs to be a means to restart the box and manually get the update into the unit. This latter method of invoking the boot loader must be in the boot loader code as previously pointed out. This does require human interaction but still keeps from having to send the box back to the factory or service center. Michael Karas |
Topic | Author | Date |
IAP / Dual applications and interrupts | 01/01/70 00:00 | |
Bootloaders Share Interrupts Like This | 01/01/70 00:00 | |
not necessarily a good idea | 01/01/70 00:00 | |
Hogworts..... | 01/01/70 00:00 | |
interesting concept | 01/01/70 00:00 | |
an added note | 01/01/70 00:00 | |
Does the bootloader _have_ to use interrupts? | 01/01/70 00:00 | |
Forwarding of interrupts. | 01/01/70 00:00 | |
And for reliability... | 01/01/70 00:00 | |
Special Hardware Features Also Show up | 01/01/70 00:00 | |
emphasizing another factor | 01/01/70 00:00 | |
Let me comment on that... | 01/01/70 00:00 | |
Yet another consideration with boot loader.![]() | 01/01/70 00:00 |