ISP vs. IAP

ISP vs. IAP
When it comes to re-programming Flash memory that is soldered down to a PCB (either integrated into the microcontroller or external), there are two programming methods: ISP and IAP.
ISP: In-System Programming
ISP allows for re-programming of a Flash memory device while it is soldered into the target hardware. However, the application needs to be stopped during the re-programming process. Usually, ISP requires that a service technician manually starts the re-programming procedure by halting the application and setting it into a special boot and/or programming mode. Only after programming is completed, the application can be restarted.
In the Philips 89C51Rx2 series, ISP is implemented with the boot loader. The chip is set to ISP mode either by driving pin PSEN high externally right after a hardware reset or by software. When in ISP mode, the 89C51Rx2 accepts Flash-programming commands via the serial interface.
IAP: In-Application Programming
IAP allows for re-programming of a Flash memory device while it is soldered into the target hardware and while the application code is running. With IAP it is possible to implement applications that can be re-programmed remotely without the need of a service technician to actually be present.
In general, IAP can always be realized with external Flash memory, where microcontroller and memory are separated components. This is true as long as there is some additional code memory available out of which the microcontroller can execute code, while the Flash memory is re-programmed.
With on-chip Flash, IAP is only possible if supported by the microcontroller. The Philips 89C51Rx2 parts support IAP also via the boot loader. The application code can call functions in the boot loader area by loading parameters into the registers R0, R1 and DPTR and then calling a specific address in the boot loader. To make these functions easier to use, the Embedded Systems Academy provides a C library supporting all boot loader functions. This allows erasing and programming directly from the C level, simply by calling C functions. For details, check ESAcademy's technical library at www.esacademy.com/faq/progs/.
The following is an example application that uses the C library to perform various IAP operations.

#include "rx2iaplib.h" // IAP Library header file

void isr0(void) interrupt 0 { ; }

void main(void)
{
unsigned int intvector;
unsigned char foo = 0x55;
iap_init(16); // initialize IAP Library by
// specifying crystal
// frequency rounded down
// to nearest integer

iap_erase_block(BLOCK_0x4000_0x7FFF); // erase flash memory from
// 0x4000 to 0x7FFF

iap_program_data_byte(foo, 0x4000); // program the value of a
// variable at 0x4000

intvector = iap_read_data_byte(0x0004); // read the address of the
intvector <<= 8; // interrupt 0 service
intvector = iap_read_data_byte(0x0005); // routine

// set security bits 1 and 2
iap_program_security_bits(SECURITY_BIT_1 SECURITY_BIT_2);

while(1);
}
The C library, combined with the features of the boot loader provided in ROM, makes it easy to re-program the start address of the boot loader currently used. This actually allows installing a customized boot loader instead of the one included in ROM. Such an application specific boot loader could ensure that essential initialization code gets executed, even if the chip starts in boot mode.
void callnewbootloader(void)
{
iap_erase_boot_vector_status_byte();
iap_program_boot_vector(0xE8); // new bootloader at 0xE800
iap_program_status_byte(0xFF); // execute bootloader on reset
reset_device();
}