Design a Power-Loss-Safe Bootloader That Updates Application Firmware

Design a bootloader that can update the application firmware of an embedded device. The bootloader runs first on every reset and decides whether to start the installed application or install a new one. Explain how a new application image reaches the device, where it is stored, how it is verified and installed, how the bootloader hands control to the application, and how the device stays able to boot if an update is interrupted. The report names only the task, so the hardware, the update channel and the security requirements are open: settle them with the interviewer before designing. ```hint Pull the plug Walk through your update step by step and ask, at each step, what the device does if power is lost right now and it restarts. ``` ```hint Trusting the image Ask how the bootloader knows that an image is complete, intact and from the right source before it ever jumps to it, and what happens if the new application starts but then misbehaves. ``` ### Clarifying Questions - What hardware is it: how much internal flash, is there external flash, and what is the erase-block size? - Is there room for two complete application images, or only one? - How does the new image arrive: serial, USB, CAN, a network, or over the air through the running application? - Must images be authenticated, and must the device refuse older versions? - Must the bootloader itself be updatable in the field? - How long may the device be out of service during an update? ### What a Strong Answer Covers - A flash layout for the bootloader, update state and application images, and why the bootloader region is protected - An update flow that survives power loss at any instant, with a clear commit point - Image verification: integrity, authenticity and version checks - Fallback after a bad update: trial boot, confirmation by the application, watchdog, recovery mode - The handoff to the application: vector table, stack pointer, and resetting what the bootloader used - Updating the bootloader itself, testing under fault injection, and diagnostics ### Follow-up Questions - The device has room for only one application image. How does your design change, and what is lost? - How would you update the bootloader itself without risking a device that never boots again? - A new image passes its signature check but crashes within seconds of starting. How does the device recover without a technician? - How would you show that power loss at any moment during an update leaves the device bootable?