Posted on May 30, 2018 at 18:24Hey folks,
I'm developing a system using the STM32F407 for an application where hardware malfunctions and especially corruption of flash memory due to environmental influences is a thing.
Additionally, the system works in a remote location so that toggling Boot0 pin to reprogram the MCU in case of corruption of the user flash memory isn't that easy as well.
Thus, I've played around with an own IAP bootloader, which is falling back to the system memory bootloader in case it sees the actual application memory to be corrupted and no sotware image to reprogram the MCU is available.
But this raises the risk of the IAP bootloader itself being corrupted and never falling back to the system memory bootloader which would imply that the system is lost (at least for my remote application).
Another option would be to add some other piece of hardware to remotely control Boot0 pin of the STM32. In turn this raises the risk of this additional piece of hardware (and consequently software) failing (the worst case would be to permanently corrupt Boot0 pin so that the STM32 would always enter the system memory loader and waiting forever to be programmed, although itself would still be fine).
Currently I'm failing to assess the risks of both options to go for the 'better' one.
Therefore, I'd like to pose some key questions about the system memory bootloader which I found not or not precisely documented and would be very thankful for anybody sharing his*her knowledge and experience =)
1.) Am I correct that the system memory bootloader, once it is entered, requires at least the 'goto application' command or hardware reset to proceed? Or differently spoken: It does not time out and jump to the application in case it gets no command from any of the supported serial interfaces?
2.) How 'stable' is the system memory regarding environmental influences? I do know that it is factory programmed and read only. But my question aims at the used technology: Is it the very same flash memory as the user flash but only somehow write-protected? Or is it some other memory technology possibly more withstanding against the environment I'm facing? Or is the system memory bootloader even implemented in hardware?
Thanks for your help and best regards,
Thomas
#bootloader-limitation #stm32f4 #bootloader #boot-pins #stm32f407 #iap #embedded-bootloader
