Texas Instruments | mmWave IWR1xxx/IWR6xxx Bootloader Flow | Application notes | Texas Instruments mmWave IWR1xxx/IWR6xxx Bootloader Flow Application notes

Texas Instruments mmWave IWR1xxx/IWR6xxx Bootloader Flow Application notes
Application Report
SWRA627 – October 2018
IWR6843 Bootloader Flow
Naveen N. and Prathyusha Inuganti
ABSTRACT
This application report describes the IWR6843 bootloader flow.
1
2
3
Contents
Introduction ................................................................................................................... 2
Basic Bootloader Flow ..................................................................................................... 5
Programming Serial Data Flash Over UART (Bootloader Service) ................................................... 9
1
Simplified Representation of IWR6843 Interconnect .................................................................... 2
2
Flashing Mode of Bootloader............................................................................................... 3
3
Execution Mode of Bootloader ............................................................................................. 4
4
Basic Bootloader Flow Chart ............................................................................................... 5
5
Image Load Sequence ...................................................................................................... 6
6
ROM-Assisted Image Download Sequence .............................................................................. 7
7
Bootmode – SPI
8
Host ← → IWR Device UART Communication ........................................................................ 11
9
Flashing Sequence ......................................................................................................... 12
List of Figures
.............................................................................................................
8
List of Tables
1
SOP Lines and Boot Modes ................................................................................................ 2
2
Supported Commands and Format ...................................................................................... 10
Trademarks
ARM, Cortex are registered trademarks of Arm Limited.
Macronix is a registered trademark of Macronix International Co., Ltd.
Spansion is a registered trademark of Spansion LLC.
All other trademarks are the property of their respective owners.
SWRA627 – October 2018
Submit Documentation Feedback
IWR6843 Bootloader Flow
Copyright © 2018, Texas Instruments Incorporated
1
Introduction
1
www.ti.com
Introduction
The IWR6843 device can be broadly split into three subsystems (see Figure 1), as follows:
• Master subsystem: ARM® Cortex®-R4F and associated peripherals, hosts the user application
• DSP subsystem: TI C674x and associated peripherals, hosts the user application
• Radar/Millimetre Wave Block: Programmed using predefined message transactions specified by TI
(reference driver provided by TI)
Unified
128 KB x 2
L2
ROM
Cache/
RAM
L1P
EDMA
32 KB
DSP
HWA
L1D
CRC
32 KB
JTAG
CRC
DSP/HWA Interconnect ± 128 bit @ 200 MHz
L3
HIL
TCM A 512 KB
TCM B 192 KB
Master Interconnect
Data
Handshake
Memory
ADC Buffer
Master
R4F
Mail
Box
MSS
DMA
32 KB
BSS Interconnect
and Radar Block
32 KB Ping-Pong
(static sharing
with R4F Space)
Interconnect
LVDS
SPI
UART
I 2C
QSPI
CAN
FD
PWM,
PMIC
CLK
Figure 1. Simplified Representation of IWR6843 Interconnect
User application components (R4F and DSP) are expected to be stored in the serial data flash (SDF)
interfaced to the IWR6843 device over the quad serial peripheral interface (QSPI) interface.
Master subsystem is the first programmable block to get activated after the IWR6843 device reset is
deasserted. The bootloader of the IWR6843 device is hosted in the read-only memory (ROM) of the
master subsystem, and takes control immediately.
From this point onward, the IWR6843 bootloader can operate in two modes: flashing and execution
The bootloader checks the state of the sense on power (SOP) I/Os – SOP lines driven externally for
choosing the specific mode (see Table 1).
Table 1. SOP Lines and Boot Modes
2
SOP2 (P9)
SOP1 (G13)
SOP0 (N13) Bootloader Mode and Operation
0
0
1
Functional mode
The device bootloader loads the user application from the QSPI serial flash to the
internal RAM and switches the control to it.
1
0
1
Flashing mode
The device bootloader spins in loop to allow flashing of the user application (or the
device firmware patch – supplied by TI).
0
1
1
Debug mode
The bootloader is bypassed and the R4F processor is halted. This lets the user
connect the emulator at a known point.
IWR6843 Bootloader Flow
SWRA627 – October 2018
Submit Documentation Feedback
Copyright © 2018, Texas Instruments Incorporated
Introduction
www.ti.com
Flashing mode of the bootloader allows an external entity to load the customer application image to the
SDF (see Figure 2).
Figure 2. Flashing Mode of Bootloader
SWRA627 – October 2018
Submit Documentation Feedback
IWR6843 Bootloader Flow
Copyright © 2018, Texas Instruments Incorporated
3
Introduction
www.ti.com
Execution (or functional) mode of the bootloader relocates the image stored in the SDF to the R4F and
DSP memory subsystems. Toward the end of this process, the bootloader passes the R4F application of
the control user. Unhalting (starting execution) of the DSP core is the responsibility of the user image (see
Figure 3).
Figure 3. Execution Mode of Bootloader
Key points
• TI’s embedded bootloader can load one primary user image (could have content for both R4F and
DSP).
• If the customer application requires handling of multiple images (factory programmed, back-up, and so
on), the customer must invest in a secondary bootloader.
4
IWR6843 Bootloader Flow
SWRA627 – October 2018
Submit Documentation Feedback
Copyright © 2018, Texas Instruments Incorporated
Basic Bootloader Flow
www.ti.com
2
Basic Bootloader Flow
At a high level, bootloader operation can be split into three phases (see Figure 4), as follows:
• Device initialization: the bootloader uses built-in self test (BIST) engines for hardware diagnostics (for
example, RAM tests).
• Setting up the root clock by starting the APLL. The root clock will be at 200 MHz.
• Checking SOP lines to proceed with either the flashing or execution mode.
Bootmode - UART
Flash Programming
Device Initialization,
APLL calibration
No
The following sequence is
on a per-command basis.
The flow is captured here
Device Management
over UART ± SOP5
SOP mode
Bootmode ± SPI
Functional mode SOP4
Flash program
Cmd over UART
Boot over
No
UART Cmd
Yes
Yes
Generate MCU clock out
(at XTAL/2)
Set up SPI.
Generate a HostIRQ to indicate
bootup completion and await
commands.
No
Flash present
Yes
Download MultiCore image
(BSS patch, MSS-DSS
application image) to SFLASH
Load BSS patch image over
UART to program memory
Bootmode - SFLASH
Load BSS patch image from SFLASH
to program memory
(Secure Boot in case of HS devices)
Wait Forever
Load MSS, DSS patch image over
UART to program memory
(Secure Boot in case of HS devices)
Command over
SPI
Load MSS, DSS patch image from
SFLASH to program memory
(Secure Boot in case of HS devices)
Load BSS patch image over
SPI to BSS program memory
Load MSS, DSS patch image
over SPI to program memory
Eclipse the MSS ROM with
RAM contents
MSS CPU reset
ROM Execution
RAM Execution
Begin execution from loaded
MSS image
Figure 4. Basic Bootloader Flow Chart
Key points
• In addition to the memories of the Radar subsystem, the bootloader loads to the following memories:
– MSS images – MSS TCMA and MSS TCMB (on IWR6843 ES1.0 samples, the load is restricted to
MSS TCMA program memory)
– DSP images – L1, L2, and L3 memories (on IWR6843 ES1.0 samples, the load is restricted to L2
and L3 memories)
SWRA627 – October 2018
Submit Documentation Feedback
IWR6843 Bootloader Flow
Copyright © 2018, Texas Instruments Incorporated
5
Basic Bootloader Flow
2.1
2.1.1
www.ti.com
Bootmode – SFLASH
Image Load Sequence
In functional mode, the bootloading of an image from the SDF is the first bootmode attempted by the
bootloader (see Figure 5). This bootmode involves the following steps:
1. Pinmux the QSPI pins of the IWR6843 device:
a. QSPI[0]: Ball R13
b. QSPI[1]: Ball N12
c. QSPI[2]: Ball R14
d. QSPI[3]: Ball P12
e. QSPI_CLK: Ball R12
f. QSPI_CS_N: Ball P11
2. QSPI is set up to operate at (system clock / 5) = (200/5) = 40 MHz.
3. The SFLASH discoverable parameters (SFDP) command is issued to retrieve the JEDEC compliant
response, which includes information regarding the SFLASH capabilities and command set. When the
SFDP response is received, the information is used to communicate with the SDF and further interpret
the contents and load the images.
Figure 5. Image Load Sequence
Key points
• The ROM bootloader performs the read from the SDF, based on the highest capability mode (quad,
dual, or single) as published by the SDF in response to the SFDP command.
• For SDF variants that support quad mode, the quad mode commands are issued; if the quad enable
(QE) bit is not set, the communication will fail. In such cases, the load flow assumes that the QE bit in
the SDF is already set.
• Fallback images: the bootloader supports loading of images from the following locations as a fallback
mechanism if one of the images is corrupted in the SDF. The locations of the images are:
– META IMG1(SDF offset – 0x0)
– META IMG2(SDF offset – 0x80000)
– META IMG3(SDF offset – 0x100000)
– META IMG4(SDF offset – 0x180000)
See the Image Creator user guide available in the mmWave SDK release for image format details.
6
IWR6843 Bootloader Flow
SWRA627 – October 2018
Submit Documentation Feedback
Copyright © 2018, Texas Instruments Incorporated
Basic Bootloader Flow
www.ti.com
2.1.2
ROM-Assisted Image Download Sequence
The ROM-assisted image download sequence is entered by placing the device in flashing mode. See
Section 3, for further details on the handshake with an external host to receive the image. Figure 6 shows
the communication with the SDF.
Figure 6. ROM-Assisted Image Download Sequence
Key points
• The ROM-assisted download should work with all flash variants that allow for memory-mapped mode
and Page program command (0x2), with one dummy byte and 24-bit addressing.
• Setting the QE bit varies from one SDF vendor to another. The ROM bootloader supports setting the
QE bit for Spansion® and Macronix® variants (certain specific part variants only) in this flow.
• In addition to a checksum-based integrity check for every packet received over the UART, a CRC32based integrity check is performed over the complete image. The CRC32 is computed incrementally as
the packets are received and written to the SDF.
2.2
Bootmode – SPI
In functional mode, if and only if the detection of the SDF fails (concluded by an invalid response to the
SFDP command over the QSPI lines), the bootloader enters the SPI-based bootloading mode. This mode
involves the following steps:
1. Pinmux the SPI pins of the IWR6843 device:
a. SPIA_MOSI: Ball D13
b. SPIA_MISO: Ball E14
c. SPIA_CLK: Ball E13
d. SPIA_CS_N: Ball E15
e. SPI_HOST_INTR: Ball P13
2. Follow the communication protocol used by the mmWave SDK mmWaveLink rlDeviceFileDownload
API (described in the mmWaveLink API Doxygen documentation referenced in the mmWave SDK User
Guide) to communicate with an external host to receive the images to be loaded as message packets
over the SPI.
3. Once the loading of all images is complete, the ROM is eclipsed and execution control is transferred to
the loaded application in MSS TCMA.
SWRA627 – October 2018
Submit Documentation Feedback
IWR6843 Bootloader Flow
Copyright © 2018, Texas Instruments Incorporated
7
Basic Bootloader Flow
www.ti.com
Figure 7 shows the handshake with the external host.
Device
External host
MSS ROM
Bootup completion
AR_AE_DEV_MSSPOWERUPDONE_SB
AR_DEV_FILE_DOWNLOAD_SB
(REM_CHUNKS (N-1), FILE_TYPE,
FILE_LENGTH and MetaImage (1/N))
AR_ACK_MSG
AR_DEV_FILE_DOWNLOAD_SB
(REM_CHUNKS (N-2),MetaImage (2/N))
AR_ACK_MSG
Image download over
SPI
Bootloading
over SPI
AR_DEV_FILE_DOWNLOAD_SB
(REM_CHUNKS (0),MetaImage (N/N))
AR_ACK_MSG
AR_AE_MSS_BOOTERRORSTATUS_SB
(Indication of bootup status)
In case of no errors,
Eclipse of ROM and
handoff to application
Application Execution
Figure 7. Bootmode – SPI
8
IWR6843 Bootloader Flow
SWRA627 – October 2018
Submit Documentation Feedback
Copyright © 2018, Texas Instruments Incorporated
Programming Serial Data Flash Over UART (Bootloader Service)
www.ti.com
3
Programming Serial Data Flash Over UART (Bootloader Service)
The IWR6843 device from TI can be configured to operate as an autonomous radar sensor. In this
configuration, the user application and TI firmware patches are hosted in an SDF interfaced to the
IWR6843 over the QSPI port.
SDF programming supports downloading meta images that are a combination of the following
components:
• User application image for R4F (master subsystem)
• User application image for C674 (DSP subsystem)
• TI Radar Block patches
The flash programmer connects to the device over UART. Specifics are as follows:
• MSS_UARTA of the IWR6843 device:
– RX: Ball N4
– TX: Ball N5
• Baud rate: 115200
• Maximum Data Chunk Size: 240bytes
NOTE: Commands ‘Write File to SFLASH’ and ‘Write File to SRAM’ support a maximum data chunk
size of 240 bytes only.
The file is split into N commands where
N = (file size/240) + ((file size%240) ? 1 : 0)
3.1
Binary File Format
The target binary file is composed of the following sections:
• Header
• R4F application
• DSP application
• TI Radar Block patch
The mmWave SDK package for the IWR6843 device from TI includes the Image Creator utility, which
constructs the complete image with the previously listed components.
3.2
Flash Programming Sequence
1. Boot the device in SOP 5 mode (see Table 1).
2. Open the UniFlash tool (as listed in the mmWave SDK for IWR6843).
3. Connect to the device over the UARTA com port (the device expects a UART break signal – this is
generated by the UniFlash tool).
4. Flash the desired images <META_IMAGE1/ META_IMAGE2/ META_IMAGE3/ META_IMAGE4>
SWRA627 – October 2018
Submit Documentation Feedback
IWR6843 Bootloader Flow
Copyright © 2018, Texas Instruments Incorporated
9
Programming Serial Data Flash Over UART (Bootloader Service)
3.3
www.ti.com
Supported Commands and Format
Table 2 lists the supported commands and format.
Table 2. Supported Commands and Format
Command
10
Command
ID
Description
PING
0x20
The device responds with ACK
OPEN FILE
0x21
Command that gives details about the type of
file being downloaded
WRITE FILE to
SFLASH
0x24
Command that gives the content of the file to
write to SFLASH
WRITE FILE to RAM
0x26
Command that gives the content of the file
and the file is directly written to RAM
CLOSE FILE
0x22
Command that indicates the end-of-file
download
GET STATUS
0x23
Command that requests the status of the
previous command. The device responds with
the status of the previous command issued.
ERASE DEVICE
0x28
Command to erase the contents of the
SFALSH
GET VERSION
0x2F
Command that requests the version of the
ROM. Device responds with the version
information.
ACK response
0xCC
Response from the device
IWR6843 Bootloader Flow
Fields
File size: total file size being downloaded.
File type: META IMG1(4), META IMG2(5),
META IMG3(6), and META IMG4(7)
Storage type: 2- SFLASH, 4 - SRAM
Storage type: 2- SFLASH and 4- SRAM
SWRA627 – October 2018
Submit Documentation Feedback
Copyright © 2018, Texas Instruments Incorporated
Programming Serial Data Flash Over UART (Bootloader Service)
www.ti.com
Figure 8 shows the supported commands that can be issued to the IWR device during the flash
programming process and the various responses from the IWR device.
HOST COMMANDS TO Device
GENERIC COMMAND
STRUCTURE
OPEN
COMMAND
WRITE TO FLASH
COMMAND
WRITE TO RAM
COMMAND
CLOSE
COMMAND
PING
COMMAND
ERASE
COMMAND
GET STATUS
COMMAND
GET VERSION
COMMAND
(length -2) bytes
Max size: (243 ± 2) bytes
1 byte
2 bytes
1 byte
SYNC
(0xAA)
LENGTH
CHEC
KSUM
1 byte
2 bytes
1 byte
1 byte
4 bytes
4 bytes
4 bytes
4 bytes
0xAA
0x13
CHEC
KSUM
0x21
FILE SIZE
STORAGE TYPE
FILE TYPE
RESERVED
1 byte
2 bytes
1 byte
1 byte
0xAA
LENGTH
CHEC
KSUM
0x24
1 byte
2 bytes
1 byte
1 byte
0xAA
LENGTH
CHEC
KSUM
0x26
1 byte
2 bytes
1 byte
1 byte
4 bytes
0xAA
0x7
CHEC
KSUM
0x22
STORAGE TYPE
1 byte
2 bytes
1 byte
1 byte
0xAA
0x3
0x20
0x20
1 byte
2 bytes
1 byte
1 byte
0xAA
0x3
0x28
0x28
1 byte
2 bytes
1 byte
1 byte
0xAA
0x3
0x23
0x23
1 byte
2 bytes
1 byte
1 byte
0xAA
0x3
0x2F
0x2F
PAYLOAD
(length -3) bytes
Max size: (243 ± 3) bytes
DATA CHUNCK
(length -3) bytes
Max size: (243 ± 3) bytes
DATA CHUNCK
Device RESPONSE TO HOST
GENERIC RESPONSE
STRUCTURE
ACK RESPONSE
STATUS RESPONSE
VERSION RESPONSE
(length -2) bytes
Max size: (256 ± 2) bytes
2 bytes
1 byte
LENGTH
CHEC
KSUM
2 bytes
1 byte
2 bytes
0x4
0xCC
0x00CC
2 bytes
1 byte
1 byte
0x3
CHEC
KSUM
STAT
US
2 bytes
1 byte
0xE
CHECK
SUM
PAYLOAD
4 bytes
ROM VERSION
INFORMATION
8 bytes
RESERVED
Figure 8. Host ← → IWR Device UART Communication
The 8-bit checksum in each UART command is a simple unsigned sum of the unsigned values of all the
bytes of the payload of the command, where only the least-significant 8 bits of the sum are kept. For
example, the pseudo-code to calculate the checksum would be:
checksum = 0
for each byte in the payload, checksum = (checksum + (unsigned) byte) AND (0xFF)
SWRA627 – October 2018
Submit Documentation Feedback
IWR6843 Bootloader Flow
Copyright © 2018, Texas Instruments Incorporated
11
Programming Serial Data Flash Over UART (Bootloader Service)
www.ti.com
The STATUS RESPONSE returned from the device is the bootloader error status based on the last
actionable command executed. Actionable commands include OPEN, WRITE TO FLASH, CLOSE, and
ERASE. Status commands like PING, GET STATUS, and GET VERSION do not affect the error status
reported in the STATUS RESPONSE. The possible returned STATUS values are as follows.
0x00 = INITIAL_STATUS (before any actionable commands are issued)
0x40 = SUCCESS
0x4B = ACCESS_IN_PROGRESS
Any RESERVED fields in commands sent from the host should be set to 0x0.
3.4
Flashing Sequence
Figure 9 shows the flash programming sequence. The initial handshake starts with a UART break issued
by the external host. This break is followed by the command sequence in Figure 9. The bootloader uses a
command-response protocol. So the host should wait after sending each command until an ACK response
is received from the device. Please note that the GET STATUS command is unique in that it returns only
the STATUS RESPONSE message without sending an ACK response.
Device
External host
Bootup
Wait for UART Break
UART Break
ACK_MSG
OPEN Command
ACK_MSG
WRITE Command (MetaImage (1/N))
ACK_MSG
WRITE Command (MetaImage (2/N))
ACK_MSG
Image download over
UART
Writing to SFLASH,
Compute CRC per
packet
WRITE Command (MetaImage (N/N))
ACK_MSG
Ensure the CRC
matches
CLOSE Command
ACK_MSG/NACK_MSG
Figure 9. Flashing Sequence
12
IWR6843 Bootloader Flow
SWRA627 – October 2018
Submit Documentation Feedback
Copyright © 2018, Texas Instruments Incorporated
www.ti.com
Programming Serial Data Flash Over UART (Bootloader Service)
Bootmode – UART: The bootloading over the UART also follows the same sequence as previously
mentioned (WRITE command – 0x26). The META IMAGE received over the UART is interpreted and
loaded to the appropriate memories. Once the bootloading is complete, the ROM is eclipsed and
execution control is passed to the application residing in MSS TCMA. The META IMAGE should not have
the CRC32 appended (unlike the image to be flashed).
Key Points:
• The host processor needs to split the each file/image into smaller chunks and send each chunk in a
WRITE TO FLASH command. The LENGTH field of the command should be set to the total payload
size (which includes the image data chunk and 1 byte for the 0x24 opcode) + 2. The max chunk size is
243 - 3 = 240 bytes.
• The byte order for the words in the UART commands is big-endian (i.e. transmit most-significant byte
first). The BSS/MSS/Config images should be transmitted as bytes in the order they are in the binary
files.
• The ERASE command is not required but can be used to make sure the entire SDFLASH is cleared
before the new images are written.
• The GET STATUS command is not required but can be used to check status of device.
• The GET VERSION command not required but can be used by the host processor to allow it to
operate differently depending on the device silicon version.
SWRA627 – October 2018
Submit Documentation Feedback
IWR6843 Bootloader Flow
Copyright © 2018, Texas Instruments Incorporated
13
IMPORTANT NOTICE AND DISCLAIMER
TI PROVIDES TECHNICAL AND RELIABILITY DATA (INCLUDING DATASHEETS), DESIGN RESOURCES (INCLUDING REFERENCE
DESIGNS), APPLICATION OR OTHER DESIGN ADVICE, WEB TOOLS, SAFETY INFORMATION, AND OTHER RESOURCES “AS IS”
AND WITH ALL FAULTS, AND DISCLAIMS ALL WARRANTIES, EXPRESS AND IMPLIED, INCLUDING WITHOUT LIMITATION ANY
IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE OR NON-INFRINGEMENT OF THIRD
PARTY INTELLECTUAL PROPERTY RIGHTS.
These resources are intended for skilled developers designing with TI products. You are solely responsible for (1) selecting the appropriate
TI products for your application, (2) designing, validating and testing your application, and (3) ensuring your application meets applicable
standards, and any other safety, security, or other requirements. These resources are subject to change without notice. TI grants you
permission to use these resources only for development of an application that uses the TI products described in the resource. Other
reproduction and display of these resources is prohibited. No license is granted to any other TI intellectual property right or to any third
party intellectual property right. TI disclaims responsibility for, and you will fully indemnify TI and its representatives against, any claims,
damages, costs, losses, and liabilities arising out of your use of these resources.
TI’s products are provided subject to TI’s Terms of Sale (www.ti.com/legal/termsofsale.html) or other applicable terms available either on
ti.com or provided in conjunction with such TI products. TI’s provision of these resources does not expand or otherwise alter TI’s applicable
warranties or warranty disclaimers for TI products.
Mailing Address: Texas Instruments, Post Office Box 655303, Dallas, Texas 75265
Copyright © 2018, Texas Instruments Incorporated
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Related manuals

Download PDF

advertising