UG-1262
Rev. B | Page 192 of 312
If immediate protection is required, user code must also write the same values to the WRPROT register. When writing the WRPROT
metadata, consider including write protection of the most 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 most 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 most 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 directly to flash. Write 0 to a particular bit to enable protection for the
corresponding block. In the 256 kB flash, this word is available at Address 0x3FFF0.
3.
Verify that the write completed by polling the status register.
4.
Reset the device. WRPROT, Bits[31:0] are automatically uploaded 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 generated 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 (depending 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 command 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.