IWR6843 Bootloader Flow - TI.com · 2018. 10. 23. · 128 KB x 2 32 KB Ping-Pong 32 KB 32 KB 32 KB 192 KB 512 KB Cache/ RAM (static sharing with R4F Space) HWA CAN FD Introduction

1SWRA627–October 2018Submit Documentation Feedback

Copyright © 2018, Texas Instruments Incorporated

IWR6843 Bootloader Flow

Application ReportSWRA627–October 2018


Naveen N. and Prathyusha Inuganti

ABSTRACTThis application report describes the IWR6843 bootloader flow.

Contents1 Introduction ................................................................................................................... 22 Basic Bootloader Flow ..................................................................................................... 53 Programming Serial Data Flash Over UART (Bootloader Service) ................................................... 9

List of Figures

1 Simplified Representation of IWR6843 Interconnect.................................................................... 22 Flashing Mode of Bootloader............................................................................................... 33 Execution Mode of Bootloader ............................................................................................. 44 Basic Bootloader Flow Chart ............................................................................................... 55 Image Load Sequence ...................................................................................................... 66 ROM-Assisted Image Download Sequence.............................................................................. 77 Bootmode – SPI ............................................................................................................. 88 Host ← → IWR Device UART Communication ........................................................................ 119 Flashing Sequence......................................................................................................... 12

List of Tables

1 SOP Lines and Boot Modes................................................................................................ 22 Supported Commands and Format ...................................................................................... 10

TrademarksARM, 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.

http://www.go-dsp.com/forms/techdoc/doc_feedback.htm?litnum=SWRA627

DSP/HWA Interconnect ± 128 bit @ 200 MHz Master Interconnect

Interconnect

ADC Buffer

L3

DataHandshake

Memory

LVDS

DSP

L2

EDMA

MSSDMA

CRC JTAG CRC HIL

MasterR4F

ROM

TCM A

TCM B

L1P

L1D

MailBox

SPI UARTI2C QSPI

PWM,PMICCLK

BSS Interconnectand Radar Block

Unified128 KB x 2

32 KB Ping-Pong32 KB

32 KB

32 KB

192 KB

512 KB

Cache/RAM

(static sharing with R4F Space)

HWA

CANFD

Introduction www.ti.com

2 SWRA627–October 2018Submit Documentation Feedback



1 IntroductionThe 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)

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 isdeasserted. The bootloader of the IWR6843 device is hosted in the read-only memory (ROM) of themaster 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 forchoosing the specific mode (see Table 1).

Table 1. SOP Lines and Boot Modes

SOP2 (P9) SOP1 (G13) SOP0 (N13) Bootloader Mode and Operation

0 0 1Functional modeThe device bootloader loads the user application from the QSPI serial flash to theinternal RAM and switches the control to it.

1 0 1Flashing modeThe device bootloader spins in loop to allow flashing of the user application (or thedevice firmware patch – supplied by TI).

0 1 1Debug modeThe bootloader is bypassed and the R4F processor is halted. This lets the userconnect the emulator at a known point.

http://www.ti.comhttp://www.go-dsp.com/forms/techdoc/doc_feedback.htm?litnum=SWRA627

www.ti.com Introduction




Flashing mode of the bootloader allows an external entity to load the customer application image to theSDF (see Figure 2).

Figure 2. Flashing Mode of Bootloader


Introduction www.ti.com




