Usage of old Version of DFU-Tool #117

Closed
Detmud opened this Issue Jun 23, 2014 · 15 comments

Comments

Projects
None yet
10 participants
@Detmud

Detmud commented Jun 23, 2014

Hello,
you are using a older version of the DFU-Tool.
You can see here https://github.com/mossmann/hackrf/blob/master/firmware/common/Makefile_inc.mk#L13 that you're using the option -s.

As you may see in the official Repo, this option ist not used any more (2014) https://gitorious.org/dfu-util/dfu-util/source/fc81c6cc4eba30eaadf0010deb3d38f3be93ecd1:src/suffix.c#L52

So I tried to find a version with this option.
It seems like you are using an older (2012) version https://github.com/Stefan-Schmidt/dfu-util ... with this version all your scripts and manuals are working quite fine. The problem is that this version isn't developed anymore.

Both versions are version 0.7 so this problem gets even worse.
A clarification would be very nice.

@xyrtek

This comment has been minimized.

Show comment
Hide comment
@xyrtek

xyrtek Jun 23, 2014

Hi,
I ran into some issues with this yesterday
Use this workaround if you need to use DFU with the latest version (0.7 as mentioned above).
Compile a new dfu file, do not use the one in the latest release package(hackrf-2014.04.1)
Windows only!!!
dfu-util -D file_name.dfu
boot into Linux and proceed to download the firmware to the LPC MCU.
Tested in Win 7 64Bits, Dual boot to Ubuntu 14.04 64Bits
http://dfu-util.gnumonks.org/

xyrtek commented Jun 23, 2014

Hi,
I ran into some issues with this yesterday
Use this workaround if you need to use DFU with the latest version (0.7 as mentioned above).
Compile a new dfu file, do not use the one in the latest release package(hackrf-2014.04.1)
Windows only!!!
dfu-util -D file_name.dfu
boot into Linux and proceed to download the firmware to the LPC MCU.
Tested in Win 7 64Bits, Dual boot to Ubuntu 14.04 64Bits
http://dfu-util.gnumonks.org/

@Detmud

This comment has been minimized.

Show comment
Hide comment
@Detmud

Detmud Jun 24, 2014

@xyrtek Don't get me wrong i solved this Problem, but its not Document.
A Better and clearer Documentation would be desirable.

Detmud commented Jun 24, 2014

@xyrtek Don't get me wrong i solved this Problem, but its not Document.
A Better and clearer Documentation would be desirable.

@mossmann mossmann added the bug label Aug 21, 2014

@mossmann

This comment has been minimized.

Show comment
Hide comment
@mossmann

mossmann Aug 22, 2014

Owner

According to http://dfu-util.gnumonks.org/, the 0.7 version I'm using (md5sum 56844020177d4db4c1ea2e926fe9d588) is the current release. Compatibility with the dfu-util git repo may be broken, but I'm not inclined to call that a bug until there is a new dfu-util release.

Owner

mossmann commented Aug 22, 2014

According to http://dfu-util.gnumonks.org/, the 0.7 version I'm using (md5sum 56844020177d4db4c1ea2e926fe9d588) is the current release. Compatibility with the dfu-util git repo may be broken, but I'm not inclined to call that a bug until there is a new dfu-util release.

@Xykon

This comment has been minimized.

Show comment
Hide comment
@Xykon

Xykon Nov 12, 2014

Can you upload the correct dfu-util sources on github? The http://dfu-util.gnumonks.org site has been dead for a while and I can only find versions 0.5 and 0.8 on the internet.

Xykon commented Nov 12, 2014

Can you upload the correct dfu-util sources on github? The http://dfu-util.gnumonks.org site has been dead for a while and I can only find versions 0.5 and 0.8 on the internet.

@Xykon

This comment has been minimized.

Show comment
Hide comment
@Xykon

Xykon Nov 18, 2014

Does anyone know where to get the correct dfu-util version sources?

Xykon commented Nov 18, 2014

Does anyone know where to get the correct dfu-util version sources?

@russm

This comment has been minimized.

Show comment
Hide comment
@russm

russm Dec 21, 2014

