偶看新闻家电可以怎样分类:程序部署
来源：百度文库 编辑：偶看新闻 时间：2024/04/30 00:30:13
You need some way for the device to determine when it is reset which of two possible locations it should start executing from. But generally a bare-metal device has only a single starting location it runs from when it's reset (some controllers can select from two or maybe more entry points based on the logic level of some pins on the device).
We had a similar requirement, and worked out the following scheme:
- a small bootloader program is required - it's built and linked to be the program that gains control of the CPU at reset
- the main program image is actually built twice - once for each possible location. Note: the two possible loading locations are fixed and known by the bootloader.
- there's a small data structure at the start of the program image that contains several bits of information important to the bootloader. Among them are the entry point address of the program and a checksum of the program image
The bootloader examines the fixed, well-known locations to checksum the two possible images.
- if it finds no valid images, it simply loops (the watchdog will reset the device, but that doesn't really matter - it's a brick until a valid main program is loaded)
- if it finds only one valid image, that's the entry point that it jumps to.
- if it finds both images are valid it uses other information in the data structure to determine which one to give control to (version information, last known good, whatever your policy might be).
The key to this is that the bootloader must be simple and stupid. It's not easily upgradeable, so you want it to be stupid enough that it can't have bugs.
Now the device can be upgraded while it's running by flashing the image to the non-running location (the Cortex-M3 device we have allows this - if the LPC1758 doesn't allow this, then you have to have something that runs from RAM perform the flash update). Reset, and the bootloader picks up the newly flashed image.
The system requires a little up-front work to get the bootloader running and rock-solid, but once it's working updates are 100% reliable (if the new flash doesn't complete, the old image is the only one that checksums, so it'll run at next reset - no bricks). The main disadvantage - and it's a big one - is that you essentially lose half your flash address space for the main program since the flash has to be able to hold two compete images.