Execution (or functional) mode of the bootloader relocates the image stored in the SDF to the R4F andDSP memory subsystems. Toward the end of this process, the bootloader passes the R4F application ofthe control user. Unhalting (starting execution) of the DSP core is the responsibility of the user image (seeFigure 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.


SOP mode

Download MultiCore image (BSS patch, MSS-DSS

application image) to SFLASH

Flash programCmd over UART

Device Managementover UART ± SOP5

Functional mode SOP4

Flash present

Load BSS patch image from SFLASH to program memory

(Secure Boot in case of HS devices)

Load MSS, DSS patch image from SFLASH to program memory


Command overSPI

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

Begin execution from loaded MSS image

Wait Forever

Set up SPI.Generate a HostIRQ to indicate

bootup completion and await commands.

ROM Execution

RAM Execution

Device Initialization, APLL calibration

Generate MCU clock out (at XTAL/2)

Load BSS patch image over UART to program memory

Load MSS, DSS patch image over UART to program memory


Bootmode - UARTFlash Programming

Bootmode - SFLASH

Bootmode ± SPI

Boot over

UART Cmd

Yes

YesYes

The following sequence is on a per-command basis. The flow is captured here

No

No

No

www.ti.com Basic Bootloader Flow




2 Basic Bootloader FlowAt 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.

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 toMSS TCMA program memory)

– DSP images – L1, L2, and L3 memories (on IWR6843 ES1.0 samples, the load is restricted to L2and L3 memories)


Basic Bootloader Flow www.ti.com




2.1 Bootmode – SFLASH

2.1.1 Image Load SequenceIn functional mode, the bootloading of an image from the SDF is the first bootmode attempted by thebootloader (see Figure 5). This bootmode involves the following steps:1. Pinmux the QSPI pins of the IWR6843 device:

a. QSPI[0]: Ball R13b. QSPI[1]: Ball N12c. QSPI[2]: Ball R14d. QSPI[3]: Ball P12e. QSPI_CLK: Ball R12f. 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 theSFDP response is received, the information is used to communicate with the SDF and further interpretthe 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 inthe SDF is already set.

• Fallback images: the bootloader supports loading of images from the following locations as a fallbackmechanism 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.


www.ti.com Basic Bootloader Flow




2.1.2 ROM-Assisted Image Download SequenceThe ROM-assisted image download sequence is entered by placing the device in flashing mode. SeeSection 3, for further details on the handshake with an external host to receive the image. Figure 6 showsthe 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 CRC32-

based integrity check is performed over the complete image. The CRC32 is computed incrementally asthe packets are received and written to the SDF.

2.2 Bootmode – SPIIn functional mode, if and only if the detection of the SDF fails (concluded by an invalid response to theSFDP command over the QSPI lines), the bootloader enters the SPI-based bootloading mode. This modeinvolves the following steps:1. Pinmux the SPI pins of the IWR6843 device:

a. SPIA_MOSI: Ball D13b. SPIA_MISO: Ball E14c. SPIA_CLK: Ball E13d. SPIA_CS_N: Ball E15e. SPI_HOST_INTR: Ball P13

2. Follow the communication protocol used by the mmWave SDK mmWaveLink rlDeviceFileDownloadAPI (described in the mmWaveLink API Doxygen documentation referenced in the mmWave SDK UserGuide) to communicate with an external host to receive the images to be loaded as message packetsover the SPI.

3. Once the loading of all images is complete, the ROM is eclipsed and execution control is transferred tothe loaded application in MSS TCMA.


Device External host

AR_AE_DEV_MSSPOWERUPDONE_SB

MSS ROMBootup completion

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

AR_DEV_FILE_DOWNLOAD_SB(REM_CHUNKS (0),MetaImage (N/N))

AR_ACK_MSG

AR_AE_MSS_BOOTERRORSTATUS_SB(Indication of bootup status)

Bootloading over SPI

Image download over SPI

In case of no errors,Eclipse of ROM and

handoff to application

Application Execution

Basic Bootloader Flow www.ti.com




Figure 7 shows the handshake with the external host.

Figure 7. Bootmode – SPI


www.ti.com Programming Serial Data Flash Over UART (Bootloader Service)




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 thisconfiguration, the user application and TI firmware patches are hosted in an SDF interfaced to theIWR6843 over the QSPI port.

