DFU 64kB write size

[michalcourson]

The QSPI writes are fastest when everything aligns with the 64k boundaries. The FAT flash already writes in 64k chunks, but the DFU does not. I've added a buffer to defer the writes until either there is 64k to write, or the end of the file is reached.

I get a ~25% speed improvement with a ~3.5MB test file (41 seconds to 30) in the download portion of the flash procedure.

[stephenhensley]

Hm, so when I try to program my test program with this (rebased to the latest updates), I consistently get the same error, but at different parts of the program cycle.

The error is:

Download	[                         ]   1%        58368 bytes failed!
DFU state(10) = dfuERROR, status(11) = iString indicates a vendor specific error
dfu-util: Failed to write whole chunk: -1 of 1024 bytes

The failures occurred at various points: 40960, 58368, and 56320 bytes in three consecutive attempts.

Seems like it is consistently less than than the new block size, but I haven't looked much deeper than that yet.

[michalcourson]

hmm interesting. I did not see those errors, but I was also not rebased to the latest updates. I think I'll also have some time today to look into it

[michalcourson]

Errors are coming from here

DFUHandle::Result DFUHandle::Impl::MemoryWrite(uint8_t *src, uint8_t *dest, uint32_t Len)
{
    if (io_state.busy) {
        dfu_log.pushEvent(DfuLogger::Event::Type::WriteBusy, System::GetNow(), (uint32_t)dest, Len, 0);
        return Result::ERR;
    }
...

I'm pretty sure it's happening because the transfer size has changed from 4096 to 1024, so the timing is different. Looking at ways to fix this while still keeping it fast.

[michalcourson]

All I have so far is to extend the poll timeout, but that just slows the whole process down.

I think there are download speed improvements with the new middleware that I didn't notice anyway. I'm getting roughly the same speed during download with the current main branch that I did with this update. So I'm pretty content with just abandoning this idea.

However, we should also put "#define USBD_DFU_XFER_SIZE 4096" in the usbd_conf.h file as well to get the transfer size back up to where it was before. That does make a pretty big difference to the usb download speed.

[stephenhensley]

oh, I meant to include my test program to help with troubleshooting, but totally spaced.

But that makes sense to me, I can do that update to libDaisy's usbd_conf sometime early next week.

Feel free to close this if you'd like, otherwise we can leave it open until we see if the xfer size update in libDaisy results in sufficiently fast program times, and go from there.