Boot Loader
tionally, upload the existing firmware image to the USB host.
The full specification for
the device class can be downloaded from the USB Implementer’s Forum web site at
http://www.usb.org/developers/devclass_docs#approved.
All communication with the DFU device takes place using the USB control endpoint, endpoint 0. The
device publishes a standard device descriptor with vendor, product, device revisions and strings. It
also publishes a single configuration descriptor and a single interface descriptor where the interface
class of 0xFE indicates an application-specific class and the subclass of 0x01 indicates “Device
Firmware Upgrade”. Attached to the interface descriptor is a DFU Functional Descriptor which
provides information to the host on DFU-specific device capabilities such as whether the device can
perform upload operations and what the maximum transfer size for upload and download operations
is.
DFU functions are initiated by means of a set of class-specific requests. Each request, which follows
the standard USB request format, performs some operation and moves the DFU device between
a series of well-defined states. Additional requests allow the host to query the current state of the
device to determine whether, for example, it is ready to receive the next block of download data.
A DFU device may operation in either “Run Time” mode or “DFU” mode. In “Run Time” mode, the
device publishes the DFU interface and functional descriptors along with any other descriptors that
the device requires for normal operation. However, it is not required to respond to any DFU class-
specific requests other than
DFU_DETACH
which indicates that it should switch to “DFU” mode.
The “Run Time” mode support is not part of the USB boot loader but can be added to a USB
device application to provide simple switching to “DFU” mode. If a main application wishes to
publish DFU descriptors and respond to the
DFU_DETACH
request, it can cause a switch to “DFU”
mode on receiving a
DFU_DETACH
request by removing itself from the USB bus using a call to
before transferring control to the USB boot loader by making a call
to
. Once in “DFU” mode in the boot loader, the device supports all DFU
functionality and can perform upload and download operations as specified in its DFU functional
descriptor.
2.3.2
DFU Requests
Requests supported by the USB boot loader are as follow:
DFU_DNLOAD
This OUT request is used to send a block of binary data to the
device. The DFU class specification does not define the con-
tent and format of the binary data but typically it is either binary
data to be written to some position in the device’s flash mem-
ory or a device-specific command. The request payload size is
constrained by the maximum packet size specified in the DFU
functional descriptor. In this implementation, that maximum is
set to 1024 bytes.
After sending a
DFU_DNLOAD
request, the host must poll the de-
vice status and wait until the state reverts to
DNLOAD_IDLE
be-
fore sending another request. If the host wishes to indicate that
it has finished sending download data, it sends a
DFU_DNLOAD
request with a payload length of 0.
April 8, 2013
13
Содержание Tiva TM4C123GH6PM
Страница 26: ...Boot Loader 26 April 8 2013...
Страница 68: ...Controller Area Network CAN 68 April 8 2013...
Страница 122: ...Hibernation Module 122 April 8 2013...
Страница 136: ...Inter Integrated Circuit I2C 136 April 8 2013...
Страница 152: ...Memory Protection Unit MPU 152 April 8 2013...
Страница 174: ...Pulse Width Modulator PWM Returns None 174 April 8 2013...
Страница 196: ...Synchronous Serial Interface SSI 196 April 8 2013...
Страница 222: ...System Control 222 April 8 2013...
Страница 270: ...UART 270 April 8 2013...
Страница 296: ...uDMA Controller 296 April 8 2013...
Страница 351: ...April 8 2013 351...