SDF programming supports downloading meta images that are a combination of the followingcomponents:• 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 chunksize 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 FormatThe 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, whichconstructs the complete image with the previously listed components.

3.2 Flash Programming Sequence1. 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


Programming Serial Data Flash Over UART (Bootloader Service) www.ti.com




3.3 Supported Commands and FormatTable 2 lists the supported commands and format.

Table 2. Supported Commands and Format

CommandCommand

ID Description FieldsPING 0x20 The device responds with ACK

OPEN FILE 0x21 Command that gives details about the type offile being downloaded

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

WRITE FILE toSFLASH 0x24

Command that gives the content of the file towrite to SFLASH

WRITE FILE to RAM 0x26 Command that gives the content of the fileand the file is directly written to RAM

CLOSE FILE 0x22 Command that indicates the end-of-filedownload Storage type: 2- SFLASH and 4- SRAM

GET STATUS 0x23Command that requests the status of theprevious command. The device responds withthe status of the previous command issued.

ERASE DEVICE 0x28 Command to erase the contents of theSFALSH

GET VERSION 0x2FCommand that requests the version of theROM. Device responds with the versioninformation.

ACK response 0xCC Response from the device


SYNC(0xAA) LENGTH

CHECKSUM

PAYLOAD

2 bytes(length -2) bytes

Max size: (243 ± 2) bytes

0xAA 0x13CHECKSUM

0x21 FILE SIZE STORAGE TYPE FILE TYPE

2 bytes 4 bytes 4 bytes

0xAA LENGTHCHECKSUM

0x24

2 bytes

DATA CHUNCK

(length -3) bytesMax size: (243 ± 3) bytes

0xAA 0x7CHECKSUM

0x22

2 bytes

STORAGE TYPE

4 bytes

0xAA 0x3 0x20 0x20

2 bytes

0xAA 0x3 0x28 0x28

2 bytes

0xAA 0x3 0x23 0x23

0xAA 0x3 0x2F 0x2F

GENERIC COMMAND STRUCTURE

OPENCOMMAND

WRITE TO FLASHCOMMAND

CLOSECOMMAND

PINGCOMMAND

ERASECOMMAND

GET STATUSCOMMAND

GET VERSIONCOMMAND

LENGTHCHECKSUM

PAYLOAD

2 bytes(length -2) bytes

Max size: (256 ± 2) bytes

0x4 0xCC 0x00CC

2 bytes 2 bytes

0x3CHECKSUM

STATUS

2 bytes

0xECHECK

SUM

2 bytes

ROM VERSION INFORMATION

RESERVED

4 bytes 8 bytes

GENERIC RESPONSE STRUCTURE

ACK RESPONSE

STATUS RESPONSE

VERSION RESPONSE

HOST COMMANDS TO Device

Device RESPONSE TO HOST

0xAA LENGTHCHECKSUM

0x26

2 bytes

DATA CHUNCK

(length -3) bytesMax size: (243 ± 3) bytes

WRITE TO RAMCOMMAND

1 byte 1 byte

1 byte 1 byte 1 byte


1 byte1 byte1 byte


1 byte1 byte1 byte


2 bytes 1 byte 1 byte1 byte

2 bytes 1 byte 1 byte1 byte

1 byte

1 byte

1 byte 1 byte

1 byte

4 bytes 4 bytes

RESERVED





Figure 8 shows the supported commands that can be issued to the IWR device during the flashprogramming process and the various responses from the IWR device.

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 thebytes of the payload of the command, where only the least-significant 8 bits of the sum are kept. Forexample, the pseudo-code to calculate the checksum would be:

checksum = 0

for each byte in the payload, checksum = (checksum + (unsigned) byte) AND (0xFF)


Device External host

UART Break

BootupWait for UART Break

WRITE Command (MetaImage (1/N))

ACK_MSG

WRITE Command (MetaImage (2/N))

ACK_MSG

WRITE Command (MetaImage (N/N))

