Activity for Hendry Kaak
-
Hendry Kaak created ticket #107
Dfu-util user feedback optimisation
-
I have now pushed the changes to git. One way to test it out is to pack a DfuSe file from multiple binary files with several alternate interfaces, and for the non-flash targets, use a RAM address (one that doesn't clash with bootloader operation!): ./dfuse-pack.py \ -b 0x08001000@0:/tmp/at4k.bin \ -b 0x08002000@0:/tmp/at8k2k.bin \ -b 0x20004000@1:/tmp/at4k.bin \ -b 0x20004400@2:/tmp/at4k.bin \ -b 0x20004800@2:/tmp/at4k.bin \ ../testalt.dfu The resulting DfuSe file can be verified with: ./dfuse-pack.py...
-
Console output of the download that went well.
-
@tormod I did a couple of tests with the dfuse-pack.py script and it seems to work well if the alternateSetting is set with '@x'. The only con I saw when using this option is that people can still unknowingly enter 2 or more different '@x' parameters and depending on the sequence of the build parameters it will always pick the last alternateSetting in the command line as the alternateSetting for the whole target suffix (without warning the user). If this is the case, it should probably create a new...
-
I'll see what I can do. Perhaps I can write a few optional bytes for now to verify if dfu-util works with multiple images.
-
Nice! That's some quick progress. This makes testing a lot easier, thanks.
-
I'll see what I can do. Perhaps I can write a few optional bytes for now to very if dfu-util works with multiple images.
-
Nice, that seems to be working well already! The only log output to mention is probably this memory leakage at the end of the upload log, but the upload process seems to be working correct with a single image indeed. libusb: debug [libusb_close] libusb: debug [libusb_exit] libusb: debug [libusb_exit] destroying default context libusb: warning [libusb_exit] some libusb_devices were leaked
-
Nice, that seems to be working quite already! The only log output to mention is probably this memory leakage at the end of the upload log, but the upload process seems to be working correct with a single image indeed. libusb: debug [libusb_close] libusb: debug [libusb_exit] libusb: debug [libusb_exit] destroying default context libusb: warning [libusb_exit] some libusb_devices were leaked
-
Yes, that was my mistake, sorry for the misconception. Here I used the dfu-util in my environment path by accident (which is the default dfu-util v0.9) without the patch applied. That one returned the "More than one DFU capable USB device found! Try `--list`' and specify the serial number or disconnect all but one device" message. But in this case it actually should've given a message saying that I should specify an altSetting with '-a', because more than one alternate setting options are found in...
-
It's a custom PCB with a stm32F4 MCU and native USB where I'm working on :-) People should be able to flash the firmware over USB and those files should match the board. DfuSe files have the VID/PID information (and more to verify) in the file to match the device with, which is the reason for using DfuSe files. Here I printed the information from on top in the while loop in 'dfuse_multiple_alt()' as requested (the method returns 1/true when finished): dif=0x800065010 dev=0x8000658b0; dif->dev=0x8000658b0...
-
Hello again, I was quite busy yesterday so I couldn't really check what was going on (and I'm still not really sure where the problem is). I'm able to download a Dfuse file to my device with the '-a 0' option in the commandline, but when I remove the alternate setting from commandline it seems to breaks. I think the last piece of the verbose log shows the most important information, like so: Determining device status: libusb: debug [libusb_alloc_transfer] transfer 0x8000650f0 libusb: debug [libusb_submit_transfer]...
-
Hello, @tormod I build dfu-util with your patch applied. But it doesn't seem to do the trick. Dfu-util shows the message: "More than one DFU capable USB device found! Try --list' and specify the serial number or disconnect all but one device", even though the command was as following (with serial number specified): dfu-util -s :leave -S "307637963237" -D file.DfuSe :-)
-
Interface nr. is alternate setting nr. btw, I mixed them up.
-
@tormod Thanks for merging :-) Yeah that would be nice indeed. What would also be nice when using Dfu-util is that, when using a DfuSe file as input Dfu-util is not smart enough to check in the DfuSe file which interface it should download the binary images to. If dfu-util sees multiple interface ID's (seeable with the list option -l) enumerated from a device, you still need to specify the interface number with the alt option(-a). But this information is readily available in the DfuSe file in the...
-
The merge request can be found here (also for reference): https://sourceforge.net/p/dfu-util/dfu-util/merge-requests/11/
-
No problem, also thanks for the quick responses ;-)
-
Here is the script output file without an flash target file in it for reference.
-
Fix "DFUImageSize" field in the DFU prefix
-
dfuse-pack.py: Introduce 'PREFIX_SIZE' and 'SUFFIX_SIZE'
-
dfuse-pack.py: Fix "DFUImageSize" field in the DFU prefix
-
Ok yes, I've never worked with sourceforge before, but let me see what I can do :-)
-
Just to be sure, the 'DFUImageSize' I was talking about are bytes 6-9 in the Prefix of a DfuSe-file.
-
Bug in dfuse-pack.py?
1