Can anyone recommend a good/simple/free bootloader example for STM32F0 - Page 1
Forum section: electronics / projects

author: Psi
author_rank: Super Contributor
timestamp: May 22, 2025, 08:12:36 am
content: I need to add a USB based bootloader to my new STM32F0 product with some encryption (Don't want to so distribute raw bin files.)I can handle the encryption part myself as I already made a bootloader for an AVR product long ago with simple PC1 cipher.But it would be great to have a solid STM32F0 bootloader example project to adapt for my needs.I've seen a few on GitHub but just wondering if anyone has one they recommend?Ideally one that already setup to init the USB controller into VCP mode.Any recommendations welcome.

author: darkspr1te
author_rank: Frequent Contributor
timestamp: May 22, 2025, 01:36:15 pm
content: The STM DFU example as it supports encryption , but fix the DFU read back bug or it will just spill the flash contents with the correct type of packet.Depending on your design (if you included vcc usb power sense for example) you could detect vcc on boot and if found jump to bootloader or stay in boot loader as i do it in my code.darkspr1te

author: Psi
author_rank: Super Contributor
timestamp: May 23, 2025, 04:30:07 am
content: I've heard bad things about dfu mode and driver issues. Is that still the case?Do I need to bundle a special dfu driver version in my app/installer

author: darkspr1te
author_rank: Frequent Contributor
timestamp: May 23, 2025, 05:52:04 am
content: The stm implements a standard dfu device driver wise and i've never needed a external driver(win10) with win7 ymmv . software wise you can supply dfu.exe as thats all thats needed to apply updates/firmware.darkspr1te

author: peter-h
author_rank: Super Contributor
timestamp: May 23, 2025, 01:49:07 pm
content: Why do you need a bootloader when you can have code in the CPU which receives an encrypted firmware file, using whatever system you want, decrypts it, CRC checks it, and flashes it?

author: langwadt
author_rank: Super Contributor
timestamp: May 23, 2025, 03:01:22 pm
content: Quote from: peter-h on May 23, 2025, 01:49:07 pmunlikely to have enough ram to do that

author: radiolistener
author_rank: Super Contributor
timestamp: May 23, 2025, 03:12:16 pm
content: using encryption to flash firmware is a stupid idea, because those who need to read your unencrypted firmware can do it, but you will spend flash space for useless code to encrypt/decrypt it and can introduce bugs and issues to your code.

author: darkspr1te
author_rank: Frequent Contributor
timestamp: May 24, 2025, 07:52:49 am
content: I kinda agree with radiolistener on this on, i myself have found the necessity to crack a stm32 based device to dump it's firmware ,in my case it's only been for repair/open source firmware but it can be done quite easily,depending on who your device is distributed to will depend on how long it takes,To answer peter-h question :-a bootloader it required when you need to receive firmware/verify and then write to the device in such a way that if there is a mistake it does not render the device useless, a example would be my roland CNC machine, roland themselves sent me firmware to fix issues i was having with my device, firmware 1/2/3 all rendered the device dead for operation but still flashable if i can get the correct firmware which by file 4 they thankfully fixed their mistake and sent me the firmware for the egx300 where as all prior files were for a egx250, this fixed the device which i still use to this day but it would have been scrap without some form of bootloader.darkspr1te

author: peter-h
author_rank: Super Contributor
timestamp: May 27, 2025, 08:23:47 am
content: You can address these requirements without using the device's boot loader feature.You do a "boot clock" which is never overwritten. My last project does just that. I've posted reams on that topic in various boot block threads - a search should find it