|SHDesigns: Embedded Systems Design, Consulting and Developer Resources||Page hits:|
Testing has shown that implementing a 100% failsafe download manager on a Rabbit board is near to impossible. This is due to some limitations in the designs of the Z-World boards and modules.
These limitations are:
1. The Flash chips are not reset when the Rabbit board is reset.
If the board is reset during Flash write, the Flash is in "write mode". Reset does not clear this mode as the reset line was never tied to the reset line on the Flash chip. This causes the rabbit to read garbage, usually 0xff and 0x7f. This causes RST 38's to be executed. The resulting stack writes cause additional writes to the flash. It can trash or erase the flash chip.
2. There is no power fail interrupt.
The code can not anticipate a power loss and exit flash write mode. This makes problem #1 significant for brown-out resets.
3. The flash is not protected.
The flash does not provide a protected "boot block"; nor does it allow write-protected sectors (some chips do, but ZW does not support it in their code.) Also, ZW does not support a boot block flash. A boot-block protected flash would allow a boot loader to always be resident in flash and impossible for an errant write to corrupt it.
4. Reserved areas in Flash are difficult to implement.
The ZW compiler supports this but it is poorly documented.
Testing has shown that when the board is reset, the flash may be corrupted. If sector 0 is overwritten, the situation is never recoverable without using the ZW programming cable. Usually the current block is corrupted and is usually recoverable (assuming there is recovery code in flash.). Recovery is usually 95% or better for a power loss or reset. The failure is usually due to the Flash sector 0 being corrupred while it is reset while writing.
Ok, so foolproof recovery is impossible without major hardware and software changes.
The SHDesigns Resident DLM overcomes this problem by running programs in RAM. The main flash is treated as a file system with a permanent boot loader.
The SHDesigns Ethernet an Serial DLMs try to be as foolproof as possible.
For the ZW versions, the RAM loader is not in a fixed location of Flash. This is very difficult to implement with the DC compiler. The RAM loader is small (usually 22k). It is copied to the start of flash when the download starts. This is a small write in time so the chance of an reset during this time is small (usually a less than a second).
Then the main code is downloaded, excluding the area of the RAM loader. Power loss during this time is usually recoverable. Once the download is complete, the RAM loader image in flash is overwritten with the user code.
There is a small window when the RAM loader is rewritten that may not be recoverable. It is usually a fraction of a second. Since there is no boot block, sector 0 must me rewritten to switch between the RAM loader and user code. This is not avoidable. This time varies depending on the Flash type but is usually only a fraction of a second.
The Softools versions of the Ethernet and Serial DLM's provide better recovery. This is because it is easy to locate the RAM loader at a fixed address. This makes the only point of failure the time when sector 0 is rewritten (usually only a fraction of a second.).
Testing has verified that sector 0 can get trashed if the board is reset during flash programming. This is due to the Flash chip not automatically resetting when the CPU is reset. The chance of corruption depends on the Flash type. Some require a specific sequence to initiate a write. Others will erase a sector on any write. The newer 3000 and 2000 chips implement a write-disable on reset. this does help some.
Ways to improve recoverability:
A more rubust method of DLM is to reserve the first sector of Flash for the DLM. The user code is located above this area. This is very hard to do in the ZW compiler. It also uses up root code space. With Softools this would be possible with a modofied cstart.asm. CStart would check the flash checksum and jump to the DLM if the CRC fails. The user code would have to be modified to allow for this hole in flash. This has not been implemented but may be in a later version of the SHDesigns Softools DLM libraries.