User`s manual

Rabbit 4000 Designer’s Handbook rabbit.com 63
7.1.3 Writing the System ID Block
The WriteFlash() function does not allow writing to the System ID block. If the System ID block
needs to be rewritten, a utility to do so is available for download from the Rabbit website:
www.rabbit.com/support/downloads/downloads_feat.shtml
or contact Rabbit’s Technical Support.
7.2 User Block Details
Starting with the System ID block version 3, two contiguous copies of the combined ID/User blocks are
used, or in the case of the version 5 ID block, two contiguous copies of the User block are used. Only one
image contains “valid” data at any time. When data is written to a mirrored User block, the currently
invalid User block image is updated first and then validated by changing its marker[5] byte from 0x00
to 0xAA. This marker is located in the user block itself in version 5 ID blocks where the mirrored user
blocks are separate from the System ID Block, and in version 5 and prior ID blocks where the User block
and System ID blocks are combined, the marker byte is located in the System ID Block. Next, the previ-
ously valid image is invalidated by changing its marker[5] byte from 0xAA to 0x00. Finally, the newly
invalidated image is updated. In this way, there is only a short period of time in which both images are
marked valid, and at no time are both data blocks marked invalid. If a power failure occurs at any time dur-
ing the User block update, the BIOS will still find a valid ID block and the valid User block will contain
data from the last completed update transaction. In addition to making data more secure, this redundancy
allows even very large sector flash types to be used without requiring a large RAM buffer to temporarily
store the contents of a sector, since sectors must be erased before they can be written.
In Dynamic C 7.20 and later, the possibility of mirrored combined ID/User blocks requires that multiple
locations in flash must be checked for a valid ID block. In versions 7.20 through 7.3x, the sequence
described above in Section 7.1.2.1 is used to check not only the top of the primary flash, but also 8KB,
16KB and 24KB below the top, and an error is returned only if no valid ID block is found at any of these
locations. Note the implication here that mirrored combined ID/User blocks are limited to one of 8KB,
16KB, or 24KB in size. Dynamic C versions 8 and later check more locations in flash, from the top down,
at each lower 4KB boundary to 64KB below the top. This allows Dynamic C 8 and up to recognize a com-
bined ID/User blocks size that is any multiple of 4KB up to a maximum of 64KB.
If the version of the System ID block doesn't support the User block, or no System ID block is present,
then the 8 KB starting 16 KB from the top of the primary flash are designated the User block area. How-
ever, to prevent errors arising from incompatible large sector configurations, this will only work if the
flash type is small sector. Rabbit manufactured boards with large sector flash will have valid System ID
and User blocks, so this should not be a problem on Rabbit-based boards.
7.2.1 Boot Block Issues
The System ID and User block implementations have been designed to accommodate huge, non-uniform
sector flash types, but it is necessary to use ‘T’ type parts with such flash types so that the smaller boot
block sectors at the top can be used for the blocks. ‘B’ parts have smaller boot block sectors at the bottom.
No code is included with Dynamic C to lock boot blocks, and users should not lock boot blocks unless
they are sure they will never write to the blocks after the System ID block is written. If a boot block lock is
irreversible, we strongly recommend never locking it.