In OEMiROT_Boot/Src/low_level_ext_flash.c, function Ext_Flash_EraseSector(), a call is made to EXTMEM_MemoryMappedMode() immediately before the sector erase takes place, to temporarily disable memory-mapped mode for the external flash, with the function called again afterwards to re-enable it.
As @ken5 reported previously, we found that these flash erases can cause corruption in the external RAM.
After a lot of experimentation and head-scratching, we've found that if the external RAM is also removed from the memory map before a flash erase, and re-enabled afterwards, these corruption issues appears to go away (pending further testing).
I'm guessing that this wasn't spotted in ST's testing because OEMiROT doesn't use the external RAM until later (if at all), so any corruption doesn't matter. However, our adapted OEMiROT does use the external RAM, and the data corruption was a serious problem.
(Incidentally, we saw occasional corruption in the external flash as well, as if the erase were incomplete. This was sometimes picked up by OEMiROT's integrity checks.)
The proposed fix is fairly simple:
/* Disable memory mapped mode */
#if (OEMIROT_LOAD_AND_RUN == LOAD_AND_RUN_EXT_RAM)
/* Must also disable RAM, if enabled, otherwise it can be corrupted by the
* erase operation. */
EXTMEM_MemoryMappedMode(MEMORY_PSRAM_0, EXTMEM_DISABLE); // <---- Add this line.
#endif
if (EXTMEM_MemoryMappedMode(MEMORY_SERIAL_0, EXTMEM_DISABLE) != EXTMEM_OK)
{
return ARM_DRIVER_ERROR;
}
/* Reload Independent Watchdog */
IWDG->KR = KR_RELOAD;
ARM_EXT_FLASH0_STATUS.busy = DRIVER_STATUS_BUSY;
err = EXTMEM_EraseSector(MEMORY_SERIAL_0, addr, (ARM_EXT_FLASH0_DEV.data)->sector_size);
/* Enable back memory mapped mode (even in case of erasing error) */
err_mapped_mem = EXTMEM_MemoryMappedMode(MEMORY_SERIAL_0, EXTMEM_ENABLE);
#if (OEMIROT_LOAD_AND_RUN == LOAD_AND_RUN_EXT_RAM)
EXTMEM_MemoryMappedMode(MEMORY_PSRAM_0, EXTMEM_ENABLE); // <---- Add this line.
#endif
For safety, we also added similar lines in Ext_Flash_ProgramData(), though this may be unnecessary as we're not aware of any corruption issues caused by writing to flash.
Please consider adding a fix like this to the next version of the code.
(Edit: we saw this behaviour with the system clock running at 380 MHz, as is used by OEMiROT, but not at the 600 MHz used by our app and development bootloader. We're curious why this might be.)
(ST: if you reply privately, please don't delete this post, in case it's of use to future readers.)
