Hi all,
I had a quite hard to time to find out a limitation of the FLASH IAP , valid at least for one actively supported device family: LPC176x.
The issue may not hit the majority of the users, but for the minority I would like to state:
The LPC176x device family requires that your source data resides in RAM.
If it resides in FLASH, mbed likely halts.
I suggest that the documentation is improved here.
Additionally, I think, the code in flash_api.c requires a bugfix (see below).
The RAM limitation can be seen in the file flash_api.c when reading the comments:
IAP.cmd = 51; // Copy RAM to Flash
IAP.par[0] = address; // Destination Flash Address
IAP.par[1] = (unsigned long)source; // Source RAM Address
IAP.par[2] = copySize; // number of bytes to be written
IAP.par[3] = CCLK; // CCLK in kHz
IAP_Call (&IAP.cmd, &IAP.stat); // Call IAP Command
if (IAP.stat) {
return (1); // Command Failed
}type or paste code here
If this error occurs, mbed reacts quite unfriendly:
The function directly returns the result 1. Unluckily you likely will never see this in a debugger.
Instead the system is halted due to failing mutex unlock.
I did not understand the full background, but it seems that the flashing requires some special guarding as the code is embraced as follow:
core_util_critical_section_enter();
// (.. omitted code)
if (IAP.stat) {
return (1); // Command Failed
}
// (.. omitted code)
if (IAP.stat) {
return (1); // Command Failed
}
// (.. omitted code)
core_util_critical_section_exit();
If the IAP commands succeed, everything is ok. But if not, the critical section is left without formally leaving it, i.e. you need something like:
if (IAP.stat) {
core_util_critical_section_exit();
return (1); // Command Failed
}
To be fully honest, I faced the issue on a (no longer) supported device, LPC4088, of course with an older mbed version.
As the code apparently has not been changed since then, the issue remains with current LPC176x devices.
Finally, you may wonder why anybody would like to flash data from one FLASH region to another.
Well, the answer is: when using a two-staged SW, bootloader + firmware, you may want to have the option to do update the bootloader as well.
A rather safe option to make this happen is: Download a special firmware which has just the purpose to update the bootloader. The bootloader code is embedded in the firmware in that case.