Dfu-util on linux fails to flash [Solved]

I am trying to flash the latest firmware (in preparation for some tweaks) from a linux machine. I have tried two machines with different versions of Ubuntu (13.10, 12.04) and different USB hardware (2.0,3.0). Both can see the device (as sudo) and can get a backup copy of the firmware from the device, but fail immediately when I try to flash with:
dfu-util: Error during special command “ERASE_PAGE” get_status

I have used the same file & device with a mac laptop and it will flash.

I am using dfu-util from macports on the mac, and 0.7 built from source on the linux boxes.

Is there some magic to make this work on Linux?

Hi @drkemp

BinaryFrost found in another thread that

The Ubuntu repo only contains dfu-util v0.5, so I downloaded, ./confugure’d, and make’d the latest release version (v0.7) from http://dfu-util.gnumonks.org/2

Could you check your dfu-util version?

1 Like

On both the linux boxes and the Mac - I am using 0.7.

As noted in my post - I built 0.7 from source on linux (because apt gave me 0.5).
I also verified that I was actually running 0.7, which is not as obvious as it might seem. The default seems to place dfu-util in both /usr/local/bin and /usr/bin. When you sudo, you can get a different version due to path differences.

Verified with:
dfu-util -V
sudo dfu-util -V

Note that the errors from 0.5 are different. I saw those too.

Hi @drkemp

Sorry I missed that you had built it from sources and had 0.7 already. Reading your post, I thought you meant the OS X version. Sorry!

I don’t have a lot of suggestions other than people have tried chgrp type stuff to make the serial port work without sudo. Maybe @binaryfrost or @Dave or @zachary would have other ideas.

I know the dfu-util guys are just about to release a new version (0.8, woo!), so that might have better success on your box, same building from source rules apply, just clone their repo instead git clone git://gitorious.org/dfu-util/dfu-util.git

Another sanity check thing might be to try switching usb cables, making sure the port isn’t a usb 3.0 port.

Thanks!
David

I’ll try sorting out the permissions so it doesn’t require sudo. I suppose there might be some other odd things going on.
Thanks!

From the comments on the dfu-util list it looks like the code is pretty stable right now and wont change much before 0.8 is released. That being the case, the version I built yesterday (from the git repo) should essentially be 0.8 (even though the build says 0.7).

I tried two different cables and two different machines. One machine has only USB 2.0 hardware and the other has both 2.0 and 3.0 ports. I tried 'em all.

I have seen other posts where users seem to be having success with dfu-util 0.7, so I assume it CAN work. The farthest I ever got was 3% before it throws an error. Usually it still reads 0.

It worked first try when I sent the file from the Mac (OSX 10.9), so I know its not the Spark Core.

Hmm, can you paste the full command you’re running plus a verbose flag -v, and the full output?

Thanks,
David

sudo dfu-util/src/dfu-util -d 1d50:607f -a 0 -s 0x08005000 -D core-firmware.bin
dfu-util 0.7

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

dfu-util: Invalid DFU suffix signature
dfu-util: 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 = 55670
Download [ ] 0% 0 bytesdfu-util: Error during special command “ERASE_PAGE” get_status

sorry - missed the -v

sudo dfu-util/src/dfu-util -v -d 1d50:607f -a 0 -s 0x08005000 -D core-firmware.bin
dfu-util 0.7

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

dfu-util: Invalid DFU suffix signature
dfu-util: 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 = dfuDNLOAD-IDLE, status = 0
aborting previous incomplete transfer
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 "
Memory segment at 0x08000000 20 x 1024 = 20480 ®
Memory segment at 0x08005000 108 x 1024 = 110592 (rew)
Downloading to address = 0x08005000, size = 55670
Download [ ] 0% 0 bytes Poll timeout 5 ms
Poll timeout 5 ms
Download from image offset 00000000 to memory 08005000-080053ff, size 1024
Poll timeout 5 ms
Poll timeout 5 ms
dfu-util: Error during download get_status

