dfu-util : can't detach, device does not revert to application code after reflash
fenugrec opened this issue · 10 comments
Quite annoying. Tried with and without -R, tried a fix suggested at https://community.st.com/s/question/0D50X00009XkhcT/application-fails-to-start-after-dfu-leave (forcing a reset of the USB peripheral), no success : device still boots right back into DFU mode.
dfu-util 0.9
Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/
Opening DFU capable USB device...
ID 0483:df11
Run-time device DFU version 011a
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
Device returned transfer size 2048
dfu-util: can't detach
$ dfu-util -l
Found Runtime: [1d50:606f] ver=0000, devnum=105, cfg=1, intf=1, path="1-3", alt=0, name="cannette firmware upgrade interface", serial="003800254250431420363230"
Found DFU: [0483:df11] ver=2200, devnum=12, cfg=1, intf=0, path="5-1", alt=1, name="@Option Bytes /0x1FFFF800/01*016 e", serial="FFFFFFFEFFFF"
Found DFU: [0483:df11] ver=2200, devnum=12, cfg=1, intf=0, path="5-1", alt=0, name="@Internal Flash /0x08000000/032*0001Kg", serial="FFFFFFFEFFFF"
workaround : needs dfu-util 0.10 which adds a ":leave" command . This is bleeding edge so I don't think we want to modify the dfu-util command before a few weeks / months.
e.g.
$ dfu-util -S "002A002A4250431420363230", -a 0 -s 0x08000000:leave
(-a 0 needed because in DFU mode, there are two altinterfaces. first serialno is the "normal" (gs_usb) serial)
See:
"DfuSe: Allow special commands without download file" (:leave command)
https://sourceforge.net/p/dfu-util/dfu-util/ci/87df198c72d7ed6dea4b11a67ab1a447c485a305/
https://sourceforge.net/p/dfu-util/tickets/99/
This is following a download, so there have been SET_ADDRESS requests, but the last one probably pointing to the start of the last sector being written. I guess this is the problem. So if the LEAVE request makes it jump to this address, it causes a crash or overrun and it restarts from 0x00000000, still being remapped to ROM (bootloader) if the boot pins are configured that way.
Not sure what debian/ubuntu are waiting for. As of 2022/01, http://dfu-util.sourceforge.net/ is on release 0.11, but I'm still seeing 0.9 on
https://packages.ubuntu.com/jammy/dfu-util
https://packages.debian.org/stable/dfu-util
A few more months maybe...
Debian has a bug report for this: "dfu-util: Release very old"
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=952905
But that bug report is old itself :(
According to https://tracker.debian.org/pkg/dfu-util , 0.11 is starting to "trickle down" into distros. It's in "testing" now...
@fenugrec does this firmware support IAP ?
Your first post with dfu-util -l shows the all three interfaces
Found Runtime: [1d50:606f] ver=0000, devnum=105, cfg=1, intf=1, path="1-3", alt=0, name="cannette firmware upgrade interface", serial="003800254250431420363230"
Found DFU: [0483:df11] ver=2200, devnum=12, cfg=1, intf=0, path="5-1", alt=1, name="@option Bytes /0x1FFFF800/01016 e", serial="FFFFFFFEFFFF"
Found DFU: [0483:df11] ver=2200, devnum=12, cfg=1, intf=0, path="5-1", alt=0, name="@internal Flash /0x08000000/0320001Kg", serial="FFFFFFFEFFFF"
After I flash my device with canette firmware I could not get the [0483:df11] and [1d50:606f] to show up at the same time.
If I start in bootloader mode I can see 0483 otherwise 1d50.
Am on windows machine BTW. Would that be the isssue?
@fenugrec does this firmware support IAP ?
I'm not sure what that means, sorry.
After I flash my device with canette firmware I could not get the [0483:df11] and [1d50:606f] to show up at the same time. If I start in bootloader mode I can see 0483 otherwise 1d50.
Ah yes, in my paste if you notice the different path="1-3" and path="5-1, I actually had 2 devices connected at the same time - one in normal mode, the other one rebooted in DFU mode !
Note, it's very unlikely that you have cannette hardware; it's a variant I was planning to build and release/sell but then massive STM shortage started so the project is on hold. I haven't released schematics since it's currently almost impossible to build more.
@fenugrec I had my suspicions on two different devices theory, thanks for clarifying that.
I am in process of building a very small batch of gs_usb board variant.
That said I would request some assistance on my windows-os related query. I am having driver issues on windows.
I tried using native winusb driver and that wont work without admin privilege, and if use libusbk driver I cant use the "firmware upgrade interface" at all.
I am able to switch to DFU mode on ubuntu with native driver without shorting bootloader pin, is this something windows-os cant/wont support?
Not sure if this is library/driver issue or is a dfu-util on windows limitation? If you can point me the direction, I can investigate more.
That said I would request some assistance on my windows-os related query.
Please open a new ticket. I'm leaving this one open for this specific issue related to recent dfu-util updates.
After some quite deeper digging, I figured I had a newer driver and old dfu-util.
Upgraded to dfu-util V0.11, all good now.
Thanks everyone