Typical bootloaders (including some of ST's built-in bootloaders for other processors) typically allow a code image to be loaded into the processor via some kind of serial link (UART, SPI, CAN, etc), without needing an ST-Link or other debug hardware. These make bootloaders ideal for in-field upgrades of products.
OEMiROT/OEMuROT has some features of a bootloader, in that a new image can be placed in a special area of flash and (if it passes all the various checks) then be executed.
However, there is no way of actually putting that image in flash without an ST-Link or similar, since this is needed to unlock the chip via the DA process. So if you want to do an in-field upgrade of your product's firmware without any debug hardware, OEMiROT in its current form isn't the solution.
Our approach is for our application to download the image into a reserved area of RAM and then switch to the bootloader, where our adapted version of OEMiROT copies this image from RAM to the special area of flash. At this point, the regular OEMiROT code takes over as normal.
As reported in other posts here, it appears that OEMiROT wasn't designed with this kind of functionality in mind. So my question is: was OEMiROT designed as a bootloader (in addition to its security functions)? If so, what is the expected use case?
(ST: please reply here, and not privately.)
