The difficulty with the checksum written into to location 0x1C is that it is weak. It assumes that image load is atomic and that it proceeded without interruption - something that cannot be assumed if IAP is used to load the application into flash from a communications link. If the goal is to ensure a highly robust and failure resistant system, a checksum of the vectors in the first block written is not sufficient. A communication failure would leave the flash with a partially written image but a valid checksum. The naive bootloader would transfer to a partially loaded image and the resulting system crash is not recoverable without a long drive, a hacked off customer, and possibly a now unemployed software engineer. (And yes, the watchdog timer may help prevent this problem, but better to avoid it entirely.)
Does LPC Support have any guidance on how to checksum the entire image at build time and then re-calculate this checksum in the bootloader so that a transfer to a defective immage will not occur (or only occur with sufficiently low probability since even a checksum will not provide certainty)?
Some thoughts that I have had, was to take another of the reserved exception vectors (likely the one at 0x28 - vector 10) and place a full image checksum there. The (custom) bootstrap loader then calculate a CRC-32 checksum across the full image, starting at location 0x2C, possibly including the unprogrammed locations to detect possible flash tampering. Using the vector at 0x28 in this manner should be safe since neither the LPC43xx parts, nor the ARM Cortex M arcitecture have a declared use for this location.
The build process would add a few post build steps to generate the CRC-32 checksum from the project.bin file. The most likely utility is "srecord" as it is open sourced, readily available and easy to use.
The estimated computation time for this CRC-32 calculation would be sub-second for the LPC43xx flash sizes.