dfu-util 0.8 has broken the -s (aka --stellaris-address) option out of dfu-suffix to a new executable, dfu-prefix. My read of the docs is that the correct fix for the hackrf build should be

diff --git a/firmware/hackrf-common.cmake b/firmware/hackrf-common.cmake
index df5d5c9..c43484c 100644
--- a/firmware/hackrf-common.cmake
+++ b/firmware/hackrf-common.cmake
@@ -164,7 +164,8 @@ macro(DeclareTargets)
        DEPENDS ${PROJECT_NAME}.bin
        COMMAND rm -f _tmp.dfu _header.bin
        COMMAND cp ${PROJECT_NAME}.bin _tmp.dfu
-       COMMAND dfu-suffix --vid=0x1fc9 --pid=0x000c --did=0x0 -s 0 -a _tmp.dfu
+       COMMAND dfu-suffix --vid=0x1fc9 --pid=0x000c --did=0x0 -a _tmp.dfu
+       COMMAND dfu-prefix -s 0 -a _tmp.dfu
        COMMAND python -c \"import os.path\; import struct\; print\('0000000: da ff ' + ' '.join\(map\(lambda s: '%02x' % ord\(s\), struct.pack\('<H', os.path.getsize\('${PROJECT_NAME}.bin'\) / 512 + 1\)\)\) + ' ff ff ff ff'\)\" | xxd -g1 -r > _header.bin
        COMMAND cat _header.bin _tmp.dfu >${PROJECT_NAME}.dfu
        COMMAND rm -f _tmp.dfu _header.bin

bit that leaves dfu-util complaining

dfu-util: DFU suffix CRC does not match
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!

russm commented Dec 21, 2014

dfu-util 0.8 has broken the -s (aka --stellaris-address) option out of dfu-suffix to a new executable, dfu-prefix. My read of the docs is that the correct fix for the hackrf build should be

diff --git a/firmware/hackrf-common.cmake b/firmware/hackrf-common.cmake
index df5d5c9..c43484c 100644
--- a/firmware/hackrf-common.cmake
+++ b/firmware/hackrf-common.cmake
@@ -164,7 +164,8 @@ macro(DeclareTargets)
        DEPENDS ${PROJECT_NAME}.bin
        COMMAND rm -f _tmp.dfu _header.bin
        COMMAND cp ${PROJECT_NAME}.bin _tmp.dfu
-       COMMAND dfu-suffix --vid=0x1fc9 --pid=0x000c --did=0x0 -s 0 -a _tmp.dfu
+       COMMAND dfu-suffix --vid=0x1fc9 --pid=0x000c --did=0x0 -a _tmp.dfu
+       COMMAND dfu-prefix -s 0 -a _tmp.dfu
        COMMAND python -c \"import os.path\; import struct\; print\('0000000: da ff ' + ' '.join\(map\(lambda s: '%02x' % ord\(s\), struct.pack\('<H', os.path.getsize\('${PROJECT_NAME}.bin'\) / 512 + 1\)\)\) + ' ff ff ff ff'\)\" | xxd -g1 -r > _header.bin
        COMMAND cat _header.bin _tmp.dfu >${PROJECT_NAME}.dfu
        COMMAND rm -f _tmp.dfu _header.bin

bit that leaves dfu-util complaining

dfu-util: DFU suffix CRC does not match
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
@hessu

This comment has been minimized.

Show comment
Hide comment
@hessu

hessu Feb 23, 2015

Contributor

To get hackrf firmware compiled, I cloned dfu-util sources from gitorious, then checked out the v0.7 tag, and compiled & installed from there. libusb-1.0 is required for building it.

sudo apt-get install libusb-1.0-dev
git clone https://gitorious.org/dfu-util/dfu-util.git
cd dfu-util
git checkout -b v0.7 v0.7
sh autogen.sh 
make
sudo make install
Contributor

hessu commented Feb 23, 2015

To get hackrf firmware compiled, I cloned dfu-util sources from gitorious, then checked out the v0.7 tag, and compiled & installed from there. libusb-1.0 is required for building it.

sudo apt-get install libusb-1.0-dev
git clone https://gitorious.org/dfu-util/dfu-util.git
cd dfu-util
git checkout -b v0.7 v0.7
sh autogen.sh 
make
sudo make install
@felipebalbi

