Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

STM32 exit DFU feature #24

Open
YgorSouza opened this issue Mar 23, 2023 · 2 comments
Open

STM32 exit DFU feature #24

YgorSouza opened this issue Mar 23, 2023 · 2 comments
Labels
help wanted Extra attention is needed

Comments

@YgorSouza
Copy link
Contributor

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

eof: bytes.is_empty(),
},
);
let res = self.dfu.io.write_control(
REQUEST_TYPE,
DFU_DNLOAD,
self.block_num,
&bytes[..len as usize],
)?;

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.

@cecton
Copy link
Member

cecton commented Mar 24, 2023

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.

@cecton
Copy link
Member

cecton commented Nov 4, 2024

I don't mind doing it as soon as I have time.

famous last words

@cecton cecton added the help wanted Extra attention is needed label Nov 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

2 participants