Texas Instruments Tiva TM4C123GH6PM User manual

Copyright © 2011-2013
Texas Instruments Incorporated
ROM-TM4C123GH6PM-UG-750
ROM USER’S GUIDE
Tiva™ TM4C123GH6PM

Copyright
Copyright © 2011-2013 Texas Instruments Incorporated. All rights reserved. Tiva and TivaWare are trademarks of Texas Instruments Instruments. ARM
and Thumb are registered trademarks and Cortex is a trademark of ARM Limited. Other names and brands may be claimed as the property of others.
Please be aware that an important notice concerning availability, standard warranty, and use in critical applications of Texas Instruments semicon-
ductor products and disclaimers thereto appears at the end of this document.
Texas Instruments
108 Wild Basin, Suite 350
Austin, TX 78746
www.ti.com/tiva-c
Revision Information
This is version 750 of this document, last updated on April 8, 2013.
2 April 8, 2013

Table of Contents
Table of Contents
Copyright ..................................................... 2
Revision Information ............................................... 2
1 Introduction ................................................. 5
2 Boot Loader ................................................. 7
2.1 Introduction .................................................. 7
2.2 Serial Interfaces ............................................... 7
2.3 USB Interface ................................................ 12
3 AES Data Tables .............................................. 27
3.1 Introduction .................................................. 27
3.2 Data Structures ............................................... 27
4 Analog Comparator ............................................ 29
4.1 Introduction .................................................. 29
4.2 Functions ................................................... 29
5 Analog to Digital Converter (ADC) .................................... 35
5.1 Introduction .................................................. 35
5.2 Functions ................................................... 35
6 Controller Area Network (CAN) ...................................... 53
6.1 Introduction .................................................. 53
6.2 Functions ................................................... 54
7 CRC ...................................................... 69
7.1 Introduction .................................................. 69
7.2 Functions ................................................... 69
8 Flash ..................................................... 73
8.1 Introduction .................................................. 73
8.2 Functions ................................................... 73
9 Floating-Point Unit (FPU) ......................................... 81
9.1 Introduction .................................................. 81
9.2 API Functions ................................................ 82
10 GPIO ..................................................... 87
10.1 Introduction .................................................. 87
10.2 Functions ................................................... 87
11 Hibernation Module ............................................ 107
11.1 Introduction .................................................. 107
11.2 Functions ................................................... 108
12 Inter-Integrated Circuit (I2C) ....................................... 123
12.1 Introduction .................................................. 123
12.2 Functions ................................................... 124
13 Interrupt Controller (NVIC) ........................................ 137
13.1 Introduction .................................................. 137
13.2 Functions ................................................... 137
14 Memory Protection Unit (MPU) ...................................... 145
14.1 Introduction .................................................. 145
14.2 Functions ................................................... 146
15 Pulse Width Modulator (PWM) ...................................... 153
April 8, 2013 3

Table of Contents
15.1 Introduction .................................................. 153
15.2 Functions ................................................... 153
16 Quadrature Encoder (QEI) ........................................ 175
16.1 Introduction .................................................. 175
16.2 Functions ................................................... 175
17 Synchronous Serial Interface (SSI) ................................... 185
17.1 Introduction .................................................. 185
17.2 Functions ................................................... 185
18 System Control ............................................... 197
18.1 Introduction .................................................. 197
18.2 Functions ................................................... 198
19 System Exception Module ........................................ 223
19.1 Introduction .................................................. 223
19.2 API Functions ................................................ 223
20 System Tick (SysTick) ........................................... 227
20.1 Introduction .................................................. 227
20.2 Functions ................................................... 227
21 Timer ..................................................... 231
21.1 Introduction .................................................. 231
21.2 Functions ................................................... 231
22 UART ..................................................... 249
22.1 Introduction .................................................. 249
22.2 Functions ................................................... 249
23 uDMA Controller .............................................. 271
23.1 Introduction .................................................. 271
23.2 Functions ................................................... 273
24 USB Controller ............................................... 297
24.1 Introduction .................................................. 297
24.2 Using USB with the uDMA Controller ................................... 298
24.3 Functions ................................................... 302
25 Watchdog Timer .............................................. 341
25.1 Introduction .................................................. 341
25.2 Functions ................................................... 341
IMPORTANT NOTICE ............................................... 352
4 April 8, 2013

