Boot Loader: Secure Read/Write or Custom Boot Loader Starting Point?

[peterlacerenza9]

Posted on May 02, 2016 at 19:33

I am getting started in developing for the STM32F407.

One thing that is certain is that I will need either secure read/write (i.e. passcode-protected), or encrypted read/write (i.e. data read out not immediately readible/usable).  I'm finding in my research that the standard STM32 boot loader does not fall into either of these categories, so my question here is two-fold:1.) Are there any currently-existing boot loaders with either of these capabilities? (If so: recommendations?)  Obviously this is preferable: less development work.2.) How would I get started on my own custom boot loader?I'm not finding much documentation on this, aside from where in flash the boot loader should reside (top of Flash for System Memory boot mode).  I'm hoping I'm overlooking something in within the several application notes and the ref. manual.Finally, a last question:I want USART and CAN capabilities with this to do the read/write of sw (Flash).  If I do not use the default STM32 embedded bootloader, am I still limited to the same peripherals (USART 1 or 3, CAN2), or do I have all options available to me, based on how that other bootloader is written?Thank you for any assistance that can be provided! #bootloader #iap #stm32 #stm32f4

[Tesla DeLorean]

Posted on May 02, 2016 at 20:33

The techniques to writing boot loaders are pretty universal, don't limit yourself to docs dealing solely with STM32 parts.

You write the code, you can use whatever pin, port and protocols you want.Loaders tend to be very product specific, tightly coded, and to be closed source.

[re.wolff9]

Posted on May 03, 2016 at 09:57I'm not sure if you ''top of flash for system boot mode'' is correct. System memory is factory programmed (mask or otherwise). You can't put your own bootloader there. (Best case, you could write your own bootloader and then ask ST to put your bootloader in system memory if you buy a million CPUs....)That said, the cheaper CPUs just boot from flash by using the first entries from the vector table at the beginning of flash. IIRC the bigger CPUs may have hardware bootloader assistance by being able to jump to another location. ON second thought, that might be AVRs that have this capability. In most cases, you would just put your bootloader at the start-of-flash, and then link your application to go after it. (with enough room to spare should there be a bug in the bootloader). On the F407, you can then relocate the vector table and jump to the application entry point.