SimpleLink is a trademark of Texas Instruments Incorporated.
Wi-Fi is a registered trademark of Wi-Fi Alliance.
Stellaris is a registered trademark of Texas Instruments Incorporated.
Arm and Cortex are registered trademarks of Arm Limited (or its subsidiaries) in the US and/or elsewhere.
All trademarks are the property of their respective owners.
The SimpleLink™ CC3100 and CC3200 devices are Wi-Fi® and networking devices that provide a comprehensive networking solution for low-cost and low-power microcontrollers (MCU) using a thin driver and simple API set.
Each product with an embedded CC3100 or CC3200 device onboard must also have a serial flash device connected. The serial flash must be formatted, and at a minimum programmed with the Service Pack, which contains necessary software updates and additional features. For the CC3200, a binary image running on the internal MCU processor must also be programmed.
There are several options for serial flash programming, as follows:
This application note describes in details additional options that leverage all the features UniFlash has to offer, but without the necessary connected PC. This option is referred to as Embedded Programming. To achieve embedded programming, bootloader protocol implemented over UART is described in detail.
The following sections describe the setup, bootloader protocol, and procedure of the embedded programming feature.
Several schemes can leverage full image programming over the UART, as follows.
The UART interface must be connected between the CC3100 or CC3200 device and the main processor. Only two pins are required, UART TX and UART RX. Flow control is not required.
The common configuration that applies to all chipsets follows:
In addition, the nHib/nReset pin is required and it must be have the ability to be temporarily pulled to GND during a reset to make the device go into bootloader mode.
For the CC3200 device, an additional SOP1 pin must be pulled up during the device reset to make the device go into bootloader mode.
The CC3100 and CC3200 bootloader protocol is a simple command-response protocol. The protocol is based on the protocol used by the Stellaris® LM Flash Programmer. The commands are serially executed and there are no unsolicited events during the bootloader phase.
Table 4-1 provides the general message format.
Length (Big Endian) | Checksum | Opcode | Data [optional] |
---|---|---|---|
2 bytes | 1 byte | 1 byte | n bytes |
The length includes all fields except the checksum (including the Length field itself), so in general:
Checksum is a simple hexadecimal addition of the Opcode and Data fields. Checksum is then clipped to occupy the least significant byte only.
Table 4-2 lists all the commands and responses of the bootloader protocol.
Item | Command or Response | Link |
---|---|---|
Get Storage List | Command | Section 4.3.2 |
Raw Storage Write | Command | Section 4.3.3 |
Get Version Information | Command | Section 4.3.4 |
Raw Storage Erase | Command | Section 4.3.5 |
Switch UART to APPS MCU | Command | Section 4.3.8 |
Ack | Response | Section 4.4.1 |
Version Info | Response | Section 4.4.6 |
Table 4-3 lists the Get Status command.
Description | |
---|---|
Brief | This command returns the status of the last command executed. Typically, this command must be invoked after every command sent to ensure that the previous command was successful or, if unsuccessful, to properly respond upon failure. The bootloader responds by sending a 1-byte packet containing the current status code. |
Opcode | 0x23 |
Direction | Host to target |
Response | Ack + Last Status response |
Format | [USHORT] Length (exclude checksum) [BYTE] Checksum (exclude length) [BYTE] Opcode |
Comments | Host responds back with Ack (Ack + Last Status response). |
Table 4-4 lists the Get Storage List command.
Description | |
---|---|
Brief | This command is used to fetch the list of existing storages. |
Opcode | 0x27 |
Direction | Host to target |
Response | Ack + Storage List response |
Format | [USHORT] Length (exclude checksum) [BYTE] Checksum (exclude length) [BYTE] Opcode |
Comments | — |
Table 4-5 lists the Raw Storage Write command.
Description | |
---|---|
Brief | This command triggers sending a chunk of raw storage data specified by StorageID, starting from a position specified by Offset and with a size specified by Length. |
Opcode | 0x2D |
Direction | Host to target |
Response | Ack |
Format | [USHORT] Length (exclude checksum) [BYTE] Checksum (exclude length) [BYTE] Opcode [UINT32] StorageID [UINT32] Offset (starting offset relative to the start of storage, in bytes) [UINT32] Length (amount of bytes to write) [BYTE Stream] Data |
Comments | The chunk is 4096 bytes and the Length must be smaller than (chunk_size-16). The SRAM storage ID is 0x0. The serial flash storage ID is 0x2. |
Table 4-6 lists the Get Version Info command.
Description | |
---|---|
Brief | This command is used to fetch version information of all cores and chip types. |
Opcode | 0x2F |
Direction | Host to target |
Response | Ack + Version info response |
Format | [USHORT] Length (exclude checksum) [BYTE] Checksum (exclude length) [BYTE] Opcode |
Comments | — |
Table 4-7 lists the Raw Storage Erase command.
Description | |
---|---|
Brief | This command erases the specified blocks (making them writable) from storage specified by StorageID. NumOfBlocks specifies the amount of blocks to erase and Offset specifies the offset of the first blocks from the start of the device. |
Opcode | 0x30 |
Direction | Host to target |
Response | Ack |
Format | [USHORT] Length (exclude checksum) [BYTE] Checksum (exclude length) [BYTE] Opcode [UINT32] StorageID [UINT32] Offset (in blocks, relative to start of device) [UINT32] NumOfBlocks (number of blocks to erase) |
Comments | The SRAM storage ID is 0x0. The serial flash storage ID is 0x2. |