Introduction
1 Introduction
The TM4C123GH6PM ROM contains the TivaWare™ Peripheral Driver Library and the TivaWare
Boot Loader. The peripheral driver library can be utilized by applications to reduce their flash
footprint, allowing the flash to be used for other purposes (such as additional features in the appli-
cation). The boot loader is used as an initial program loader (when the flash is empty) as well as
an application-initiated firmware upgrade mechanism (by calling back to the boot loader).
There is a table at the beginning of the ROM that points to the entry points for the APIs that are
provided in the ROM. Accessing the API through these tables provides scalability; while the API
locations may change in future versions of the ROM, the API tables will not. The tables are split
into two levels; the main table contains one pointer per peripheral which points to a secondary table
that contains one pointer per API that is associated with that peripheral. The main table is located
at 0x0100.0010, right after the Cortex-M4 vector table in the ROM.
The following table shows a small portion of the API tables in a graphical form that helps to illustrate
the arrangement of the tables:
ROM_APITABLE (at 0x0100.0010)
[0] = ROM_VERSION
[1] = pointer to ROM_UARTTABLE
[2] = pointer to ROM_SSITABLE
[3] = pointer to ROM_I2CTABLE
[4] = pointer to ROM_GPIOTABLE =⇒ROM_GPIOTABLE
[5] = pointer to ROM_ADCTABLE [0] = pointer to ROM_GPIOPinWrite
[6] = pointer to ROM_COMPARATORTABLE [1] = pointer to ROM_GPIODirModeSet
[7] = pointer to ROM_FLASHTABLE [2] = pointer to ROM_GPIODirModeGet
... ...
From this, the address of the ROM_GPIOTABLE table is located in the memory location at
0x0100.0020. The address of the ROM_GPIODirModeSet() function is contained at offset 0x4
from that table. In the function documentation, this is represented as:
ROM_APITABLE is an array of pointers located at 0x0100.0010.
ROM_GPIOTABLE is an array of pointers located at ROM_APITABLE[4].
ROM_GPIODirModeSet is a function pointer located at ROM_GPIOTABLE[1].
The TivaWare Peripheral Driver Library contains a file called driverlib/rom.h that assists with
calling the peripheral driver library functions in the ROM. The naming conventions for the tables
and APIs that are used in this document match those used in that file.
The following is an example of calling the ROM_GPIODirModeSet() function:
#define TARGET_IS_BLIZZARD_RB1
#include <stdbool.h>
#include <stdint.h>
#include "inc/hw_memmap.h"
#include "driverlib/gpio.h"
#include "driverlib/rom.h"
int
main(void)
{
// ...
April 8, 2013 5

Introduction
ROM_GPIODirModeSet(GPIO_PORTA_BASE, GPIO_PIN_0, GPIO_DIR_MODE_OUT);
// ....
}
See the “Using the ROM” chapter of the TivaWare Peripheral Driver Library User’s Guide for more
details on calling the ROM functions and using driverlib/rom.h.
The API provided by the ROM can be utilized by any compiler so long as it complies with the
Embedded Applications Binary Interface (EABI), which includes all recent compilers for the Cortex-
M4 microcontroller.
Documentation Overview
The ROM-based TivaWare Boot Loader is described in chapter 2, and the ROM-based TivaWare
Peripheral Driver Library is described in chapters 3through 25.
6 April 8, 2013

Boot Loader
2 Boot Loader
Introduction ...............................................................................................7
Serial Interfaces ...........................................................................................7
USB .....................................................................................................12
2.1 Introduction
The ROM-based boot loader is executed each time the device is reset when the flash is empty.
The flash is assumed to be empty if the first two words are all ones (since the second word is the
reset vector address, it must be programmed for an application in flash to execute). When run, it
will allow the flash to be updated using one of the following interfaces:
UART0 using a custom serial protocol
SSI0 using a custom serial protocol
I2C0 using a custom serial protocol
USB using DFU protocol
The USB portion of the boot loader must run with the main PLL enabled which requires not only
that the boot loader detect if a crystal is present, but also determine the frequency of the attached
crystal to properly configure the main PLL. This crystal detection algorithm is only run when the
boot loader does not find a valid application and is not run when the boot loader is called from an
application. The device is configured to run from the PLL when there is a valid external crystal for
USB operation as specified in the data sheet.
The LM Flash Programmer GUI can be used to download an application via the boot loader over
the UART or USB interface on a PC. The LM Flash Programmer utility is available for download
from www.ti.com/tiva-c.
2.2 Serial Interfaces
The serial interfaces used to communicate with the boot loader share a common protocol and differ
only in the physical connections and signaling used to transfer the bytes of the protocol.
2.2.1 UART Interface
The UART pins U0Tx and U0Rx are used to communicate with the boot loader. The device com-
municating with the boot loader is responsible for driving the U0Rx pin, while the microcontroller
drives the U0Tx pin.
The serial data format is fixed at 8 data bits, no parity, and one stop bit. An auto-baud feature is
used to determine the baud rate at which data is transmitted. Because the system clock must be at
least 32 times the baud rate, the maximum baud rate that can be used is 500 Kbaud (which is 16
MHz divided by 32).
When an application calls back to the ROM-based boot loader to start an update over the UART
port, the auto-baud feature is bypassed, along with UART configuration and pin configuration.
April 8, 2013 7

Boot Loader
Therefore, the UART must be configured and the UART pins switched to their hardware function
before calling the boot loader.
2.2.2 SSI Interface
The SSI pins SSIFss,SSIClk,SSITx, and SSIRx are used to communicate with the boot loader.
The device communicating with the boot loader is responsible for driving the SSIRx,SSIClk, and
SSIFss pins, while the microcontroller drives the SSITx pin.
The serial data format is fixed to the Motorola format with SPH set to 1 and SPO set to 1 (see the
data sheet for more information on this format). Since the system clock must be at least 12 times
the serial clock rate, the maximum serial clock rate that can be used is 1.3 MHz (which is 16 MHz
divided by 12).
When an application calls back to the ROM-based boot loader to start an update over the SSI port,
the SSI configuration and pin configuration is bypassed. Therefore, the SSI port must be configured
and the SSI pins switched to their hardware function before calling the boot loader.
2.2.3 I2C Interface
The I2C pins I2CSCL and I2CSDA are used to communicate with the boot loader. The device
communicating with the boot loader must operate as the I2C master and provide the I2CSCL signal.
The I2CSDA pin is open-drain and can be driven by either the master or the slave I2C device.
The I2C interface can run at up to 400 KHz, the maximum rate supported by the I2C protocol. The
boot loader uses an I2C slave address of 0x42.
When an application calls back to the ROM-based boot loader to start an update over the I2C port,
the I2C configuration and pin configuration is bypassed. Therefore, the I2C port must be configured,
the I2C slave address set, and the I2C pins switched to their hardware function before calling the
boot loader. Additionally, the I2C master must be enabled since it is used to detect start and stop
conditions on the I2C bus.
2.2.4 Serial Protocol
The boot loader uses well-defined packets on the serial interfaces to ensure reliable communica-
tions with the update program. The packets are always acknowledged or not acknowledged by the
communicating devices. The packets use the same format for receiving and sending packets. This
includes the method used to acknowledge successful or unsuccessful reception of a packet. While
the actual signaling on the serial ports is different, the packet format remains independent of the
method of transporting the data.
The following steps must be performed to successfully send a packet:
1. Send the size of the packet that will be sent to the device. The size is always the number of
bytes of data + 2 bytes.
2. Send the checksum of the data buffer to help ensure proper transmission of the command.
The checksum is simply a sum of the data bytes.
3. Send the actual data bytes.
8 April 8, 2013

Boot Loader
4. Wait for a single-byte acknowledgment from the device that it either properly received the data
or that it detected an error in the transmission.
The following steps must be performed to successfully receive a packet:
1. Wait for non-zero data to be returned from the device. This is important as the device may
send zero bytes between a sent and received data packet. The first non-zero byte received
will be the size of the packet that is being received.
2. Read the next byte which will be the checksum for the packet.
3. Read the data bytes from the device. There will be packet size - 2 bytes of data sent during
the data phase. For example, if the packet size was 3, then there is only 1 byte of data to be
received.
4. Calculate the checksum of the data bytes and ensure that it matches the checksum received
in the packet.
5. Send an acknowledge (ACK) or not-acknowledge (NAK) to the device to indicate the success-
ful or unsuccessful reception of the packet.
An acknowledge packet is sent whenever a packet is successfully received and verified by the boot
loader. A not-acknowledge packet is sent whenever a sent packet is detected to have an error,
usually as a result of a checksum error or just malformed data in the packet. This allows the sender
to re-transmit the previous packet.
The following commands are used by the custom protocol:
COMMAND_PING
= 0x20
This command is used to receive an acknowledge from the boot
loader indicating that communication has been established. This
command is a single byte.
The format of the command is as follows:
uint8_t pui8Command[1];
pui8Command[0] = COMMAND_PING;
April 8, 2013 9

Boot Loader
COMMAND_DOWNLOAD
= 0x21
This command is sent to the boot loader to indicate where
to store data and how many bytes will be sent by the
COMMAND_SEND_DATA commands that follow. The command
consists of two 32-bit values that are both transferred MSB first.
The first 32-bit value is the address to start programming data
into, while the second is the 32-bit size of the data that will be
sent. This command also triggers a mass erase of the flash,
which causes the command to take longer to send the ACK/NAK
in response to the command. This command should be followed
by a COMMAND_GET_STATUS to ensure that the program ad-
dress and program size were valid for the microcontroller running
the boot loader.
The format of the command is as follows:
uint8_t pui8Command[9];
pui8Command[0] = COMMAND_DOWNLOAD;
pui8Command[1] = Program Address [31:24];
pui8Command[2] = Program Address [23:16];
pui8Command[3] = Program Address [15:8];
pui8Command[4] = Program Address [7:0];
pui8Command[5] = Program Size [31:24];
pui8Command[6] = Program Size [23:16];
pui8Command[7] = Program Size [15:8];
pui8Command[8] = Program Size [7:0];
COMMAND_RUN
= 0x22
This command is sent to the boot loader to transfer execution
control to the specified address. The command is followed by a
32-bit value, transferred MSB first, that is the address to which
execution control is transferred.
The format of the command is as follows:
uint8_t pui8Command[5];
pui8Command[0] = COMMAND_RUN;
pui8Command[1] = Run Address [31:24];
pui8Command[2] = Run Address [23:16];
pui8Command[3] = Run Address [15:8];
pui8Command[4] = Run Address [7:0];
10 April 8, 2013

Boot Loader
COMMAND_GET_STATUS
= 0x23
This command returns the status of the last command that was
issued. Typically, this command should be received after every
command is sent to ensure that the previous command was suc-
cessful or, if unsuccessful, to properly respond to a failure. The
command requires one byte in the data of the packet and the
boot loader should respond by sending a packet with one byte of
data that contains the current status code.
The format of the command is as follows:
uint8_t pui8Command[1];
pui8Command[0] = COMMAND_GET_STATUS;
The following are the definitions for the possible status
values that can be returned from the boot loader when
COMMAND_GET_STATUS is sent to the the microcontroller.
COMMAND_RET_SUCCESS
COMMAND_RET_UNKNOWN_CMD
COMMAND_RET_INVALID_CMD
COMMAND_RET_INVALID_ADD
COMMAND_RET_FLASH_FAIL
COMMAND_SEND_DATA
= 0x24
This command should only follow a COMMAND_DOWNLOAD com-
mand or another COMMAND_SEND_DATA command, if more data
is needed. Consecutive send data commands automatically in-
crement the address and continue programming from the previ-
ous location. The transfer size is limited by the maximum size of
a packet, which allows up to 252 data bytes to be transferred at a
time. The command terminates programming once the number
of bytes indicated by the COMMAND_DOWNLOAD command has
been received. Each time this function is called, it should be
followed by a COMMAND_GET_STATUS command to ensure that
the data was successfully programmed into the flash. If the boot
loader sends a NAK to this command, the boot loader will not in-
crement the current address which allows for retransmission of
the previous data.
The format of the command is as follows:
uint8_t pui8Command[9];
pui8Command[0] = COMMAND_SEND_DATA
pui8Command[1] = Data[0];
pui8Command[2] = Data[1];
pui8Command[3] = Data[2];
pui8Command[4] = Data[3];
pui8Command[5] = Data[4];
pui8Command[6] = Data[5];
pui8Command[7] = Data[6];
pui8Command[8] = Data[7];
April 8, 2013 11

Boot Loader
COMMAND_RESET
= 0x25
This command is used to tell the boot loader to reset. This is
used after downloading a new image to the microcontroller to
cause the new application to start from a reset. The normal boot
sequence occurs and the image runs as if from a hardware reset.
It can also be used to reset the boot loader if a critical error
occurs and the host device wants to restart communication with
the boot loader.
The boot loader responds with an ACK signal to the host device
before actually executing the software reset on the microcon-
troller running the boot loader. This informs the updater appli-
cation that the command was received successfully and the part
will be reset.
The format of the command is as follows:
uint8_t pui8Command[1];
pui8Command[0] = COMMAND_RESET;
The definitions for these commands are provided as part of the Tiva Peripheral Driver Library, in
boot_loader/bl_commands.h.
2.3 USB Interface
The USB boot loader allows programming the flash over USB using the standard USB DFU update
method. To use the USB boot loader, the system running the boot loader must be capable of acting
as a USB device and have the proper USB B or USB AB connector. The boot loader does not sup-
port firmware update of systems which operate solely as USB hosts. The USB update mechanism
allows the boot loader to either be called from a functioning application or from startup when no
firmware has been downloaded to the microcontroller. When the USB boot loader is called from an
application, the application can customize some of the descriptors that are used for enumeration.
This customization option is not available when the microcontroller is being programmed and there
is no application present on the microcontroller.
When the USB boot loader is invoked from a running application, the boot loader reconfigures the
USB controller to publish the required descriptor set for a Device Firmware Upgrade (DFU) class
device and merge in any custom values that the application provides. Before calling the boot loader
from an application, the main application is responsible for the following: enable the main PLL and
configure it as the system clock, enable the USB PLL, enable the USB controller, and enable the
USB D+ and D- pins on the microcontroller. If the main application is already acting as a USB
device, then the application must remove the device from the bus by calling the DriverLib function
ROM_USBDevDisconnect() prior to entering the boot loader.
2.3.1 USB Device Firmware Upgrade Overview
The USB boot loader enumerates as a Device Firmware Upgrade (DFU) class device.
This standard device class specifies a set of class-specific requests and a state ma-
chine that can be used to download and flash firmware images to a device and, op-
12 April 8, 2013

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
ROM_USBDevDisconnect() before transferring control to the USB boot loader by making a call
to ROM_UpdateUSB(). 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

Boot Loader
DFU_UPLOAD This IN request is used to request a block of binary data from
the device. The data returned is device-specific but is typi-
cally the contents of a region of the device’s flash memory or
a device-specific response to a command previously sent via
aDFU_DNLOAD request. As with DFU_DNLOAD, the maximum
amount of data that can be requested is governed by the maxi-
mum packet size specified in the DFU functional descriptor, here
1024 bytes.
DFU_GETSTATUS This IN request allows the host to query the current status of the
DFU device. It is typically used during download operations to
determine when it is safe to send the next block of data. De-
pending upon the state of the DFU device, this request may also
trigger a state change. During download, for example, the de-
vice enters DNLOAD_SYNC state after receiving a block of data
and remains there until the data has been processed and a
DFU_GETSTATUS request is received at which point the state
changes to DNLOAD_IDLE.
DFU_CLRSTATUS This request is used to reset any error condition reported by
the DFU device. If an error is reported via the response to a
DFU_GETSTATUS request, that error condition is cleared when
this request is received and the device returns to IDLE state.
DFU_GETSTATE This IN request is used to query the current state of the device
without triggering any state change. The single byte of data re-
turned indicates the current state of the DFU device.
DFU_ABORT This request cancels any partially complete upload or download
operation and returns the device to IDLE state in preparation for
some other request.
2.3.3 Typical Firmware Download Sequence
The following flow chart illustrates a typical firmware image download sequence from the perspec-
tive of the host application.
14 April 8, 2013

Boot Loader
DFU Device Enumerated
Exit
Send DFU_GETSTATUS
No
Send DFU_DNLOAD with
a block o irmware
image data.
State is
ERROR?
Yes
State is
DNLOAD_SYNC
or DNBUSY?
State is
DNLOAD_IDLE?
More data
to send?
No
No
YesYes
Send DFU_DNLOAD with
a zero-length payload.
Report the error condition
Send DFU_GETSTATUS
Yes
No
State is
ERROR?
Yes
No
April 8, 2013 15

