You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
I think the way to avoid this empty write would be to assign eof to copied_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):
USB error after upload; Device reset itself?
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.
The text was updated successfully, but these errors were encountered:
Hmm 🤔 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:
dfu-core/src/download.rs
Lines 313 to 321 in fc9dee3
I think the way to avoid this empty write would be to assign
eof
tocopied_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.
The text was updated successfully, but these errors were encountered: