IWR1443BOOST: High Accuracy Lab Startup Time

Hi Chris,

Would you describing your test procedure? The ES3.0 features a BSS that is flashed in ROM which serves to reduce boot time. You are right that it doesn't make any sense why boot time is higher but I'll need more information in order to assist you.

What kind of code changes did you make? Did you make same changes for ES2.0 device?

For power optimization I'd definitely recommend looking at the TIDEP-0091 if you haven't already.


Cheers,
Akash

Hi Akash,

I imported the High Accuracy Lab from mmwave_industrial_toolbox_3_1_1 and modified MmwDemo_transmitProcessedOutput() in main.c so that only obj->rangeEst is output to the UART (instead of all the data normally sent for visualization) and added GPIO_write (SOC_XWR14XX_GPIO_2, 0U); to turn off the LED on the board immediately after rangeEst is transmitted.

Separately, I modified cli.c in the SDK [mmwave_sdk_01_02_00_05] to use a hard-coded configuration as shown below.

Then I created metaImagexwr14xx_high_accuracy_mss.bin using ImageCreator as instructed by someone at TI for ES3 devices and programmed to flash with Uniflash.

The time from power-on of the board until the LED goes off was measured with an oscilloscope (about 246 ms).

I previously did the same experiment with and ES2 device although with an earlier version of industrial_toolbox, the duration with ES2 was about 200 ms.

-Chris


char * hardCodedConfigCommands[] =
{
"% ***************************************************************",
"% Created for SDK ver:01.02",
"% Created from Feng's profile",
"% Frequency:77",
"% Platform:xWR14xx",
"% ***************************************************************",
"sensorStop",
"flushCfg",
"dfeDataOutputMode 1",
"channelCfg 8 1 0",
"adcCfg 2 1",
"adcbufCfg 0 1 0 1",
"lowPower 0 1",
"profileCfg 0 77 10 7 142 10 0 24 1 1024 8306 0 0 34",
"chirpCfg 0 0 0 0 0 0 0 1",
"frameCfg 0 0 1 0 27 1 0",
"guiMonitor 1 1 0 0 0 1",
"calibDcRangeSig 0 -5 5 32",
"RangeLimitCfg 1 1.0 5.0",
"sensorStart",
"!!!END_OF_HARD_CODED_COMMANDS"
};

Looking at the CLI_task implementation, it appears that this method of hard-coding a configuration may be responsible for significant delay. For one thing the task starts with:

#ifdef USE_HARD_CODED_CONFIG
hardCodedConfigIndex = 0;
CLI_write ("Wait some time for system to initialize...\n");
Task_sleep(100);
CLI_write ("Performing hard-coded config\n");
#endif

Note the Task_sleep call. And I am guessing that creating / processing CLI commands takes significant time, also; do you think this is why the time until the first range measurement is so long?

The TIDEP-0091 example uses a more direct method of hard-coding a configuration.

Are there any plans to add high-accuracy measurement capability to the TIDEP-0091 example?

Thanks,

-Chris

Hi Chris,

Unfortunately I cannot provide an estimate on the Zoom FFT task at this time.

I believe it is likely that the Task_sleep is causing your prolonged duration here. Have you tried shortening it or even removing it?


Cheers,
Akash

Hi Akash,

I did experiment with the sleep duration, reducing the value did reduce the startup time, removing it entirely resulted in a non-working system.

Further experimentation would probably either involve trying to add high-accuracy measurement capability to the TIDEP-0091 example, or trying to implement a better hard-coded configuration in the High Accuracy Lab firmware (and then add a stored calibration feature like the TIDEP-0091 firmware has).

Neither of these looks to be easy to achieve.

Regards,

-Chris