ACK_MSG

Writing to SFLASH,Compute CRC per

packet

Image download over UART

ACK_MSG

OPEN Command

ACK_MSG

CLOSE Command

ACK_MSG/NACK_MSG

Ensure the CRC matches

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 lastactionable command executed. Actionable commands include OPEN, WRITE TO FLASH, CLOSE, andERASE. Status commands like PING, GET STATUS, and GET VERSION do not affect the error statusreported in the STATUS RESPONSE. The possible returned STATUS values are as follows.0x00 = INITIAL_STATUS (before any actionable commands are issued)0x40 = SUCCESS0x4B = ACCESS_IN_PROGRESSAny RESERVED fields in commands sent from the host should be set to 0x0.

3.4 Flashing SequenceFigure 9 shows the flash programming sequence. The initial handshake starts with a UART break issuedby the external host. This break is followed by the command sequence in Figure 9. The bootloader uses acommand-response protocol. So the host should wait after sending each command until an ACK responseis received from the device. Please note that the GET STATUS command is unique in that it returns onlythe STATUS RESPONSE message without sending an ACK response.

Figure 9. Flashing Sequence






Bootmode – UART: The bootloading over the UART also follows the same sequence as previouslymentioned (WRITE command – 0x26). The META IMAGE received over the UART is interpreted andloaded to the appropriate memories. Once the bootloading is complete, the ROM is eclipsed andexecution control is passed to the application residing in MSS TCMA. The META IMAGE should not havethe 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 payloadsize (which includes the image data chunk and 1 byte for the 0x24 opcode) + 2. The max chunk size is243 - 3 = 240 bytes.

• The byte order for the words in the UART commands is big-endian (i.e. transmit most-significant bytefirst). The BSS/MSS/Config images should be transmitted as bytes in the order they are in the binaryfiles.

• The ERASE command is not required but can be used to make sure the entire SDFLASH is clearedbefore 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.


IMPORTANT NOTICE AND DISCLAIMER

TI PROVIDES TECHNICAL AND RELIABILITY DATA (INCLUDING DATASHEETS), DESIGN RESOURCES (INCLUDING REFERENCEDESIGNS), 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 ANYIMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE OR NON-INFRINGEMENT OF THIRDPARTY INTELLECTUAL PROPERTY RIGHTS.These resources are intended for skilled developers designing with TI products. You are solely responsible for (1) selecting the appropriateTI products for your application, (2) designing, validating and testing your application, and (3) ensuring your application meets applicablestandards, and any other safety, security, or other requirements. These resources are subject to change without notice. TI grants youpermission to use these resources only for development of an application that uses the TI products described in the resource. Otherreproduction and display of these resources is prohibited. No license is granted to any other TI intellectual property right or to any thirdparty 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 onti.com or provided in conjunction with such TI products. TI’s provision of these resources does not expand or otherwise alter TI’s applicablewarranties or warranty disclaimers for TI products.

Mailing Address: Texas Instruments, Post Office Box 655303, Dallas, Texas 75265Copyright © 2018, Texas Instruments Incorporated

http://www.ti.com/legal/termsofsale.htmlhttp://www.ti.com

IWR6843 Bootloader Flow1 Introduction2 Basic Bootloader Flow2.1 Bootmode – SFLASH2.1.1 Image Load Sequence2.1.2 ROM-Assisted Image Download Sequence

2.2 Bootmode – SPI

3 Programming Serial Data Flash Over UART (Bootloader Service)3.1 Binary File Format3.2 Flash Programming Sequence3.3 Supported Commands and Format3.4 Flashing Sequence

Important Notice

Documents

IWR6843 Bootloader Flow - TI.com · 2018. 10. 23. · 128 KB x 2 32 KB Ping-Pong 32 KB 32 KB 32 KB 192 KB 512 KB Cache/ RAM (static sharing with R4F Space) HWA CAN FD Introduction