Your bootloader can matter more than the application code.
The application crashes? A watchdog resets it. A bad update? Roll back to the previous image.
But all of that depends on the bootloader making the right decision.
If image verification is wrong, it can boot corrupted firmware. If a brownout interrupts a write to the boot metadata, it may no longer know which bank is valid. And if your rollback counter lives in the same flash sector as the metadata, one failed erase can take out both.
I’ve seen teams put months into the application and treat the bootloader as a small bit of code they’ll sort out later. That’s a dangerous way to look at it.
A bad OTA payload across 40,000 devices is a serious production incident. A bootloader that can’t recover those devices could mean getting them back from the field.
Test the ugly cases, power loss during writes, corrupt headers, failed verification, exhausted rollback attempts. The bootloader is what you’re relying on when everything else has gone wrong.
What’s the nastiest bootloader failure you’ve had to debug? I’d be interested to hear how you found it.
#EmbeddedSystems #FirmwareDevelopment #Bootloader #OTA #STM32 #FlashMemory