Texas Instruments Tiva TM4C123GH6PM User Manual
Tiva™ TM4C123GH6PM
ROM USER’S GUIDE
ROM-TM4C123GH6PM-UG-750
Copyright © 2011-2013
Texas Instruments Incorporated
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
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 application). 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
... ...
Introduction
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 CortexM4 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 3 through 25.
6 April 8, 2013
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.
Boot Loader
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 communicating 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 communications 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 successful 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 address 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
COMMAND_SEND_DATA
= 0x24
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 successful 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
This command should only follow a COMMAND_DOWNLOAD command or another COMMAND_SEND_DATA command, if more data
is needed. Consecutive send data commands automatically increment the address and continue programming from the previous 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 increment 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
The definitions for these commands are provided as part of the Tiva Peripheral Driver Library, in
boot_loader/bl_commands.h.
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 microcontroller running the boot loader. This informs the updater application 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;
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 support 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 machine 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 classspecific 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 content and format of the binary data but typically it is either binary
data to be written to some position in the device’s flash memory 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 device status and wait until the state reverts to DNLOAD_IDLE before 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 typically the contents of a region of the device’s flash memory or
a device-specific response to a command previously sent via
a DFU_DNLOAD request. As with DFU_DNLOAD, the maximum
amount of data that can be requested is governed by the maximum 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. Depending upon the state of the DFU device, this request may also
trigger a state change. During download, for example, the device 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 returned 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 perspective of the host application.
14 April 8, 2013
DFU Device Enumerated
Exit
Send DFU_GETSTATUS
No
Send DFU_DNLOAD with
a block of firmware
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
Boot Loader
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” commandline 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:
bmRequestType
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.
bRequest wValue wIndex wLength Data
Download Command Definitions
The following commands may be sent to the USB boot loader as the first 8 bytes of the payload to
a DFU_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 DFUwrapped 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 numbers 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 bigendian 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 current 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 specified 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 successful, 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
Boot Loader
DFU_CMD_BIN By default, data returned in response to a DFU_UPLOAD request includes an
8-byte DFU_CMD_PROG prefix structure. This ensures that an uploaded image
can be directly downloaded again without the need to further wrap it but, in
cases where pure binary data is required, can be awkward. The DFU_CMD_BIN
command allows the upload prefix to be disabled or enabled under host control.
The format of the command is as follows:
uint8_t pui8Data[8];
pui8Data[0] = DFU_CMD_BIN (0x06)
pui8Data[1] = 0x01 to disable upload prefix, 0x00 to enable
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
DFU_CMD_RESET This command may be sent to the USB boot loader to cause it to perform a
soft reset of the board. This reboots the system and, assuming that the main
application image is present, runs the main application. Note that a reboot also
takes place if a firmware download operation completes and the host issues a
USB reset to the DFU device.
The format of the command is as follows:
uint8_t pui8Data[8];
pui8Data[0] = DFU_CMD_RESET (0x07)
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
2.3.5 Customizing the USB Device Firmware Upgrade
The USB boot loader provides a method to pass a set of custom values to the boot loader when
called from a running application. When the USB boot loader is entered because the flash was
empty, the boot ROM offers no customization and provides generic “Texas Instruments” and “Device
Firmware Update” strings to the host as identifiers. The USB boot loader is called by an application
via a call to ROM_UpdateUSB(), which takes a single pointer as an argument that is a pointer to
an array containing the values that the boot loader uses for customization. This pointer can also be
0 to indicate that the application wishes to use the defaults provided by the ROM boot loader. The
application can place the customization structure anywhere in flash or SRAM.
April 8, 2013 21
Boot Loader
The actual values that can be customized are the following:
Vendor ID (default 0x1CBE)
Product ID (default 0x00FF)
Bus/Self Power (default Self Powered)
Max Power (default 0)
Device Version (default 0x110)
All strings in multiple languages
The defaults for the strings are a Manufacturer set to “Texas Instruments”, Product set to “Device
Firmware Update”, and serial number set to “1.0”.
If the application is providing a structure to the boot loader with custom values, then the first 12
bytes must contain valid data. The values in the structure that is passed to the boot loader have the
following meaning and are merged directly to the device and configuration descriptor for the boot
loader:
Byte Value
0 VID bits 7:0
1 VID bits 15:8
2 PID bits 7:9
3 PID bits 15:8
4 Device Version(BCD) bits 7:9
5 Device Version(BCD) bits 15:8
6 Power in 2mA Increments(250 maximum)
7 USB Configuration Descriptor bmAttributes (Self powered 0xC0,
Bus powered 0x80).
8-11 Pointer to the string table
The values for the custom strings are contained in a pointer at the end of the structure passed to
the boot loader. If the application wants to use the default strings, this pointer should be set to 0.
The string table provided supports custom strings for Manufacturer, Product, and Serial Number in
multiple languages. The string table is optimized to not require that a string be provided for every
language in case there is not a unique string for every language. This is most likely the case for the
Serial Number string but it could be any string that is provided.
The string table has a header that describes the number of languages provided and the language
identifiers for each followed by a set of strings for each language. Each entry in the table has a size
header that specifies the size of the string in bytes plus a byte for the size itself and a one byte tag
of USB_DTYPE_STRING(0x03). This size and ID padding is included for ease of string handling in
the boot loader and is required. It is very important for the application to provide the correct size
values because the boot loader uses these to skip through the array and find the requested strings
requested by the USB host. If these sizes are incorrect, the boot loader may fail to enumerate, so
care should be taken when building the string table. The application must provide all three strings
in the first language because these strings are treated as the default if a string is left blank in
other languages. In other languages, a string can be left blank for strings that do not change per
language. A blank entry in the table consists of a two byte entry with a byte size value of 2 followed
by the USB_DTYPE_STRING value.
The string table has the following format:
22 April 8, 2013
Byte Description
0 Size of the header(Number of Languages * 2) + 2
1 USB_DTYPE_STRING
2 Language ID 0 bits[7:0]
3 Language ID 0 bits[15:8]
... ...
. Language ID n bits[7:0]
. Language ID n bits[15:8]
. Language 0 Manufacturer string size in bytes + 2
. USB_DTYPE_STRING
. Language 0 Manufacturer Unicode String
. Language 0 Product string size in bytes + 2
. USB_DTYPE_STRING
. Language 0 Product Unicode String
. Language 0 Serial Number size in bytes + 2
. USB_DTYPE_STRING
. Language 0 Serial Number Unicode String
... ...
. Language n Manufacturer string size in bytes + 2
. USB_DTYPE_STRING
. Language n Manufacturer Unicode String
. Language n Product string size in bytes + 2
. USB_DTYPE_STRING
. Language n Product Unicode String
. Language n Serial Number size in bytes + 2
. USB_DTYPE_STRING
. Language n Serial Number Unicode String
Boot Loader
The next three examples show an example customization structure for a no string case, a single
language case and a multiple language case.
Example: No strings but custom descriptor.
uint8_t pui8USBBootROMInfo[] =
{
0xbe, 0x1c, // TI VID
0xff, 0x00, // Tiva DFU PID
0x00, 0x02, // USB version 2.0
0x00, // 0mA of Bus power
0xC0, // Self powered using no bus power
0 // Address of the string table
}
//
// Call to ROM USB boot loader.
//
ROM_UpdateUSB(pui8USBBootROMInfo);
Example: Single US English string set.
April 8, 2013 23
Boot Loader
uint8_t pui8Strings[] =
{
(1*2) + 2, // One Language (1*2) + 2
USB_DTYPE_STRING,
0x09, 0x04, // Language code for US English.
(17*2) + 2, // Size of Manufacturer String.
// "Texas Instruments"
USB_DTYPE_STRING,
’T’, 0, ’e’, 0, ’x’, 0, ’a’, 0, ’s’, 0, ’ ’, 0, ’I’, 0, ’n’, 0,
’s’, 0, ’t’, 0, ’r’, 0, ’u’, 0, ’m’, 0, ’e’, 0, ’n’, 0, ’t’, 0,
’s’, 0,
(23*2) + 2, // Size of Product String.
USB_DTYPE_STRING,
// "Device Firmware Upgrade"
’D’, 0, ’e’, 0, ’v’, 0, ’i’, 0, ’c’, 0, ’e’, 0, ’ ’, 0, ’F’, 0,
’i’, 0, ’r’, 0, ’m’, 0, ’w’, 0, ’a’, 0, ’r’, 0, ’e’, 0, ’ ’, 0,
’U’, 0, ’p’, 0, ’g’, 0, ’r’, 0, ’a’, 0, ’d’, 0, ’e’, 0,
(3*2) + 2, // Size of Serial Number.
USB_DTYPE_STRING,
// "1.0"
’1’, 0, ’.’, 0, ’0’, 0
};
uint8_t pui8USBBootROMInfo[] =
{
0xbe, 0x1c, // TI VID
0xff, 0x00, // Tiva DFU PID
0x00, 0x02, // USB version 2.0
0x00, // 0mA of Bus power
0xC0, // Self powered using no bus power
pui8Strings // Address of the string table
}
//
// Call to ROM USB boot loader.
//
ROM_UpdateUSB(pui8USBBootROMInfo);
Example: Two Languages with English(United States) and Spanish(Mexico) strings.
uint8_t pui8Strings[] =
{
(2*2) + 2, // Two languages
USB_DTYPE_STRING,
0x09, 0x04, // Language code for English(United States).
0x0a, 0x08, // Language code for Spanish(Mexico)
(10*2) + 2, // Size of Manufacturer String.
24 April 8, 2013
Boot Loader
// "My Company"
USB_DTYPE_STRING,
’M’, 0, ’y’, 0, ’ ’, 0, ’C’, 0, ’o’, 0, ’m’, 0, ’p’, 0, ’a’, 0,
’n’, 0, ’y’, 0
(23*2) + 2, // Size of Product String.
USB_DTYPE_STRING,
// "Device Firmware Upgrade"
’D’, 0, ’e’, 0, ’v’, 0, ’i’, 0, ’c’, 0, ’e’, 0, ’ ’, 0, ’F’, 0,
’i’, 0, ’r’, 0, ’m’, 0, ’w’, 0, ’a’, 0, ’r’, 0, ’e’, 0, ’ ’, 0,
’U’, 0, ’p’, 0, ’g’, 0, ’r’, 0, ’a’, 0, ’d’, 0, ’e’, 0,
(4*2) + 2, // Size of Serial Number.
USB_DTYPE_STRING,
// "1.01"
’1’, 0, ’.’, 0, ’0’, 0, ’1’, 0
(10*2) + 2, // Size of Manufacturer String.
USB_DTYPE_STRING,
// "My Company"
’M’, 0, ’y’, 0, ’ ’, 0, ’C’, 0, ’o’, 0, ’m’, 0, ’p’, 0, ’a’, 0,
’n’, 0, ’y’, 0
’s’, 0,
(25*2) + 2, // Size of Product String.
USB_DTYPE_STRING,
// "Actualizacion de Firmware"
’A’, 0, ’c’, 0, ’t’, 0, ’u’, 0, ’a’, 0, ’l’, 0, ’i’, 0, ’z’, 0,
’a’, 0, ’c’, 0, ’i’, 0, ’o’, 0, ’n’, 0, ’ ’, 0, ’d’, 0, ’e’, 0,
’ ’, 0, ’F’, 0, ’i’, 0, ’r’, 0, ’m’, 0, ’w’, 0, ’a’, 0, ’r’, 0,
’e’, 0,
2, // Size of Serial Number, this will use the last
// serial number found since this represents a null
// string.
USB_DTYPE_STRING,
};
uint8_t pui8USBBootROMInfo[] =
{
0xbe, 0x1c, // TI VID
0xff, 0x00, // Tiva DFU PID
250, // 500mA of Bus power
0x80, // Bus Powered
0x00, 0x02, // USB version 2.0
pui8Strings // Address of the string table
};
//
// Call to ROM USB boot loader.
//
ROM_UpdateUSB(pui8USBBootROMInfo);
April 8, 2013 25
Boot Loader
26 April 8, 2013
3 AES Data Tables
Introduction . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . .. . . .. . .. . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . .. . . . . . 27
Functions . . .. . . . .. . . .. . .. . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . .. . . .. . .. . . . .. . . . . . .. . . . . . .. . . . .. . . .. . .. . . . .27
3.1 Introduction
The Advanced Encryption Standard (AES) is a publicly defined encryption standard used by the
U.S. Government. It is a strong encryption method with reasonable performance and size. AES
is fast in both hardware and software, is fairly easy to implement, and requires little memory. AES
is ideal for applications that can use pre-arranged keys, such as setup during manufacturing or
configuration.
Four data tables used by the XySSL AES implementation are provided in the ROM. The first is
the forward S-box substitution table, the second is the reverse S-box substitution table, the third is
the forward polynomial table, and the final is the reverse polynomial table. The meanings of these
tables and their use can be found in the AES code provided in TivaWare.
AES Data Tables
3.2 Data Structures
Data Structures
ROM_pvAESTable
3.2.1 Data Structure Documentation
3.2.1.1 ROM_pvAESTable
This structure describes the AES tables that are available in the ROM.
ROM Location:
ROM_APITABLE is an array of pointers located at 0x0100.0010.
ROM_SOFTWARETABLE is an array of pointers located at ROM_APITABLE[21].
ROM_pvAESTable is an array located at &ROM_SOFTWARETABLE[7].
Definition:
typedef struct
{
unsigned char ucForwardSBox[256];
unsigned long ulForwardTable[256];
unsigned char ucReverseSBox[256];
unsigned long ulReverseTable[256];
}
ROM_pvAESTable
Members:
ucForwardSBox This table contains the forward S-Box, as defined by the AES standard.
April 8, 2013 27
AES Data Tables
ulForwardTable This table contains the forward polynomial table, as used by the XySSL AES
implementation.
ucReverseSBox This table contains the reverse S-Box, as defined by the AES standard. This
is simply the reverse of ucForwardSBox.
ulReverseTable This table contains the reverse polynomial table, as used by the XySSL AES
implementation.
28 April 8, 2013
4 Analog Comparator
Introduction . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . .. . . .. . .. . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . .. . . . . . 29
Functions . . .. . . . .. . . .. . .. . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . .. . . .. . .. . . . .. . . . . . .. . . . . . .. . . . .. . . .. . .. . . . .29
4.1 Introduction
The comparator API provides a set of functions for dealing with the analog comparators. A comparator can compare a test voltage against individual external reference voltage, a shared single
external reference voltage, or a shared internal reference voltage. It can provide its output to a
device pin, acting as a replacement for an analog comparator on the board, or it can be used to
signal the application via interrupts or triggers to the ADC to cause it to start capturing a sample
sequence. The interrupt generation and ADC triggering logic is separate, so that an interrupt can
be generated on a rising edge and the ADC triggered on a falling edge (for example).
4.2 Functions
Analog Comparator
Functions
void ROM_ComparatorConfigure (uint32_t ui32Base, uint32_t ui32Comp, uint32_t ui32Config)
void ROM_ComparatorIntClear (uint32_t ui32Base, uint32_t ui32Comp)
void ROM_ComparatorIntDisable (uint32_t ui32Base, uint32_t ui32Comp)
void ROM_ComparatorIntEnable (uint32_t ui32Base, uint32_t ui32Comp)
bool ROM_ComparatorIntStatus (uint32_t ui32Base, uint32_t ui32Comp, bool bMasked)
void ROM_ComparatorRefSet (uint32_t ui32Base, uint32_t ui32Ref)
bool ROM_ComparatorValueGet (uint32_t ui32Base, uint32_t ui32Comp)
4.2.1 Function Documentation
4.2.1.1 ROM_ComparatorConfigure
Configures a comparator.
Prototype:
void
ROM_ComparatorConfigure(uint32_t ui32Base,
uint32_t ui32Comp,
uint32_t ui32Config)
ROM Location:
ROM_APITABLE is an array of pointers located at 0x0100.0010.
ROM_COMPARATORTABLE is an array of pointers located at ROM_APITABLE[6].
ROM_ComparatorConfigure is a function pointer located at ROM_COMPARATORTABLE[1].
April 8, 2013 29
Analog Comparator
Parameters:
Description:
ui32Base is the base address of the comparator module.
ui32Comp is the index of the comparator to configure.
ui32Config is the configuration of the comparator.
This function configures a comparator. The ui32Config parameter is the result of a logical
OR operation between the COMP_TRIG_xxx, COMP_INT_xxx, COMP_ASRCP_xxx, and
COMP_OUTPUT_xxx values.
The COMP_TRIG_xxx term can take on the following values:
COMP_TRIG_NONE to have no trigger to the ADC.
COMP_TRIG_HIGH to trigger the ADC when the comparator output is high.
COMP_TRIG_LOW to trigger the ADC when the comparator output is low.
COMP_TRIG_FALL to trigger the ADC when the comparator output goes low.
COMP_TRIG_RISE to trigger the ADC when the comparator output goes high.
COMP_TRIG_BOTH to trigger the ADC when the comparator output goes low or high.
The COMP_INT_xxx term can take on the following values:
COMP_INT_HIGH to generate an interrupt when the comparator output is high.
COMP_INT_LOW to generate an interrupt when the comparator output is low.
COMP_INT_FALL to generate an interrupt when the comparator output goes low.
COMP_INT_RISE to generate an interrupt when the comparator output goes high.
COMP_INT_BOTH to generate an interrupt when the comparator output goes low or high.
The COMP_ASRCP_xxx term can take on the following values:
COMP_ASRCP_PIN to use the dedicated Comp+ pin as the reference voltage.
COMP_ASRCP_PIN0 to use the Comp0+ pin as the reference voltage (this the same as
COMP_ASRCP_PIN for the comparator 0).
COMP_ASRCP_REF to use the internally generated voltage as the reference voltage.
The COMP_OUTPUT_xxx term can take on the following values:
COMP_OUTPUT_NORMAL to enable a non-inverted output from the comparator to a
device pin.
COMP_OUTPUT_INVERT to enable an inverted output from the comparator to a device
pin.
Returns:
None.
4.2.1.2 ROM_ComparatorIntClear
Clears a comparator interrupt.
Prototype:
void
ROM_ComparatorIntClear(uint32_t ui32Base,
uint32_t ui32Comp)
30 April 8, 2013
Loading...