feat(boot): enhance firmware write functionality

[badrbouslikhin]

This PR modifies the firmware update process via USB DFU, enhancing compatibility with high-capacity microcontrollers by optimizing how firmware images are received from a host.
Instead of erasing flash pages for each received chunk, which is not feasible for microcontrollers with large erase sizes like the STM32H747XI, we now erase the entire DFU partition upfront and sequentially write incoming chunks without further erasures.

This approach resolves compatibility issues with microcontrollers where the erase block size exceeds the USB control buffer capacity, which is often limited to 4KB. Such a mismatch makes it impossible to efficiently manage page erasures for each chunk received, as required by the standard USB DFU protocol which does not communicate the total number of chunks or their target addresses in advance (such mechanism is supported in DfuSe).

By introducing a write_firmware_without_erase method, used in conjunction with prepare_update, this PR allows for a more efficient firmware update process.
This method aligns with the third mechanism outlined in the USB DFU v1.1 spec, where a significant portion of memory is pre-erased, and firmware chunks are written into the prepared space without additional erasures.

[lulf]

I think rather than introducing write_firmware_without_erase API, you should use the flash borrow returned from prepare_update to do the writing. Or is there something preventing that?

[badrbouslikhin]

That was the first thing I tried, but I struggled with lifetimes. It was especially tricky when I had both a BootLoader and a BlockingFirmwareUpdater instances in different scopes of the bootloader. For example, if the bootloader starts and it detects that a specific button is pressed, it sets State::DfuDetach and begins a USB DFU update.

I agree that the proposed API here isn't great though.

[Dirbaio]

I think this can be fixed without extending (and therefore complicating) the FirmwareUpdater public API.

The issue is write_firmware requires the data to be page-aligned, which is prohibitive if pages are too big. We can instead make it accept smaller chunks, write them incrementally to the page, and when crossing into a new page, erase it before writing to it.

For example, when having 4kb pages and writing 1kb chunks:

• 0th write_firmware call erases page 0, writes 1kb of data.
• 1st write_firmware writes 1kb of data.
• 2nd write_firmware writes 1kb of data.
• 3rd write_firmware writes 1kb of data.
• 4th write_firmware call erases page 1, writes 1kb of data.
• 5th write_firmware writes 1kb of data.
• etc

if written properly, this'd allow chunks to span across pages even. So the only requirement for chunk size is to be a multiple of WRITE_SIZE, but not necessarily a divisor of ERASE_SIZE. For example, with 4kb pages writing 2.5kb chunks:

• 0th write_firmware call erases page 0, writes 2.5kb of data.
• 1st write_firmware writes 1.5kb of data, erases page 1, writes 1kb of data.
• 2nd write_firmware writes 2.5kb of data
• etc

Advantages:

• Doesn't complicate public API
• Keeps updates fast. If your partition is 1MB but the firmware is 200kb, you only end up erasing 200kb (rounded up to erase size), instead of the full 1MB.

[badrbouslikhin]

@Dirbaio I like your suggestion! Let me give it a shot.

[badrbouslikhin]

I've implemented the mechanism suggested by @Dirbaio.
I've added a few tests make sure it works if various configurations and tested the changes on an STM32H7 + USB DFU (only the blocking implementation not async, although tests pass).

Let me know what you think.

[lulf]

Overall looks good, left one comment. And thanks for adding tests!

[lulf]

Looks good! I will give the async version a spin before merging.

[lulf]

Confirmed it works on nrf with async, thanks for the contribution! 🚀