Boot Loader
2.3.4 Tiva-Specific USB Download Commands
The DFU class specification provides the framework necessary to download and upload firmware
files to the USB device but does not specify the actual format of the binary data that is transferred.
As a result, different device implementations have used different methods to perform operations
that are not defined in the standard such as:
Setting the address to flash a downloaded binary.
Setting the address and size of the area of flash with contents to be uploaded.
Erasing sections of the flash.
Querying the size of flash and writeable area addresses.
The USB boot loader implementation employs a small set of commands which can be sent to the
DFU device via a DFU_DNLOAD request when the device is in IDLE state. Each command takes
the form of an 8-byte structure that defines the operation to carry out and provides any required
additional parameters.
To ensure that a host application that does not have explicit support for Tiva-specific commands can
still be used to download binary firmware images to the device, the protocol is defined such that only
a single 8-byte header structure must be placed at the start of the binary image being downloaded.
This header and the DFU-defined suffix structure can both be added using the “dfuwrap” command-
line application supplied with TivaWare, thus providing a single binary that can be sent to a device
running the Tiva USB boot loader using a standard sequence of DFU_DNLOAD requests with no
other embedded commands or device-specific operations required. An application which does
understand the Tiva-specific commands may make use of them to offer additional functionality that
would not otherwise be available.
Querying Command Support
Because the device-specific commands defined here are sent to the DFU device in DFU_DNLOAD
requests, the possibility exists that sending them to a device which does not understand the protocol
could result in corruption of that device’s firmware. To guard against this possibility, the USB boot
loader supports an additional USB request which is used to query the device capabilities and allow
a host to determine whether or not the device supports the Tiva commands. A device which does
not support the commands either stalls the request or returns unexpected data.
To determine whether a target DFU device supports the Tiva-specific DFU commands, send the
following IN request to the DFU interface:
bmRequest-
Type
bRequest wValue wIndex wLength Data
10100001b 0x42 0x23 Interface 4 Protocol Info
where the protocol information returned is a 4-byte structure, the first two bytes of which are 0x4D,
0x4C and the second two bytes indicates the protocol version supported, currently 0x01 and 0x00
respectively.
Download Command Definitions
The following commands may be sent to the USB boot loader as the first 8 bytes of the payload to
aDFU_DNLOAD request. The boot loader expects any DFU_DNLOAD request received while in the
16 April 8, 2013

Boot Loader
IDLE state to contain a command header but does not look for a command unless the state is IDLE.
This protocol allows an application that is unaware of the command header to download a DFU-
wrapped binary image using a standard sequence of multiple DFU_DNLOAD and DFU_GETSTATUS
requests without the need to insert additional command headers during the download.
The commands defined here and their parameter block structures can be found in header file
usbdfu.h provided with TivaWare. In all cases where multi-byte numbers are specified, the num-
bers are stored in little-endian format with the least significant byte in the lowest addressed location.
The following definitions specify the command byte ordering unambiguously but care must be taken
to ensure correct byte swapping if using the command structure types defined in usbdfu.h on big-
endian systems.
DFU_CMD_PROG This command is used to provide the USB boot loader with the address at which
the next download should be written and the total length of the firmware image
that follows. This structure forms the header that is written to the DFU-wrapped
file generated by the dfuwrap tool.
The start address is provided in terms of 1024-byte flash blocks. To convert a
byte address to a block address, merely divide by 1024. The start address must
always be on a 1024-byte boundary.
This command may be followed by up to 1016 bytes of firmware image data,
this number being the maximum transfer size minus the 8 bytes of the command
structure.
The format of the command is as follows:
uint8_t pui8Data[8];
pui8Data[0] = DFU_CMD_PROG (0x01)
pui8Data[1] = Reserved - set to 0x00
pui8Data[2] = Start Block Number [7:0];
pui8Data[3] = Start Block Number [15:8];
pui8Data[4] = Image Size [7:0];
pui8Data[5] = Image Size [15:8];
pui8Data[6] = Image Size [23:16];
pui8Data[7] = Image Size [31:24];
April 8, 2013 17

Boot Loader
DFU_CMD_READ This command is used to set the address range of the content to be returned
on subsequent DFU_UPLOAD requests from the host.
The start address is provided in terms of 1024-byte flash blocks. To convert a
byte address to a block address, divide by 1024. The start address must always
be on a 1024-byte boundary.
To read back a the contents of a region of flash, the host should send a
DFU_DNLOAD request with command DFU_CMD_READ, start address set to the
1KB block start address and length set to the number of bytes to read. The
host should then send one or more DFU_UPLOAD requests to receive the cur-
rent flash contents from the configured addresses. Data returned includes an
8-byte DFU_CMD_PROG prefix structure unless the prefix has been disabled by
sending a DFU_CMD_BIN command with the bBinary parameter set to 1. The
host should, therefore, be prepared to read 8 bytes more than the length spec-
ified in the READ command if the prefix is enabled.
By default, the 8-byte prefix is enabled for all upload operations. This prefix
is required by the DFU class specification which states that uploaded images
must be formatted to allow them to be directly downloaded back to the device
at a later time.
The format of the command is as follows:
uint8_t pui8Data[8];
pui8Data[0] = DFU_CMD_READ (0x02)
pui8Data[1] = Reserved - set to 0x00
pui8Data[2] = Start Block Number [7:0];
pui8Data[3] = Start Block Number [15:8];
pui8Data[4] = Image Size [7:0];
pui8Data[5] = Image Size [15:8];
pui8Data[6] = Image Size [23:16];
pui8Data[7] = Image Size [31:24];
18 April 8, 2013

