2017-11-27 21:19:49 +00:00

136 lines
5.5 KiB
HTML

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en-US">
<head>
<title>DfuSe and dfu-util</title>
<meta http-equiv="content-type" content="application/xhtml+xml; charset=iso-8859-1" />
<meta name="author" content="Tormod Volden" />
<meta name="keywords" content="dfu-util, DfuSe, ST DFU extensions" />
<meta name="description" content="How to use dfu-util with DfuSe devices" />
<link rel="icon" type="image/png" href="favicon.ico" />
<link rel="stylesheet" type="text/css" href="simple.css" media="screen, print" />
</head>
<body>
<div id="middlebox">
<h1>Using dfu-util with DfuSe devices</h1>
<h2>DfuSe</h2>
<p>
DfuSe (DFU with ST Microsystems extensions) is a protocol based on
DFU 1.1. However, in expanding the functionality of the DFU protocol,
ST Microsystems broke all compatibility with the DFU 1.1 standard.
DfuSe devices report the DFU version as "1.1a".
</p>
<p>
DfuSe can be used to download firmware and other data
from a host computer to a conforming device (or upload in the
opposite direction) over USB similar to standard DFU.
</p>
<p>
The main difference from standard DFU is that the target address in
the device (flash) memory is specified by the host, so that a
download can be performed to parts of the device memory. The host
program is also responsible for erasing flash pages before they
are written to.
</p>
<h2>.dfu files</h2>
<p>
A special file format is defined by ST Microsystems to carry firmware
for DfuSe devices. The file contains target information such as address
and alternate interface information in addition to the binary data.
Several blocks of binary data can be combined in one .dfu file.
</p>
<h2>Alternate interfaces</h2>
<p>
Different memory locations of the device may have different
characteristics that the host program (dfu-util) has to take
into considerations, such as flash memory page size, read-only
versus read-write segments, the need to erase, and so on.
These parameters are reported by the device in the string
descriptors meant for describing the USB interfaces.
The host program decodes these strings to build a memory map of
the device. Different memory units or address spaces are listed
in separate alternate interface settings that must be selected
according to the memory unit to access.
</p>
<p>
Note that dfu-util leaves it to the user to select alternate
interface. When parsing a .dfu file it will skip file segments
not matching the selected alternate interface. Also, some
DfuSe device firmware implementations ignore the setting of
alternate interface and deduct the memory unit from the
address, since they have no address space overlap.
</p>
<h2>DfuSe special commands</h2>
<p>
DfuSe special commands are used by the host program during normal
downloads or uploads, such as SET_ADDRESS and ERASE_PAGE. Also
the normal DFU_DNLOAD and DFU_UPLOAD commands have special
implementations in DfuSe.
Many DfuSe devices also support commands to leave DFU mode,
read unprotect the flash memory or mass erase the flash memory.
dfu-util (from version 0.7)
supports adding "leave", "unprotect", or "mass-erase"
to the -s option argument to send such requests in combination
with a download request. These modifiers are separated with a colon.
</p>
<p>
Some DfuSe devices have their DfuSe bootloader running from flash
memory. Erasing the whole flash memory would therefore destroy
the DfuSe bootloader itself and practically brick the device
for most users. Any use of modifiers such as "unprotect"
and "mass-erase" therefore needs to be combined with the "force"
modifer. This is not included in the examples, to not encourage
ignorant users to copy and paste such instructions and shoot
themselves in the foot.
</p>
<p>
Devices based on for instance STM32F103 all run the bootloader
from flash, since there is no USB bootloader in ROM.
</p>
<p>
For instance STM32F107, STM32F2xx and STM32F4xx devices have a
DfuSe bootloader in ROM, so the flash can be erased while
keeping the device available for USB DFU transfers as long
as the device designers use this built-in bootloader and have
not implemented another DfuSe bootloader in flash that the user is
dependent upon.
</p>
<p>
Well-written bootloaders running from flash will report their
own memory region as read-only and not eraseable, but this does
not prevent dfu-util from sending a "unprotect" or "mass-erase"
request which overrides this, if the user insists.
</p>
<h2>Example usage</h2>
<p>
Flashing a .dfu (special DfuSe format) file to the device:
</p>
<pre>
$ dfu-util -a 0 -D /path/to/dfuse-image.dfu
</pre>
<p>
Reading out 1 KB of flash starting at address 0x8000000:
</p>
<pre>
$ dfu-util -a 0 -s 0x08000000:1024 -U newfile.bin
</pre>
<p>
Flashing a binary file to address 0x8004000 of device memory and ask
the device to leave DFU mode:
</p>
<pre>
$ dfu-util -a 0 -s 0x08004000:leave -D /path/to/image.bin
</pre>
<p>
[<a href="index.html">Back to dfu-util main page</a>]
</p>
<p id="footer">
&copy;2012 Tormod Volden &mdash; Valid <a href="http://validator.w3.org/check?uri=referer" title="validate XHTML">XHTML</a> &amp; <a href="http://jigsaw.w3.org/css-validator" title="validate CSS">CSS</a>
</p>
</div>
</body>
</html>