Reference Manual ADuCM356
FLASH CONTROLLER
analog.com Rev. A | 185 of 312
write the same values to the WRPROT register. When writing the
WRPROT metadata, consider including write protection of the least
significant page, which protects the metadata from a page erase
or other modification. As with all flash locations, do not perform
repeated writes without intermediate erasures, because repeated
writes tend to cause ECC errors during readback.
After protection is enabled (the corresponding bit has been cleared
in WRPROT), it cannot be disabled without resetting the device.
For this reason, after write protection is enabled for any block of
pages through the user space metadata, it cannot be disabled
without erasing the least significant page of user space or otherwise
affecting the flow of the bootloader.
The following sequence outlines the process of programming the
write protection metadata word in flash:
1. Ensure that the least significant page of user space has been
erased since the last time the metadata was written.
2. Write the desired value for the WRPROT metadata word direct-
ly to flash. Write 0 to a particular bit to enable protection for the
corresponding block.
3. Verify that the write completed by polling the status register.
4. Reset the device. WRPROT, Bits[31:0] are automatically up-
loaded by the bootloader from user space to the WRPROT
register and are used to enforce the protection scheme.
Signatures
Signatures are used to check the integrity of the flash device
contents. Signature calculations do not include the ECC portion of
the flash data bus or the most significant word read from the set
of pages being signed. The most significant word is considered
metadata and is intended to hold the expected signature value for
the given set of pages.
The flash controller implements its own standalone CRC engine for
generating and verifying signatures. However, this implementation
matches the CRC accelerator peripheral with an initial value of
0xFFFFFFFF. For more information about the CRC algorithm used,
refer to the Cyclic Redundancy Check section.
Signatures can be included in the initial upload of user data and
program code generated before being uploaded, or can be generat-
ed and stored to flash at run time. Generation at run time utilizes
the CRC accelerator or calls on the signature generation logic of
the flash controller.
ECC bytes correspond to 64-bit data words in the flash memory.
As such, if ECC is enabled, the most significant 64 bits (including
the 32‑bit signature word) must be written all at once. Otherwise,
the ECC byte is corrupted by the second write. If using the flash
controller to generate the signature value, leave the unused 32 bits
paired with the signature word in their erased state (0xFFFFFFFF).
Otherwise, spurious ECC errors may occur after device reset (de-
pending on WRPROT configuration) and the device may become
unusable.
The sign command generates a signature for all data from the start
page to the end page, excluding the signature metadata word. The
user must define the start and end pages by writing PAGE_ADDR0,
Bits[18:10] and PAGE_ADDR1, Bits[18:10], respectively.
To generate or verify a signature, perform the following steps:
1. Write the start address of a contiguous set of pages to
PAGE_ADDR0, Bits[18:10]. If out of bounds, the command is
denied.
2. Write the end address of a contiguous set of pages to
PAGE_ADDR1, Bits[18:10]. If out of bounds, the command is
denied.
3. Write to Key, Bits[31:0]. Write the user key value (0x676C7565)
to the key register.
4. Write to CMD, Bits[3:0]. Write the sign command (0x3) to the
CMD register.
5. Wait. When the command is completed, STAT, Bit 2 is set.
6. If using the flash controller to generate a signature to write into
the flash metadata, the signature value can be read from the
signature register.
7. The generated signature is automatically compared with the
data stored in the most significant 32-bit word of the region
being signed. If the generated result does not match the stored
value, a fail is reported in the STAT register by asserting a verify
error in the STAT, Bit 2 field.
While the signature is being computed, all other accesses to the
flash are stalled. Generating and verifying the signature for a
256 kB block (full user space) results in a stall duration of 32 kB
flash reads (64 bits per read operation) or approximately 64,000
HCLK periods. The PAGE_ADDR0, Bits[18:10] and PAGE_ADDR1,
Bits[18:10] addresses can be written as byte addresses but are
consumed by the flash controller as page addresses. When this
occurs, the lower 10 address bits are ignored. The sign com-
mand is denied if PAGE_ADDR1, Bits[18:10] is less than the
PAGE_ADDR0, Bits[18:10]. Signatures are always performed at a
page level granularity over continuous address ranges.
KEY REGISTER
To prevent spurious and potentially damaging flash accesses, some commands and registers are key protected. The user key is not a security
element and is not meant to be a secret. Instead, this key protects users from negative consequences of software bugs, especially during early
software development.
To Next Page
Loading...
Need help?
General