So I’ve been using DFU-UTIL 0.7 for local build binary transfers to the Core… and the ......... progress bar really pisses me off. So I went and looked at the dfu-util repo and there is a much nicer progress bar implemented. I tried to download the source and compile it on my Windows machine… but it’s not completely straight forward, or well documented.
Does anyone have the power of greyskull that can get this done for me and the rest of the 2% of the world that apparently is left in the dust with Windows 8.1? Please and thank you!
So much neater and cleaner than before, worked for me… but i only tried once not sure why there is almost a 1kb difference in the size? maybe there is overheads in the transfer?
dfu-util 0.7-msvc
Copyright 2005-2008 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2012 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to dfu-util@lists.gnumonks.org
Opening DFU capable USB device...
ID 1d50:607f
Run-time device DFU version 011a
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuERROR, status = 10
dfuERROR, clearing status
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
Device returned transfer size 1024
DfuSe interface name: "Internal Flash "
Downloading to address = 0x08005000, size = 106576
Download [=========================] 100% 107520 bytes
Download done.
File downloaded successfully
Transitioning to dfuMANIFEST state
Invalid DFU suffix signature
A valid DFU suffix will be required in a future dfu-util release!!!
RUN SUCCESSFUL (total time: 19s)
D:\Spark>p
PROGRAMMING!!!
dfu-util 0.7-msvc
Copyright 2005-2008 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2012 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to dfu-util@lists.gnumonks.org
Invalid DFU suffix signature
A valid DFU suffix will be required in a future dfu-util release!!!
Opening DFU capable USB device...
ID 1d50:607f
Run-time device DFU version 011a
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuERROR, status = 10
dfuERROR, clearing status
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
Device returned transfer size 1024
DfuSe interface name: "Internal Flash "
Downloading to address = 0x08005000, size = 85740
Download [=========================] 100% 86016 bytes
Download done.
File downloaded successfully
Transitioning to dfuMANIFEST state
D:\Spark>
No error message at the end for me.
I think we can safely ping @zachary on this one… even though he doesn’t use Windows. It would probably be good to get these features on a Mac. Also post up your compiled binary on the Core-Firmware readme.md. It virus scans clean for me…
I just have to ask… HOW did you compile it? I tried setting up a MinGW environment to compile it in to no avail! Kept getting errors that were not solved by typical googling.
Just noticed they have a byte transfer discrepancy:
I compiled it using the msvc project they provided. I first spent a few hours trying on MinGW and Ubuntu - I got it close to compiling - it was failing at linking, looks like it wasn’t bringing in the libusb library. But I was a bit lost with the automake scripts, so moved on to the msvc project.) It really just took a few minutes with the msvc project. There is an external lib to download and build, and then some manual file copying of those built libraries to the right place.
Let’s hope the size issue is a bug in the progress bar!
I'm just using the command line makefile and I don't see any special device ID stuff in there. Actually mine does have the same error yours does, mine is just at the top for some reason.
So I changed my programming script to the following:
@ECHO OFF
ECHO PROGRAMMING!!!
dfu-suffix -d 1d50:607f -a .\core-firmware\build\core-firmware.bin
dfu-util -d 1d50:607f -a 0 -s 0x08005000:leave -D .\core-firmware\build\core-firmware.bin
Now no errors as well!
D:\Spark>p
PROGRAMMING!!!
dfu-suffix (dfu-util) 0.7
(C) 2011-2012 Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to dfu-util@lists.gnumonks.org
No valid DFU suffix signature
New DFU suffix added.
dfu-util 0.7-msvc
Copyright 2005-2008 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2012 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to dfu-util@lists.gnumonks.org
Opening DFU capable USB device...
ID 1d50:607f
Run-time device DFU version 011a
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuERROR, status = 10
dfuERROR, clearing status
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
Device returned transfer size 1024
DfuSe interface name: "Internal Flash "
Downloading to address = 0x08005000, size = 85208
Download [=========================] 100% 86016 bytes
Download done.
File downloaded successfully
Transitioning to dfuMANIFEST state
D:\Spark>
so a bit more playing i’ve found that once you have added the suffix, if you add it again by re-running the batch file it will throw an error too, saying to remove the suffix first. so im thinking ill have to find a way to add it after the build in netbeans, and before i hit run for the dfu-util bit
maybe @seulater could help us as he is the netbeans super guru
I’m also building locally in Netbeans. How did you setup your project - did you use the existing makefile? If that’s the case, then you’ll need to edit the makefile so that it runs dfu-suffix after the .bin file is built, like this:
Under the lines
@echo Building target: $@
@echo Invoking: ARM GCC C++ Linker
$(CPP) $(CFLAGS) $(ALLOBJ) --output $@ $(LDFLAGS)
add
dfu-suffix -d 1d50:607f -a $@
You’ll need to make sure dfu-suffix is in your path.
That’s definitely the better way @mdma but every time I update and pull changes for my local build environment, I’ll have to edit that makefile. So I’ll probably just live with the error if I have to program something more than once without rebuilding the code.
OK so i tried adding it after there with no luck, i think thats making and elf. so i added it here
@BDub Could this be added to the master so it is in there anyway? if dfu-util is in there anyways, then dfu-suffix shouldnt be an issue to add too? if the dfu gets up revved like they say and wont work without the suffix it could be good to have it in there already
# Create a bin file from ELF file
%.bin : %.elf
@echo Invoking: ARM GNU Create Flash Image
$(OBJCOPY) -O binary $< $@
@echo
dfu-suffix -d 1d50:607f -a $@
@echo
@hootie81 - you’re absolutely right - I should have put the command where it produces the bin file…without thinking I assumed that was after linking, but of course it’s not!
Agreed that it would be good to be proactive. It doesn’t seem to break the v0.7 released dfu-util from downloading the BIN either. @zachary and @Dave would need to chime in on this.
Hmm, if you guys are looking to distribute a pre-compiled windows 8.1 binary, it might be better to get in touch with the dfu-util guys here: http://dfu-util.gnumonks.org/ . They probably just need a build machine added to their system for that platform, no?
They obviously don’t believe in releasing new builds on a regular basis, so I don’t think trying to get a Windows 8.1 build machine setup is going to be useful. We just need to stick this one-off 2 year newer dfu-util for Windows users somewhere in the Docs ;-), and I thought you guys might like this progress bar if you use command line DFU mode a lot.
Please and thank you!
