Request criticism and feedback on my fail-safe dual slot bootloader and single slot bootloader for STM32F446ZE

[tantheman]

I have made a bootloader for STM32F4 with dual bank and single bank structure. I have done so rudimentary testing with it and written test logs in a md file.

 

Here is the link:-

https://github.com/Tank4676/stm32-dualslot_bootloader

[mƎALLEm]

Hello ​@tantheman ,

Please avoid capital letters for a full text (the title here) as it gives the impression you’re shouting.

Thank you for your understanding. I’m editing the title then.

Good luck.

[tantheman]

I’m truly sorry it was not my intention, would love to have some feedback on this if you can 

 

[T_Hamdi]

Hello ​@tantheman 

Thank you for this project and for your effort.
I will review it and get back to you with my feedback.

Also, could you please let me know exactly what you would like me to review, so I can address your needs as best as possible?

with regards,

Hamdi

  

[tantheman]

Hello Hamdi,

Thank you for taking the time to review my project.

I'm building a custom dual-slot bootloader for the STM32F446ZE with the following features already implemented:

• Dual-slot flash architecture with a boot descriptor in a dedicated sector for slot management
• OTA firmware updates over UART with per-chunk CRC32 verification
• MSP range check and full firmware CRC validation before jumping to the application
• Automatic failover to the other slot if the active slot fails validation
• Post-build Python tooling for CRC and metadata injection

Specifically, I'd appreciate your feedback on:

1. Boot flow robustness — whether my slot validation and failover logic handles all edge cases correctly, especially first boot and both-slots-invalid scenarios.
2. OTA protocol design — the chunked transfer with per-chunk CRC works, but it is slow (~8 minutes for 128 KB). Are there recommended patterns from ST for faster and reliable transfer without sacrificing safety?
3. Bootloader deinit before jump — I found that calling HAL_RCC_DeInit() and HAL_UART_DeInit() prevented the application from starting properly. Only clearing SysTick and disabling interrupts worked. Is this the ST-recommended approach, or am I missing something?
4. Flash sector allocation — my layout has some waste (a full 128 KB sector 5 used for a ~36-byte descriptor). Is there a cleaner approach on STM32F4 with its non-uniform sector sizes?
5. Any general architectural feedback you can offer as someone from ST who has seen many bootloader implementations.

Repository:

https://github.com/Tank4676/stm32-dualslot_bootloader

Beyond the bootloader review, I'd also like to ask for your guidance on what to work on next. I want to go deeper into embedded systems and firmware engineering, ideally in areas that are technically challenging and relevant to what ST and the wider industry actually build.

Given your experience at ST, I'd really value your perspective on:

• Which areas would give me the strongest foundation as an embedded engineer?
• Are there specific areas where junior engineers commonly struggle that a self-driven project could prepare me for?
• Are there any ST open-source repositories, contribution paths, or community programs you'd recommend to get involved with?

Thank you again for your time and for engaging with my work.

Best regards,
Tanmay