This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AWR6843AOP: Questions Regarding Hardcoded Configuration in AOP OOB Project

Part Number: AWR6843AOP
Other Parts Discussed in Thread: IWR6843AOP, IWR6843ISK

Tool/software:

Subject: Questions Regarding Hardcoded Configuration in IWR6843AOP OOB Projects

Dear TI Support Team,

I have a few questions regarding the use of hardcoded configurations in the mmWave IWR6843AOP OOB project:

  1. I successfully compiled the OOB project using a hardcoded configuration that was generated by the mmWave Visualizer GUI (version 3.6.0).

    The configuration was verified to work correctly, as the range profile output appeared as expected.

  2. At runtime, the UART baud 115200 8 n 1 output shows:

     
    xWR64xx MMW Demo 03.06.00.00

    mmwDemo:/>

    (observed via AccessPort tool).

    It seems the system is waiting for external UART input, even though I expected the hardcoded configuration to be automatically executed

  3. Is there any difference in the hardcoded configuration implementation between the IWR6843AOP and IWR6843ISK OOB projects?

  4. Why do the AOP and ISK OOB projects have different project structures?

    • AOP OOB:

      • out_of_box_6843_aop.projectspec (single file)

    • ISK OOB:

      • out_of_box_6843_isk_dss.projectspec

      • out_of_box_6843_isk_mss.projectspec

Working based on

- IWR6843AOP

- CCS10.2.0

- SDK 3.5.0.4  

- mmwave_industrial_toolbox_4_12_1

- project: OOB

Thank you for your support and clarification.

Best regards,

Kevin

  • Hi Kevin,

    One of our software experts will get back to you soon.

  • Hey Kevin,

    Thanks for reaching out regarding the hard coded config. I have commented and answered on some of your observations and questions below.

    It seems the system is waiting for external UART input, even though I expected the hardcoded configuration to be automatically executed

    Yes, upon restarting the program, the serial terminal should display the demo banner followed by some text stating that it is performing a hard-coded config. Additionally, every time a command is read in from the HCC, a "Command" text should be printed to the terminal. Which method did you follow to add the HCC - i.e., Method A.1, A.2, or B?

    Is there any difference in the hardcoded configuration implementation between the IWR6843AOP and IWR6843ISK OOB projects?

    There shouldn't be any differences on how to implement the HCC for either demo. Just note that the ISK project includes one additional CLI command, bpmCfg.

    Why do the AOP and ISK OOB projects have different project structures?

    The AOP and ISK demos actually have slightly different processing chains with the primary difference being whether the DSP is utilized. You can see the main processing difference in the image below, but for a more detailed overview on the processing chain, you can check out the <MMWAVE_SDK_INSTALL_DIR>/packages/ti/demo/xwr68xx/mmw/docs/doxygen/html/index.html for ISK documentation and the <MMWAVE_SDK_INSTALL_DIR>/packages/ti/demo/xwr64xx/mmw/docs/doxygen/html/index.html for AOP documentation.

    Regards,

    Kristien

  • Hi Kristien,

    Thanks for answering my questions in detail.

    Currently, I am working based on HCC Method B:

    1. I ran setenv.bat, followed by gmake clean and gmake all, and the build completed successfully.

    2. In cli.c:

      • I have edited the char *hardCodedConfigCommands[] array to include the appropriate configuration statements.

      • In the CLI_task() function, I added the #ifdef USE_HARD_CODED_CONFIG block in the appropriate location (as I’ve successfully done before in another project).

    3. At runtime, the UART monitor tool (AccessPort V1.37) shows the following output:

    ******************************************
    xWR64xx MMW Demo 03.06.00.00
    ******************************************
    mmwDemo:/>
    sensorStop (Note: since the hardcoded config didn’t work, I sent this command via UART from a Windows PC)
    Ignored: Sensor is already stopped Done
    mmwDemo:/>
    mmwDemo:/>
    flushCfg (Note: also sent manually due to the hardcoded config not executing)
    Done
    mmwDemo:/>
    1. I noticed that in the OOB (Out-of-Box) project, the function CLI_open() doesn’t appear to be explicitly called in C:\ti\mmwave_sdk_03_05_00_04\packages\ti\utils\cli\src\cli.c.

                Is it possible that CLI_open() is being invoked from somewhere else that’s not immediately visible?
               Could it be duplicated or hidden in another part of the codebase?


    Regards,

    Kevin

  • Hey Kevin,

    I have few more comments on some of your observations and questions below.

    First of all, I should've caught onto this earlier, but you should update to the latest version of the SDK, 3.6.2.0, and the latest version of the toolbox, Radar Toolbox 3.0.0.5. While I don't believe this has anything to do with the HCC issue, we always recommend using the latest software since it will be the most stable version.

    Currently, I am working based on HCC Method B

    I would highly recommend Method A.1 or A.2 since as mentioned in the HCC documentation, you may need to edit and double check correct settings in the cli.c file every time projects are rebuilt in CCS which may be inconvenient and lead to unintended usage of the HCC. If you would still like to proceed with Method B, I have included some additional thoughts on what could be causing issues below.

    I ran setenv.bat, followed by gmake clean and gmake all, and the build completed successfully.

    Did you verify that the .aer4f files for the xwr68xx are updating upon executing gmake all - i.e., does the file creation date update? 

    Is it possible that CLI_open() is being invoked from somewhere else that’s not immediately visible?

    During the system initialization task (MmwDemo_initTask) of most demos, MmwDemo_CLIInit is called which calls CLI_open.

    Regards,

    Kristien