What may be the reasons to call IAP routine from embedded application (LPC1788)?

[Eugene723]

The process is described in LPC1788 processor’s User Manual rev. 4 of December 2016, chapter 37.8:

//The following snippet of code is simplified

#define IAP_LOCATION 0x1FFF1FF1

iap_entry=(IAP) IAP_LOCATION;

iap_entry (command, output);

What would be typical reason(s) to have such function in an embedded application?

Background info:

While reviewing an old application that I have taken up for support and maintenance, I noticed similar code:

#define IAP_HOOK_FN( in, out ) ((( void(*) (unsigned int , unsigned int*) )0x1FFF1FF1 ) ( (in), (out)) )

#define iap_mode (LPC_RTC.GPREG0)

#define IAP_DOWNLOAD (((uint32_t)'I' << 24) | ((uint32_t)'A' << 16) | ((uint32_t)'P' <<  | ((uint32_t)'D'))

#define IAP_RESTART (((uint32_t)'I' << 24) | ((uint32_t)'A' << 16) | ((uint32_t)'P' <<  | ((uint32_t)'R'))



//The following snippet is invoked early in in “main” (long before the main loop):

#ifdef IAP_HOOK_FN

                if (iap_mode == IAP_DOWNLOAD) {

                                iap_mode = IAP_RESTART;

                                iap_params[0] = 57;

                                IAP_HOOK_FN (iap_params, iap_params);

                                __CPU_RESTART();

                } else if (iap_mode == IAP_RESTART) {

                                iap_mode = 0;

                                __CPU_RESTART();

                }

                iap_mode = 0;

#endif

Since I’m relatively new to embedded development, I’d like to know if this code is typical or unconventional. For this code to execute, bytes “IAPD” have to be written into “LPC_RTC.GPREG0” register described as “General purpose storage that can be used to store important information when the main power supply is off” (User Manual, chapter 29.6.6.1 page 796).

To add to my puzzlement, the function writing “IAPD” into “LPC_RTC.GPREG0” is never called and is removed from the image by the linker (per .map file) Original application and hardware designers implemented two buttons: one is to bring pin P2[10] down and another one is to reset. Am I correct in understanding that this also invokes IAP routine located at 0x1FFF1FF1 address? If so, why implementing a call to IAP routine from the firmware code?

Thank you,

Eugene

[frank_m]

> Original application and hardware designers implemented two buttons: one is to bring pin P2[10] down and another one is to reset.

I would need to read the MCU DS and user manual, but I'm pretty sure this method is intended to invoke the ROM-based system bootloader, i.e. gets the device into ISP mode.
From that point on, Flash manipulation (erase, firmware update) has to follow the protocol specified by NXP, via one of the interfaces supported by the device

> If so, why implementing a call to IAP routine from the firmware code?

This usually requires a second-stage bootloader, i.e. one you write yourself.
It is additional code and effort (including project setup & link management), but you can support any protocol and interface you are willing to implement in your BL.
My company uses such a second-stage BL in most of its devices, to allow for an update via UDS in a CANopen network.