mmWaveLink Framework

Introduction

TI Automotive and Industrial mmWave Radar products are highly-integrated 77GHz CMOS millimeter wave devices.The devices integrate all of the RF and Analog functionality, including VCO, PLL, PA, LNA, Mixer and ADC for multiple TX/RX channels into a single chip.

  1. The AWR1243 is an RF transceiver device and it includes 4 receiver channels and 3 transmit channels in a single chip. AWR1243 also support multi-chip cascading.
  2. The AWR1443/IWR1443 is a mmwave radar-on-a-chip device, which includes 4 receive channels and 3 transmit channels and additionally an Cortex R4F and hardware FFT accelerator.
  3. AWR1642 and IWR1642 are mmwave radar-on-a-chip device, which includes 4 receive channels and 2 transmit channels and additionally an Cortex R4F and C674x DSP for signal processing

TI mmWave radar devices include a mmwave front end or BIST (Built-in Self-Test) processor, which is responsible to configure the RF/Analog and digital front-end in real-time, as well as to periodically schedule calibration and functional safety monitoring.This enables the mmwave front-end(BIST processor) to be self-contained and capable of adapting itself to handle temperature and ageing effects, and to enable significant ease-of-use from an external host perspective.

TI mmwave front end is a closed subsystem whose internal blocks are configurable using messages coming over mailbox.
TI mmWaveLink provides APIs generates these message and sends it to mmwave front end over mailbox. It also includes acknowledement and CRC for each message to provide a reliable communication

TI mmWaveLink Framework:

Modules

To make it simple, TI's mmWaveLink framework capabilities are divided into modules.
These capabilities include device control, RF/Analog configuration, ADC configuration, Data path(LVDS/CSI2) cofiguration, FMCW chirp configuration and more.
Listed below are the various modules in the mmWaveLink framework:

  1. Device - Controls mmwave radar device which include:
     Initialization, such as: mmwave device power On/Off, Firmware Patch download
     Cascade device configuration such as Add/Connect multiple mmWave devices
    
  2. Sensor - The RF/Sensor Configuration module controls the different HW blocks inside mmWave Front end.

    mmwave_frontend.png

    mmWave Front End has below key blocks

    1. Chirp sequencer (Radar Timing Engine) - This block is responsible for constructing the sequence of FMCW chirps or frames and programming the timing engine
    2. Rx/Tx Channel - This defines how many Rx and Tx channel needs to be enabled. Also it defines how to configure the mmWave front end in cascade mode for Imaging Radar
    3. Rx Analog Chain - This defines how the received signal is mixed and how different filters in the chain can be configured
    4. ADC and Digital Front End Configuration - This defines how the IF data is digitized and how it is sampled for further processing in the DSP or Hardware Accelerator. Same ADC data can be sent over LVDS/CSI2 interface to an extenal processor

    The configuration APIs can further be categorized as.

    1. mmwave static configuration, such as: Tx and Rx channel, ADC configuration etc
    2. mmwave dynamic configuration, such as FMCW Chirp configuration, profile configuration
    3. mmwave advance configuration such as Binary phase modulation, Dynamic power save etc
    4. mmwave sensor control, such as: Frame start/stop
  3. Data Path - The Data path Configuration module controls the high speed interface in mmWave device.

    data_path.png

    The configuration APIs include.

    1. High Speed interface(LVDS/CSI2) selection
    2. Data format and rate configuration
    3. ADC, Chirp Profile(CP), Chirp Quality(CQ) data transfer sequence
    4. Lane configurations
    5. LVDS/CSI2 specific configuration
  4. Monitoring - The Monitoring/Calibration module configures the calibration and functional safety monitoring in mmWave device

    TI mmWave Front end includes built-in processor that is programmed by TI to handle RF calibrations and functional safety monitoring. The RF calibrations ensure that the performance of the device is maintained across temperature and process corners

  5. Communication Protocol - The mmWave communication protocol ensures reliable communication between host(internal or external) and mmWave Front end.
    1. It is a simple stop and wait protocol. Each message needs to be acknowledged by receiver before next message can be sent.
    2. Messages are classifieds as "Command", "Response" and "Asynchronous Event"
    3. If Command can not be processed immediately, ACK response is sent immediately (If requested). "Asynchronous Event" is sent upon completion of the command execution.

      comm_prot.png

Porting Guide

The porting of the mmWaveLink driver to any new platform is based on few simple steps. This guide takes you through this process step by step. Please follow the instructions carefully to avoid any problems during this process and to enable efficient and proper work with the device. Please notice that all modifications and porting adjustments of the driver should be made in the application only and driver should not be modified. Changes in the application file will ensure smoothly transaction to new versions of the driver at the future!

Step 1 - Define mmWaveLink client callback structure

The mmWaveLink framework is ported to different platforms using mmWaveLink client callbacks. These callbacks are grouped as different structures such as OS callbacks, Communication Interface callbacks and others. Application needs to define these callbacks and initialize the mmWaveLink framework with the structure.

