
UM10850
All information provided in this document is subject to legal disclaimers.
© NXP B.V. 2016. All rights reserved.
User manual
Rev. 2.4 — 13 September 2016
418 of 464
NXP Semiconductors
UM10850
Chapter 31: LPC5410x Flash API
The operation of ECC is transparent to the running application. The ECC content itself is
stored in a flash memory not accessible by user’s code to either read from it or write into it
on its own. A byte of ECC corresponds to every consecutive 128 bits of the user
accessible Flash. Consequently, Flash bytes from 0x0000 0000 to 0x0000 000F are
protected by the first ECC byte, Flash bytes from 0x0000 0010 to 0x0000 001F are
protected by the second ECC byte, etc.
Whenever the CPU requests a read from user’s Flash, both 128 bits of raw data
containing the specified memory location and the matching ECC byte are evaluated. If the
ECC mechanism detects a single error in the fetched data, a correction will be applied
before data are provided to the CPU. When a write request into the user’s Flash is made,
write of user specified content is accompanied by a matching ECC value calculated and
stored in the ECC memory.
When a sector of Flash memory is erased, the corresponding ECC bytes are also erased.
Once an ECC byte is written, it can not be updated unless it is erased first. Therefore, for
the implemented ECC mechanism to perform properly, data must be written into the flash
memory in groups of 16 bytes (or multiples of 16), aligned as described above.
31.3.4 Criteria for Valid User Code
The reserved CPU exception vector location 7 (offset 0x0000 001C in the vector table)
should contain the 2’s complement of the check-sum of table entries 0 through 6. This
causes the checksum of the first 8 table entries to be 0. The boot loader code checksums
the first 8 locations in sector 0 of the flash. If the result is 0, then execution control is
transferred to the user code.
If the signature is not valid, the auto-baud routine synchronizes with the host via the serial
port (USART).
If the USART is selected, the host should send a ’?’ (0x3F) as a synchronization character
and wait for a response. The host side serial port settings should be 8 data bits, 1 stop bit
and no parity. The auto-baud routine measures the bit time of the received
synchronization character in terms of its own frequency and programs the baud rate
generator of the serial port. It also sends an ASCII string ("Synchronized<CR><LF>") to
the host. In response to this, the host should send back the same string
("Synchronized<CR><LF>").
The auto-baud routine looks at the received characters to verify synchronization. If
synchronization is verified then "OK<CR><LF>" string is sent to the host. The host should
respond by sending the crystal frequency (in kHz) at which the part is running. The
response is required for backward compatibility of the boot loader code
and is ignored. "OK<CR><LF>" string is sent to the host after receiving the crystal
frequency. If synchronization is not verified then the auto-baud routine waits again for a
synchronization character. For auto-baud to work correctly in case of user invoked ISP,
the clock frequency should be greater than or equal to 10 MHz. In USART ISP mode, the
part is clocked by the IRC and the crystal frequency is ignored.
Once the crystal frequency is received the part is initialized and the ISP command handler
is invoked. For safety reasons an "Unlock" command is required before executing the
commands resulting in flash erase/write operations and the "Go" command. The rest of
the commands can be executed without the unlock command. The Unlock command is
required to be executed once per ISP session. The Unlock command is explained in