Well that’s interesting. When I run dfu-util with -v under OS X, I get a bunch of Poll timeout 50 ms (not 5 ms), two per 1024 byte block in fact, but it continues on and succeeds.

dfu-util -v -d 1d50:607f -a 0 -s 0x08005000:leave -D core-firmware.bin
dfu-util 0.7

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

Filter on vendor = 0x1d50 product = 0x607f
Opening DFU capable USB device... ID 1d50:607f
Run-time device DFU version 011a
Found DFU: [1d50:607f] devnum=0, cfg=1, intf=0, alt=0, name="@Internal Flash  /0x08000000/20*001Ka,108*001Kg"
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
No valid DFU suffix signature
Warning: File has no DFU suffix
DfuSe interface name: "Internal Flash  "
Memory segment at 0x08000000  20 x 1024 = 20480 (r)
Memory segment at 0x08005000 108 x 1024 = 110592 (rew)
Downloading to address = 0x08005000, size = 72628
   Poll timeout 50 ms
 Download from image offset 00000000 to memory 08005000-080053ff, size 1024
   Poll timeout 50 ms
   Poll timeout 50 ms
 Download from image offset 00000400 to memory 08005400-080057ff, size 1024
   Poll timeout 50 ms
   Poll timeout 50 ms
 Download from image offset 00000800 to memory 08005800-08005bff, size 1024
   Poll timeout 50 ms
   Poll timeout 50 ms
...

I wonder why it is 50ms for me and 5ms for you? Could be a clue maybe?

Hi again,

I just read that you can add more -v to the commands to get USB logging, so

dfu-util -v -v -d 1d50:607f -a 0 -s 0x08005000:leave -D core-firmware.bin

produces a bunch more output. Might help you!

Hmm. That might be the clutch, had you tried it previously with 0.7, and not the 0.8 build?

I noticed the new dfu-util is much faster, and I wonder if that isn’t from some change of timeouts from 50ms to 5ms. I’ve noticed during manufacturing that dfu performance can vary from core to core, and based on which version of firmware you have on your core. Any chance (if you haven’t already), you can try the older 0.7 version of dfu-util?

edit: in your original posts, you said it worked on the mac I am using dfu-util from macports on the mac, and 0.7 built from source on the linux boxes. – but it hadn’t worked on linux, so I wonder if that source build is the issue.

This is good for us to know now if it is a problem, so we can communicate with the dfu-util guys.

Thanks,
David

Interesting bit…
In Feb 2014 there was a patch to set the default timeout to 5ms under some circumstances. The 0.7 version is much older than that, so I would have that change and the official 0.7 wont.

I cant check it right now, but tonight I will look into moving the DEFAULT_POLLTIMEOUT to 50 and see what that does.

from the git log on dfu-util…
Date: Sat Feb 15 11:46:39 2014 +0100

Apply bwPollTimout quirk inside dfu_get_status()

Instead of all places where dfu_get_status() gets called.

And wait for the bwPollTimout after every status request
also on the devices for which the quirk applies (that is,
the quirk default value of 5 ms) instead of skipping it.
2 Likes

I did a git checkout v0.7 and tried to build and just got a boatload of errors.
So I changed src/quirks.h from
#define DEFAULT_POLLTIMEOUT 5
to
#define DEFAULT_POLLTIMEOUT 50

built again and it works like a charm!

4 Likes

Very interesting, thank you! – Pinging @zachary and @satishgn since this may have bootloader implications, thoughts?

I just upgraded to ubuntu 14.04 and was running into this exact problem. @drkemp’s patch worked for me! Thanks so much!

1 Like

@drkemp & @Hypnopompia: git blame on dfu-util/src/quirks.h shows that the DEFAULT_POLLTIMEOUT hasn’t changed since 2010. I’d be curious to know if intermediate values work. 10? 20? 30?

1 Like

I just gave Tormod a heads-up about this thread. He’ll probably have some insight into whether this is more a problem with dfu-util or more something we could improve in the bootloader.

I don’t have a core with me at work today, but I’ll definitely try some other values when I get home tonight.