#31 Adding suffix with dfu-suffix makes dfu-util unhappy

[JC]

I have a binary file that I've run through STs 'DFU File Manager (v3.0.5)' tool (DFUFM), and also through dfu-suffix. dfu-prefix reports no prefix on the file created with DFUFM. dfu-suffix reports indentical output, except for the CRC, on both output files. I can use dfu-util to program the file created by DFUFM, but it gets unhappy trying to program the file created with dfu-suffix. The output sizes are also different.

I don't think I'm doing anything incorrectly. Am I seeing an actual issue here?

$ ls -l
-rw-r--r-- 1 xxx xxx 229376 Sep  8 22:00 original.bin
-rw-r--r-- 1 xxx xxx 229685 Sep  8 22:01 dfufm.dfu
-rw-r--r-- 1 xxx xxx 229392 Sep  8 22:01 dfusuffix.dfu

$ dfu-suffix -c dfufm.dfu 
dfu-suffix (dfu-util) 0.9

Copyright 2011-2012 Stefan Schmidt, 2013-2014 Tormod Volden
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

The file dfufm.dfu contains a DFU suffix with the following properties:
BCD device: 0x0000
Product ID: 0xDF11
Vendor ID:  0x0483
BCD DFU:    0x011A
Length:     16
CRC:        0x78B7FC39

$ dfu-suffix -c dfusuffix.dfu 
dfu-suffix (dfu-util) 0.9

Copyright 2011-2012 Stefan Schmidt, 2013-2014 Tormod Volden
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

The file dfusuffix.dfu contains a DFU suffix with the following properties:
BCD device: 0x0000
Product ID: 0xDF11
Vendor ID:  0x0483
BCD DFU:    0x011A
Length:     16
CRC:        0x39D3CB43

$ sudo dfu-util -a -0 -D dfufm.dfu 
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/

Match vendor ID from file: 0483
Match product ID from file: df11
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
DfuSe interface name: "Internal Flash  "
file contains 1 DFU images
parsing DFU image 1
Target name: FloorBoard Controller
image for alternate setting 0, (1 elements, total size = 229384)
parsing element 1, address = 0x08000000, size = 229376
Download    [=========================] 100%       229376 bytes
Download done.
done parsing DfuSe file

$ sudo dfu-util -a -0 -D dfusuffix.dfu 
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/

Match vendor ID from file: 0483
Match product ID from file: df11
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
DfuSe interface name: "Internal Flash  "
dfu-util: No valid DfuSe signature
$

[JC]

I do see that the dfufm.dfu file has a target name, which I don't I'm able to add with either dfu-prefix or dfu-suffix. That would likely explain the difference in length, in part.

The target processor is an STM32F401, if that's of any value.

[Tormod Volden]

The DFU standard only specifies a dfu suffix. The dfu-prefix command implements some proprietary prefices from NXP and TI Stellaris. The DfuSe file format from ST is an entirely different beast. It uses a standard-compliant suffix but the rest is much more complex (multiple segments and targets etc). You can use the dfuse-pack.py tool with DfuSe files.

[JC]

OK. But why doesn't dfu-suffix add a suffix to the binary file that dfu-util can read? That's really the point of the issue. I just mentioned the part about dfu-prefix to cover as many bases as possible in the report.

[Tormod Volden]

A .dfu file usually means a DfuSe file. The "prefix" of a DfuSe file is a header which allows several several binaries to be packed together to one .dfu file. dfu-suffix and dfu-prefix have no support for DfuSe files, and this is not needed since that is what dfuse-pack.py is for.

dfu-suffix can add a standard DFU suffix to your binary file. Since the suffix in a DfuSe file follows the DFU standard (just with another DFU version of 1.1a) it can be read by dfu-suffix. dfu-suffix also lets you put whatever as the DFU version (including 1.1a) but it doesn't do anything special depending on that version.

When dfu-util detects a DFU version of 1.1a it assumes it to be a DfuSe file and not just a plain binary with a DFU suffix. It will abort if it doesn't find the DfuSe signature that is required in DfuSe files.

You can however use dfu-suffix correctly on a plain binary for an STM32 device if you specify a 1.0 or 1.1 DFU version. When can then use this file with dfu-util like any binary file - that means for an STM32 device that you will need to specify the loading address with the -s (--dfuse-address) option.