bootloaders-embedded

# Embedded bootloaders ## Contract | Field | Bound contract | |---|---| | Trigger | An application must run at a non-zero flash offset, a bootloader must validate and jump to it, a firmware update path (UART, USB DFU, custom protocol) is being written, or an application works when flashed alone but fails when launched by the bootloader. | | Authority | Read-only: emits the flash layout, validation checks, handoff sequence, and update-safety rules to chat; the user places them in the project. Rollback is not needed because no file is written. No remote mutation. | | Side effect | Chat output only. | | Done | The flash partition table, the application validity check, the ordered handoff sequence, and the update commit rule are stated for the target part, and the application-side `VTOR` and linker changes are named. | ## Inputs - Target part and its flash map: base address, sector or page sizes, and whether it has two banks. - Bootloader size budget and the chosen application base address. - Update transport (UART, USB DFU, external flash, none). - Where the update request flag lives (RTC backup register, GPIO strap, magic word in RAM). - Whether the vendor part has a system-memory bootloader and which transports it lists in the vendor application note (AN2606 for STM32). ## Procedure 1. Fix the flash layout and relink both images to it. The bootloader starts at the flash base; the application starts at a sector boundary above it and its vector table sits at that base. Don...