AWR2243: How to use Profile & Chirp Ram

Hi,

AWR2243 is a sensor device which is configured using a Host. The mmwavelink API is running on the host and is used to configure the sensor

Regarding the Profile and Chirp memory available please see following

Regarding programming the chirp parameters using the mmWave Link API running on the Host please see the examples provided in the dfp release in the mmwave link folder

thank you

Cesar

Hi,

How to program for advanced profile chirp configurations ?

Is there any support for interleaved chirps from different modes of radar like SRR,MRR.

Not able to understand the use of subframe in multi-mode, please explain the

use case of subframe and bursts.  Or can subframe support interleaved like

first chirp from USRR, second from MRR and third from SRR ?

How this can be realized with  sub frames and burst ?

Hello Ben,

Please refer DFP user guide document (for AWR2243)

http://software-dl.ti.com/ra-processors/esd/MMWAVE-DFP-2G/latest/exports/mmwave_dfp_user_guide.pdf  

Section 11.1 explains advanced frame config well.

Now coming to your requirement:

1. advFrame config supports max of 4 sub-frame, and device supports max of 4 profiles.

2. Each sub-frame can connect to one unique profile-ID, which matches with SRR/MRR or USRR. So effectively within one advanced frame: each sub-frame corresponds to one usecase out of USRR/MRR/SRR.

3. Each sub-frame can contain single or multiple burst and all those burst will have same configuration (profile-ID).

4. On top of this chirp configuration can be updated during run time using either dynChirpConfig or advChirpConfig APIs.

I hope this explanation and document together clarify your question to fulfill the requirement.

 You can refer to the mmwave DFP example also for the usage of these APIs.

Regards,

Jitendra

Hi Jitendra,

>> 3. Each sub-frame can contain single or multiple burst and all those burst will have same configuration (profile-ID).

This means still all the chirps in a burst corresponds to one use-case. What I need is within a burst how to interleave chirps

from different use cases, like chirp1 USRR, chirp2-SRR,chirp3-MRR all within a single burst.

Are you saying the above can be achieved using the dynChirpConfig or advChirpConfig APIs at run-time ?

Statically I assume these all configs are stored in memory and at run-time for each chirp this mem location is read and used,

so using dynamic API this can be modified at run time. Is my understanding correct ?

How the radar front-end takes these configurations ? Is it operating on chirp basis, BIST programs for every chirp during inter chirp time ?

-ben

Ben Alexandar said:

Hi Jitendra,

>> 3. Each sub-frame can contain single or multiple burst and all those burst will have same configuration (profile-ID).

This means still all the chirps in a burst corresponds to one use-case. What I need is within a burst how to interleave chirps

from different use cases, like chirp1 USRR, chirp2-SRR,chirp3-MRR all within a single burst.

Are you saying the above can be achieved using the dynChirpConfig or advChirpConfig APIs at run-time ?

Statically I assume these all configs are stored in memory and at run-time for each chirp this mem location is read and used,

so using dynamic API this can be modified at run time. Is my understanding correct ?

How the radar front-end takes these configurations ? Is it operating on chirp basis, BIST programs for every chirp during inter chirp time ?

-ben

Jitendra, we are in the beginning of design phase for IC selection.  Your support and solutions are critical at this time. 

Please provide details to above query.

Hello Ben,

For your usecase: chirp1 USRR, chirp2-SRR,chirp3-MRR all within a single burst.

For this purpose, each chirp needs to connect with different profile configuration. [profile-0: USRR, profile-1: SRR, profile-2: MRR]

mmwave sensor currently supports max of 4 profile configuration. So within burst/frame you can configure three set of chirps to three different profile-ID then repeat these three chirp set multiple times (if required) within burst/frame.

As you see in the above snapshot, each chirp RAM has a field of profile-Idx with which it needs to connect or get other configuration (numOfSample, chirp duration, freq start, sampling rate etc.)

Thus, your requirement to have each chirp different within a burst/frame is possible with mmwave sensor.

In RadarSS all the configuration are stored in RAM and it configures the HW in a group of chirps (no. of chirps in this group may vary based on time available or total no. of chirp in busrt/frame).

