cecton
commented
1 year ago Hmm :thinking: yes that does not look intentional..... although I'm not sure tbh. @sjoerdsimons may I have your input on this? I know it's not your code but you know the stuff very well.
Since apparently this is kind of a "feature", the best approach would be to add a method that would allow the user to do this "jump to application firmware" intentionally. While also removing this "0 write" at the end of the download process.
If you make a PR it would be faster but I don't mind doing it as soon as I have time.
The STM32 built-in bootloader has a sequence that allows exiting the bootloader and jumping to the application firmware. It consists of a write command with 0 bytes, followed by a read of the status, as explained in AN3156. This crate currently performs this sequence, seemingly by accident, as it does send an empty write here:
https://github.com/dfu-rs/dfu-core/blob/fc9dee3e03c1f5133e8f99a42dd5135407f98f57/src/download.rs#L313-L321
I think the way to avoid this empty write would be to assign
eoftocopied_pos + len == end_pos, then it would stop at the previous block before the empty one. I assume this is accidental because I couldn't find any mention of it in the docs or the source, and the download function treats it as an error, as the DFU device gets disconnected. The download example from the dfu-libusb crate reports it like this (source):I was wondering if this could be made into an actual feature that the caller can opt into or out of when calling the download function, or as a separate function altogether if it makes more sense.