IAP for all flash

"I know that while I program the flash if there will be power fail I will get into trouble - How to avoid them?"

Don't replace everything. Keep a small 4kB boot loader in the first sector of the flash. If you get a power loss, the 4kB boot loader will allow the programming to restart.

Or make the first UART and the a push-button available, so an end-user may activate the NXP boot loader and perform a full download.

I want to replace all the flash code in the internal flash at site. [...] I know that while I program the flash if there will be power fail I will get into trouble - How to avoid them?

By not doing the former, or ensuring the latter cannot happen.

Replacing the entire executable code makes it impossible to be fully robust to power-failure. At some point in the process, you'll have to draw the rug away under your own feet. You'll be erasing the flash page with the reset vector in it, or something like that. If power fails before you've rolled out the new rug, you end up with a dead parrot.

The usual alternatives are:

1) a fixed bootloader that you never overflash

2) backup power supply to allow finishing the operation cleanly.

Hi,
Thanks for the reply.
Ok, I will use a small part as a bootloader. What are the steps to follow. How can I redirect the code to run into the bootloader while programing and after I have the code - to run only my program..

Thanks,
Doron

What are the steps to follow. How can I redirect the code to run into the bootloader while programing

You have that backwards. You don't redirect into the bootloader, you have the bootloader redirect to your application. I.e. the bootloader is the primary program that runs directly out of reset. The bootloader then checks if there's a valid application program present. If there is, the bootloader jumps to it. Otherwise it just waits for a fresh program on its input channel.

Otherwise it just waits for a fresh program on its input channel.

In this case it doesn't need to wait for a new download. Since the OP has an external flash for downloading the new binary, a power loss when copying from external to internal flash isn't dangerous. The boot loader can restart the copying, and leave all transfers to the application. The only way to loose the chip then is if the internal flash is broken and can't be reprogrammed (in which case the hardware has to be replaced anyway) or a seriously buggy application has been downloaded, that fools the bootloader to start the application, but where the application does not perform as expected.

Since the OP has an external flash for downloading the new binary, a power loss when copying from external to internal flash isn't dangerous.

But a powerloss while filling the external flash from elsewhere, would be.

Not with a boot loader. It would also produce a broken copy, but the boot loader would be able to restart the copy.

Without room for two application copies, the boot loader must wait for a new transfer in case of a power loss during the update. With room for two application copies, the boot loader do not need any transfer capabilities - just the ability to detect a partial copy.

Sorry, I think I missed your point.

"But a powerloss while filling the external flash from elsewhere, would be."

If the external flash is just used as a scratch buffer for the transfer+reprogramming cycle, a power loss during the transfer to external flash should not be dangerous.

A working boot loader should be able to notice that it has a valid crc for the main application, but a broken crc for the new application and then just start the application in the internal flash. That application can then restart the transfer of a new application into the external flash.

If the boot loader do find a valid image in both internal and external flash, it can compare the two images and see if a copy is needed. After a full copy is done, the boot loader may decide to erase the external flash or toggle a flag in EEPROM or similar, just to speed up following reboots.