Dynamic update I have mentioned above if you need to change any existing configuration for the next frame then that can be done using dynamic APIs.

Regards,

Jitendra

Hi Jitendra,

I downloaded the DFP package, can you guide me which example application has the usage of dynamic APIs.

Runtime front-end parameter change is possible only on next radar frame, right ?

https://software-dl.ti.com/ra-processors/esd/MMWAVE-DFP-2G/latest/index_FDS.html

-ben

Hello Ben,

You can refer <dfp installation>\ti\example\mmWaveLink_SingleChip_Example\mmw_example.c which has usage of dynamic configuration.

And yes change will be visible during next radar frame.

As I understood your usecase that you need 3 different types (USRR, SRR, MRR) of chirp within the same frame/burst then that is possible with single shot configuration without using dynamic reconfiguration.

I hope below picture clarify your doubt.

Regards,

Jitendra

Hi Jitendra,

What are the performance figures for sending data from MSS to BSS through SPI mailbox ?

Please share if any performance figures are available for communication between domains.

-ben

Hello Ben,

That would be roughly less than a msec for communication b/w MSS & BSS over mailbox. Overall timing included much more point of contacts, like Host to AWR over SPI communication depends on Host processor speed, SPI clock rate (max 40MHz); then within AWR device MSS to BSS CMD transfer; BSS process and apply those CMD config etc.

Most of the APIs take less than a msec (given fast processor and high SPI clock).

And for the few of the APIs when RadarSS needs to do some heavy task then it may take high time (like boot time calibration), but this is one time job.

Here are some rough no. for few APIs

To cover the concept of dynamic configuration device takes care of those constraints and provides much flexibility for device configuration so the Host processor flow/algo and performance don't get affected by any extra time taken. For AWR2243 you can refer few of the APIs from ICD and DFP examples.

This document explains the advanced frame and chirp APIs in detail which can be used to implement many complex and flexible features.

https://software-dl.ti.com/ra-processors/esd/MMWAVE-DFP-2G/latest/exports/mmwave_dfp_user_guide.pdf

ICD: https://software-dl.ti.com/ra-processors/esd/MMWAVE-DFP-2G/latest/exports/mmWave-Radar-Interface-Control.pdf

Regards,

Jitendra

Hi Jitendra,

Any MCAL driver packages available for AWR products ? How CSI2/LVDS drivers categorized in Autosar context ?

Are they implemented as CDD drivers which can run on MSS ? What about mmWave Link driver to run on MSS and in

Autosar context how it is treated ? Do you have different drivers to run on DSS & MSS ?

If I have to run Autosar on MSS and mmWave Link drivers also on MSS, is it possible to do dynamic chirp re configurations during inter chirp intervals at run time ?

-ben

Ben Alexandar said:

Any MCAL driver packages available for AWR products ? How CSI2/LVDS drivers categorized in Autosar context ?

MCAL driver is available for AWR products.    But No CSI2/LVDS drivers are offered in the MCAL package. 

Ben Alexandar said:

Are they implemented as CDD drivers which can run on MSS ? What about mmWave Link driver to run on MSS and in Autosar context how it is treated ? Do you have different drivers to run on DSS & MSS ?

The Complex driver is implemented to use the Mailbox IP for IPC between different cores. No support for mmwavelink driver.

Ben Alexandar said:

If I have to run Autosar on MSS and mmWave Link drivers also on MSS, is it possible to do dynamic chirp re configurations during inter chirp intervals at run time ?

Yes, if mmwavelink is running on Autosar (MSS), it can be used to re-configure for dynamic change. Chirp/frame interrupt can be re-route to MSS core where application can invoke specific dynamic APIs at particular time stance (wrt to physical chirp/frame streaming timing).

Regards,

Jitendra

Jitendra Gupta said:

MCAL driver is available for AWR products.    But No CSI2/LVDS drivers are offered in the MCAL package. 

May I know why CSI2/LVDS drivers are not available as CDD drivers ? How can I use these drivers in MSS and in Autosar context ?

-ben