This comment has been minimized.

Show comment
Hide comment
@felipebalbi

felipebalbi Mar 11, 2015

I have this issue with dfu-util from debian sid (0.8)

The patch posted above by russm fixes it, but I guess we need to find a way to support older versions too ?

Update: It doesn't really fix it. I can compile a firmware but the resulting firmware, after loading to RAM (or flashing to device) makes hackrf non-functional at least with XHCI hosts.

I have this issue with dfu-util from debian sid (0.8)

The patch posted above by russm fixes it, but I guess we need to find a way to support older versions too ?

Update: It doesn't really fix it. I can compile a firmware but the resulting firmware, after loading to RAM (or flashing to device) makes hackrf non-functional at least with XHCI hosts.

@liubenyuan

This comment has been minimized.

Show comment
Hide comment
@liubenyuan

liubenyuan Jun 19, 2015

OIC, maybe only dfu-util 0.7 works with hackrf one.

OIC, maybe only dfu-util 0.7 works with hackrf one.

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Jul 15, 2015

The source code for dfu-util has moved to sourceforge and the release branches are not listed any more but the following works if you need 0.7:
git clone git://git.code.sf.net/p/dfu-util/dfu-util
cd dfu-util
git log --grep "Release 0.7"
git checkout 4e312c5567a84f76654295c267ec35f71727fe5a
sh autogen.sh
./configure
make
sudo make install

But the cmake change by russm above is probably better.to use.

ghost commented Jul 15, 2015

The source code for dfu-util has moved to sourceforge and the release branches are not listed any more but the following works if you need 0.7:
git clone git://git.code.sf.net/p/dfu-util/dfu-util
cd dfu-util
git log --grep "Release 0.7"
git checkout 4e312c5567a84f76654295c267ec35f71727fe5a
sh autogen.sh
./configure
make
sudo make install

But the cmake change by russm above is probably better.to use.

@stiege

This comment has been minimized.

Show comment
Hide comment
@stiege

stiege Oct 17, 2015

I've completed itsbert's instructions but I'm still getting CRC warnings and a bricked device:

stiege@spyro:~/projects/hackrf/firmware/build/hackrf_usb$ dfu-util -D hackrf_usb.dfu
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