rlClientCbs_t clientCtx = { 0 };
rlReturnVal_t retVal;
rlUInt32_t deviceMap = RL_DEVICE_MAP_CASCADED_1;

Refer to rlClientCbs_t for more details

Step 2 - Implement Communication Interface Callbacks

The mmWaveLink device support several standard communication protocol among SPI and MailBox Depending on device variant, one need to choose the communication channel. For e.g xWR1443/xWR1642/xWR1843 requires Mailbox interface and AWR1243 supports SPI interface. The interface for this communication channel should include 4 simple access functions:

  1. rlComIfOpen
  2. rlComIfClose
  3. rlComIfRead
  4. rlComIfWrite
clientCtx.comIfCb.rlComIfOpen = Host_spiOpen;
clientCtx.comIfCb.rlComIfClose = Host_spiClose;
clientCtx.comIfCb.rlComIfRead = Host_spiRead;
clientCtx.comIfCb.rlComIfWrite = Host_spiWrite;

Refer to rlComIfCbs_t for interface details

Step 3 - Implement Device Control Interface

The mmWaveLink driver internally powers on/off the mmWave radar device. The exact implementation of these interface is platform dependent, hence you need to implement below functions:

  1. rlDeviceEnable
  2. rlDeviceDisable
  3. rlRegisterInterruptHandler
clientCtx.devCtrlCb.rlDeviceDisable = Host_disableDevice;
clientCtx.devCtrlCb.rlDeviceEnable = Host_enableDevice;
clientCtx.devCtrlCb.rlDeviceMaskHostIrq = Host_spiIRQMask;
clientCtx.devCtrlCb.rlDeviceUnMaskHostIrq = Host_spiIRQUnMask;
clientCtx.devCtrlCb.rlRegisterInterruptHandler = Host_registerInterruptHandler;
clientCtx.devCtrlCb.rlDeviceWaitIrqStatus = Host_deviceWaitIrqStatus;

Refer to rlDeviceCtrlCbs_t for interface details

Step 4 - Implement Event Handlers

The mmWaveLink driver reports asynchronous event indicating mmwave radar device status, exceptions etc. Application can register this callback to receive these notification and take appropriate actions

clientCtx.eventCb.rlAsyncEvent = Host_asyncEventHandler;

Refer to rlEventCbs_t for interface details

Step 5 - Implement OS Interface

The mmWaveLink driver can work in both OS and NonOS environment. If Application prefers to use operating system, it needs to implement basic OS routines such as tasks, mutex and Semaphore

clientCtx.osiCb.mutex.rlOsiMutexCreate = Host_osiLockObjCreate;
clientCtx.osiCb.mutex.rlOsiMutexLock = Host_osiLockObjLock;
clientCtx.osiCb.mutex.rlOsiMutexUnLock = Host_osiLockObjUnlock;
clientCtx.osiCb.mutex.rlOsiMutexDelete = Host_osiLockObjDelete;
clientCtx.osiCb.sem.rlOsiSemCreate = Host_osiSyncObjCreate;
clientCtx.osiCb.sem.rlOsiSemWait = Host_osiSyncObjWait;
clientCtx.osiCb.sem.rlOsiSemSignal = Host_osiSyncObjSignal;
clientCtx.osiCb.sem.rlOsiSemDelete = Host_osiSyncObjDelete;
clientCtx.osiCb.queue.rlOsiSpawn = Host_osiSpawn;
clientCtx.timerCb.rlDelay = Host_osiSleep;

Refer to rlOsiCbs_t for interface details

Step 6 - Implement CRC Interface

The mmWaveLink driver uses CRC for message integrity. If Application prefers to use CRC, it needs to implement CRC routine.

clientCtx.crcCb.rlComputeCRC = Host_computeCRC;

Refer to rlCrcCbs_t for interface details

Step 7 - Implement Debug Interface

The mmWaveLink driver can print the debug message. If Application prefers to enable debug messages, it needs to implement debug callback.

Refer to rlDbgCb_t for interface details

Final Step - Initializing mmWaveLink Driver

Once all the above Interfaces are implemented, Application need to fill these callbacks in rlClientCbs_t and Initialize mmWaveLink by passing the client callbacks. Application also need to define where the mmWaveLink driver is running, for e.g, External Host in case of AWR1243 or MSS/DSS in case of xWR1642/xWR1843.

clientCtx.platform = RL_PLATFORM_HOST;
clientCtx.arDevType = RL_AR_DEVICETYPE_12XX;
retVal = rlDevicePowerOn(deviceMap, clientCtx);

Big Endian Support

The mmWaveLink driver by default is enabled for Little Endian host. Support for Big Endian is provided as compile time option using a Pre-processor Macro MMWL_BIG_ENDIAN.
For memory optimizations, mmWaveLink doesn't swap the data elements in structure buffer. It is the responsibility of the application to swap multi byte data elements before passing the structure buffer to mmWaveLink API. Since SPI word-size is 16bit, Swap of 32 bit fields such as integer needs to be done at 16bit boundary.


Copyright 2018, Texas Instruments Incorporated