UG-1262
Rev. B | Page 190 of 312
8.
The BurstWriteISR interrupt is called when an interrupt is generated by WRALCOMP.
9.
Disable all interrupts so that sequenced writes to the KH_ADDR register, KH_DATA0 register, KH_DATA1 register, and CMD
register are not interrupted by another ISR, which may also have flash writes.
10.
Read the STAT register to verify the state of several status flags. Clear the flags by writing back the same value and ensure that the
status bits are set appropriately. The WRALCOMP flag is set, indicating that there is still time for the next write to occur for a burst
write. CMDBUSY is set, indicating that the current write operation is still ongoing. CMDCOMP is not set, indicating that a
command has already completed, and, therefore, the command currently in progress is not the earlier write command (another
function has initiated a new command). WRCLOSE is not set. If WRCLOSE is set, the keyhole registers are closed and cannot be
written. WRCLOSE clears when WRALCOMP is asserted.
11.
If no further writes are required, wait for STAT, Bit 2 to be set, clear the bit, and then exit the subroutine.
12.
Request the next 64-bit dual word write through the keyhole access by writing the KH_ADDR register, KH_DATA0 register,
KH_DATA1 register, and CMD register.
13.
Check if the write command was accepted by reading the STAT register to see if any error flags are set.
14.
Reenable interrupts.
15.
Exit the ISR.
To prevent corrupting the flash, execute code with many write accesses to flash from SRAM if possible. Write operations cause ICode
reads to stall, resulting in degraded performance when ICode access is required to fetch the next instruction. This degraded performance
can be partially alleviated by the cache controller.
During a burst write, the flash controller overlaps the write operations and, therefore, any reported write failures (such as access denied
due to write protection) may reflect the status of either of the two overlapped writes. Interpret a burst write failure as a failure for both
the current and the prior write requests.
DMA WRITES
Keyhole writes generally require writing four memory mapped registers per flash write access. An optional address auto-increment feature can
reduce the APB traffic required per flash write transaction to three register writes (KH_DATA0, KH_DATA1, and CMD) for all but the
first in a series of sequential writes. The first write requires setting up the start address. DMA writes reduce the number of APB transactions to
two. Every pair of KH_DATA0 and KH_DATA1 register writes results in a single flash write command executing and the address automatically
incrementing to the next data word. Regardless of the value of auto-increment, DMA writes always increment the address in this manner.
To perform DMA-based writes, user code must first configure the DMA controller (a separate peripheral module) for basic access. DMA
mode supports transferring data to and from peripherals, including the flash controller. After the DMA controller module is set up, it sits
idle until a DMA request signal is asserted by the flash controller.
The user code must manually write KH_ADDR to set up the initial target address for DMA writes. The DMA controller must be
configured to write all output data to KH_DATA1. Each pair of DMA writes to KH_DATA1 executes a single flash write command and
waits for a corresponding delay before the next DMA request signal is made.
To start the flash controller process of requesting data from the DMA controller, the flash controller must be configured for DMA access. To
enable DMA mode, user code must set UCFG, Bit 0. After DMA mode is enabled and the flash controller is idle, the flash controller drives the
DMA request signal to the DMA module. The DMA request signal is driven at the appropriate time to support burst writes. New requests are
made after the current write operation is nearly complete. For more information about DMA functionality, refer to the DMA Controller section.
PROTECTION AND INTEGRITY
Integrity of Information Space
User code does not have any control over the content of information space. If the integrity check fails on a POR, the check is attempted
repeatedly until a preset number of attempts has occurred or the integrity check passes, providing some recoverability from power faults
that occur during device power-up. For all other resets (except software resets, which do not reinitialize the flash controller), the integrity
check is attempted just once.
In the event of an information space integrity check failure, it is expected that the device has failed. Dispose the device or return the
device to Analog Devices for failure analysis. If the information space integrity check does not pass, the flash controller enters a special
purpose debugging mode. In this mode, user space protection is automatically asserted and the flash controller local JTAG protection is
set to allow the JTAG (or other serial wire type interface) to interact with the ICode, DCode, and APB interfaces.