In all the history of LPC microcontrollers I don't see it differently: the flash controller itself and the way the flash is erased and programmed is mostly described over the IAP API. The few static settings like wait states or the CRC feature are explained.
I have no problem with the expression "Reserved: leave existing value unchanged", it exactly defines the usage of this bit field. It doesn't define it "for future use" and it doesn't express that it is not used by the system. It only says that the user should not touch the existing values.
We implicitely described the bit PDRUNCFG0[5] by opening up the power lib source code
https://www.nxp.com/docs/en/application-note/TN00038.zip
where you find the definition of this bit and the usage for achieving lowest power operation. See further down below why we don't document it this way in the UM.
With regards to the missing description of the flash controller itself: it is a proprietary flash architecture and we don't want to open it up. As this flash is always part of the LPC microcontroller device, there is even no need to do that, because the operation is handled by the ROM code API. This is as good as the programming procedures defined for external flash devices.
The reason behind the reduction to API usage is simple: minimize the risk of doing something wrong.
I can't think of applications where calling into the boot ROM is inappropriate. By doing this, you only need to consider a few things:
- Active interrupts are risky, as they would interrupt and delay activities which have been triggered to run from ROM
- For activities on the flash the interrupts are dangerous, as the interrupt vectors reside at the beginning of the flash. During erase and program cycles the flash goes offline from the bus and any access from the ARM to the interrupt vector table would cause an exception. But it would not be an organized exception, as the vector the ARM gets back for the location of the exception handler is random ...
To work around this problem, you can remap the interrupt vector table to another memory location, for example to RAM. Then your application can continue with its job, under the condition that any access to flash memory locations is forbidden.
Regards,
Bernhard.