Boot Loader
DFU_CMD_CHECK This command is used to check a region of flash to ensure that it is completely
erased.
The start address is provided in terms of 1024-byte flash blocks. To convert a
byte address to a block address, divide by 1024. The start address must always
be on a 1024-byte boundary. The length must also be a multiple of 4.
To check that a region of flash is erased, the DFU_CMD_CHECK command
should be sent with the required start address and region length set then the
host should issue a DFU_GETSTATUS request. If the erase check was success-
ful, the returned bStatus value is OK (0x00), otherwise it is errCheckErased
(0x05).
The format of the command is as follows:
uint8_t pui8Data[8];
pui8Data[0] = DFU_CMD_CHECK (0x03)
pui8Data[1] = Reserved - set to 0x00
pui8Data[2] = Start Block Number [7:0];
pui8Data[3] = Start Block Number [15:8];
pui8Data[4] = Region Size [7:0];
pui8Data[5] = Region Size [15:8];
pui8Data[6] = Region Size [23:16];
pui8Data[7] = Region Size [31:24];
DFU_CMD_ERASE This command is used to erase a region of flash.
The start address is provided in terms of 1024-byte flash blocks. To convert a
byte address to a block address, divide by 1024. The start address must always
be on a 1024-byte boundary. The length must also be a multiple of 4.
The size of the region to erase is expressed in terms of flash blocks. The block
size can be determined using the DFU_CMD_INFO command.
The format of the command is as follows:
uint8_t pui8Data[8];
pui8Data[0] = DFU_CMD_ERASE (0x04)
pui8Data[1] = Reserved - set to 0x00
pui8Data[2] = Start Block Number [7:0];
pui8Data[3] = Start Block Number [15:8];
pui8Data[4] = Number of Blocks [7:0];
pui8Data[5] = Number of Blocks [15:8];
pui8Data[6] = Reserved - set to 0x00
pui8Data[7] = Reserved - set to 0x00
April 8, 2013 19

Boot Loader
DFU_CMD_INFO This command is used to query information relating to the target de-
vice and programmable region of flash. The device information structure,
tDFUDeviceInfo, is returned on the next DFU_UPLOAD request following this
command.
The format of the command is as follows:
uint8_t pui8Data[8];
pui8Data[0] = DFU_CMD_INFO (0x05)
pui8Data[1] = Reserved - set to 0x00
pui8Data[2] = Reserved - set to 0x00
pui8Data[3] = Reserved - set to 0x00
pui8Data[4] = Reserved - set to 0x00
pui8Data[5] = Reserved - set to 0x00
pui8Data[6] = Reserved - set to 0x00
pui8Data[7] = Reserved - set to 0x00
//*******************************************************************
//
// Payload returned in response to the DFU_CMD_INFO command.
//
// This is structure is returned in response to the first DFU_UPLOAD
// request following a DFU_CMD_INFO command. Note that byte ordering
// of multi-byte fields is little-endian.
//
//*******************************************************************
typedef struct
{
//
// The size of a flash block in bytes.
//
uint16_t ui16FlashBlockSize;
//
// The number of blocks of flash in the device. Total
// flash size is usNumFlashBlocks *usFlashBlockSize.
//
uint16_t ui16NumFlashBlocks;
//
// Information on the part number, family, version and
// package as read from SYSCTL register DID1.
//
uint32_t ui32PartInfo;
//
// Information on the part class and revision as read
// from SYSCTL DID0.
//
uint32_t ui32ClassInfo;
//
// Address 1 byte above the highest location the boot
// loader can access.
//
uint32_t ui32FlashTop;
//
// Lowest address the boot loader can write or erase.
//
uint32_t ui32AppStartAddr;
}
PACKED tDFUDeviceInfo;
20 April 8, 2013