Opening DFU capable USB device... ID 1fc9:000c
Run-time device DFU version 0100
Claiming USB DFU Runtime Interface...
Determining device status: state = dfuIDLE, status = 0
WARNING: Runtime device already in DFU state ?!?
Found Runtime: [1fc9:000c] devnum=0, cfg=1, intf=0, alt=0, name="DFU"
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 0100
Device returned transfer size 2048
DFU CRC does not match
Warning: File has no DFU suffix
bytes_per_hash=409
Copying data from PC to DFU device
Starting download: [##################################################] finished

stiege commented Oct 17, 2015

I've completed itsbert's instructions but I'm still getting CRC warnings and a bricked device:

stiege@spyro:~/projects/hackrf/firmware/build/hackrf_usb$ dfu-util -D hackrf_usb.dfu
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

Opening DFU capable USB device... ID 1fc9:000c
Run-time device DFU version 0100
Claiming USB DFU Runtime Interface...
Determining device status: state = dfuIDLE, status = 0
WARNING: Runtime device already in DFU state ?!?
Found Runtime: [1fc9:000c] devnum=0, cfg=1, intf=0, alt=0, name="DFU"
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 0100
Device returned transfer size 2048
DFU CRC does not match
Warning: File has no DFU suffix
bytes_per_hash=409
Copying data from PC to DFU device
Starting download: [##################################################] finished
@dominicgs

This comment has been minimized.

Show comment
Hide comment
@dominicgs

dominicgs Oct 17, 2015

Collaborator

Could you post the output from the firmware build? That output suggests that the DFU file is missing a suffix, which implies that the build did not work correctly.

Collaborator

dominicgs commented Oct 17, 2015

Could you post the output from the firmware build? That output suggests that the DFU file is missing a suffix, which implies that the build did not work correctly.

@stiege

This comment has been minimized.

Show comment
Hide comment
@stiege

stiege Oct 17, 2015

stiege@spyro:~/projects/hackrf/firmware/build/hackrf_usb$ make all
[  7%] Built target hackrf_usb_m0.elf
[  7%] Built target hackrf_usb_m0.bin
[100%] Built target hackrf_usb.elf
[100%] Built target hackrf_usb.bin
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
Not valid TI Stellaris DFU prefix
TI Stellaris DFU prefix added.
New DFU suffix added.
[100%] Built target hackrf_usb.dfu

So I assume that we're getting a non-match warning as we calculate the CRC based on the _tmp.dfu file, then we go and catenate a header with it:

        COMMAND cp ${PROJECT_NAME}.bin _tmp.dfu
        COMMAND dfu-suffix --vid=0x1fc9 --pid=0x000c --did=0x0 -s 0 -a _tmp.dfu
        COMMAND python -c \"import os.path\; import struct\; print\('0000000: da ff ' + ' '.join\(map\(lambda s: '%02x' % ord\(s\), struct.pack\('<H', os.path.getsize\('${PROJECT_NAME}.bin'\) / 512 + 1\)\)\) + ' ff ff ff ff'\)\" | xxd -g1 -r > _header.bin
        COMMAND cat _header.bin _tmp.dfu >${PROJECT_NAME}.dfu
        COMMAND rm -f _tmp.dfu _header.bin

I assume this is by design though as if I "fix" it, I can remove the warnings but the transfer fails with:

Copying data from PC to DFU device
Starting download: [dfu_download: libusb_control_transfer returned -1
Error during download

My "fix" seems to correct the suffix warning as well:

stiege@spyro:~/projects/hackrf/firmware/build$ dfu-suffix -c hackrf_usb/hackrf_usb.dfu
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

DFU CRC does not match

to

stiege@spyro:~/projects/hackrf/firmware/build$ dfu-suffix -c hackrf_usb/hackrf_usb.dfu
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

Dfu suffix version 100
The file hackrf_usb/hackrf_usb.dfu contains a DFU suffix with the following properties:
BCD device: 0x0000
Product ID: 0x000C
Vendor ID:  0x1FC9
BCD DFU:    0x0100
Length:     16
CRC:        0xF8D7797D

So since we modify the dfu after we calculate a suffix/prefix for it, I'm unsure why everyone else doesn't get the warning?

My obviously wrong fix (don't use):

diff --git a/firmware/hackrf-common.cmake b/firmware/hackrf-common.cmake
index df5d5c9..4cc7dc9 100644
--- a/firmware/hackrf-common.cmake
+++ b/firmware/hackrf-common.cmake
@@ -164,9 +164,9 @@ macro(DeclareTargets)
                DEPENDS ${PROJECT_NAME}.bin
                COMMAND rm -f _tmp.dfu _header.bin
                COMMAND cp ${PROJECT_NAME}.bin _tmp.dfu
-               COMMAND dfu-suffix --vid=0x1fc9 --pid=0x000c --did=0x0 -s 0 -a _tmp.dfu
                COMMAND python -c \"import os.path\; import struct\; print\('0000000: da ff ' + ' '.join\(map\(lambda s: '%02x' % ord\(s\), struct.pack\('<H', os.path.getsize\('${PROJECT_NAME}.bin'\) / 512 + 1\)\)\) + ' ff ff ff ff'\)\" | xxd -g1 -r > _header.bin
                COMMAND cat _header.bin _tmp.dfu >${PROJECT_NAME}.dfu
+               COMMAND dfu-suffix --vid=0x1fc9 --pid=0x000c --did=0x0 -s 0 -a ${PROJECT_NAME}.dfu
                COMMAND rm -f _tmp.dfu _header.bin
        )

stiege commented Oct 17, 2015

stiege@spyro:~/projects/hackrf/firmware/build/hackrf_usb$ make all
[  7%] Built target hackrf_usb_m0.elf
[  7%] Built target hackrf_usb_m0.bin
[100%] Built target hackrf_usb.elf
[100%] Built target hackrf_usb.bin
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
Not valid TI Stellaris DFU prefix
TI Stellaris DFU prefix added.
New DFU suffix added.
[100%] Built target hackrf_usb.dfu

So I assume that we're getting a non-match warning as we calculate the CRC based on the _tmp.dfu file, then we go and catenate a header with it:

        COMMAND cp ${PROJECT_NAME}.bin _tmp.dfu
        COMMAND dfu-suffix --vid=0x1fc9 --pid=0x000c --did=0x0 -s 0 -a _tmp.dfu
        COMMAND python -c \"import os.path\; import struct\; print\('0000000: da ff ' + ' '.join\(map\(lambda s: '%02x' % ord\(s\), struct.pack\('<H', os.path.getsize\('${PROJECT_NAME}.bin'\) / 512 + 1\)\)\) + ' ff ff ff ff'\)\" | xxd -g1 -r > _header.bin
        COMMAND cat _header.bin _tmp.dfu >${PROJECT_NAME}.dfu
        COMMAND rm -f _tmp.dfu _header.bin

I assume this is by design though as if I "fix" it, I can remove the warnings but the transfer fails with:

Copying data from PC to DFU device
Starting download: [dfu_download: libusb_control_transfer returned -1
Error during download

My "fix" seems to correct the suffix warning as well:

stiege@spyro:~/projects/hackrf/firmware/build$ dfu-suffix -c hackrf_usb/hackrf_usb.dfu
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

DFU CRC does not match

to

stiege@spyro:~/projects/hackrf/firmware/build$ dfu-suffix -c hackrf_usb/hackrf_usb.dfu
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

Dfu suffix version 100
The file hackrf_usb/hackrf_usb.dfu contains a DFU suffix with the following properties:
BCD device: 0x0000
Product ID: 0x000C
Vendor ID:  0x1FC9
BCD DFU:    0x0100
Length:     16
CRC:        0xF8D7797D

So since we modify the dfu after we calculate a suffix/prefix for it, I'm unsure why everyone else doesn't get the warning?

My obviously wrong fix (don't use):

diff --git a/firmware/hackrf-common.cmake b/firmware/hackrf-common.cmake
index df5d5c9..4cc7dc9 100644
--- a/firmware/hackrf-common.cmake
+++ b/firmware/hackrf-common.cmake
@@ -164,9 +164,9 @@ macro(DeclareTargets)
                DEPENDS ${PROJECT_NAME}.bin
                COMMAND rm -f _tmp.dfu _header.bin
                COMMAND cp ${PROJECT_NAME}.bin _tmp.dfu
-               COMMAND dfu-suffix --vid=0x1fc9 --pid=0x000c --did=0x0 -s 0 -a _tmp.dfu
                COMMAND python -c \"import os.path\; import struct\; print\('0000000: da ff ' + ' '.join\(map\(lambda s: '%02x' % ord\(s\), struct.pack\('<H', os.path.getsize\('${PROJECT_NAME}.bin'\) / 512 + 1\)\)\) + ' ff ff ff ff'\)\" | xxd -g1 -r > _header.bin
                COMMAND cat _header.bin _tmp.dfu >${PROJECT_NAME}.dfu
+               COMMAND dfu-suffix --vid=0x1fc9 --pid=0x000c --did=0x0 -s 0 -a ${PROJECT_NAME}.dfu
                COMMAND rm -f _tmp.dfu _header.bin
        )
@stiege

This comment has been minimized.

Show comment
Hide comment
@stiege

stiege Oct 18, 2015

I used the dfu in the release from the hackrf website to unbrick my device. Good enough fix for me...

stiege commented Oct 18, 2015

I used the dfu in the release from the hackrf website to unbrick my device. Good enough fix for me...

@dominicgs

This comment has been minimized.

Show comment
Hide comment
@dominicgs

dominicgs Jan 14, 2016

Collaborator

As PR #229 has now been merged, we are able to build .dfu files using either dfu-util 0.7 or 0.8+. Anything less than 0.7 will require an upgrade, but most distros are now shipping one of these two releases.

Collaborator

dominicgs commented Jan 14, 2016

As PR #229 has now been merged, we are able to build .dfu files using either dfu-util 0.7 or 0.8+. Anything less than 0.7 will require an upgrade, but most distros are now shipping one of these two releases.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment