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.

IWR1843BOOST: Using CCS debug to read L3 memory, theoretical bytes do not match actual

Part Number: IWR1843BOOST
Other Parts Discussed in Thread: UNIFLASH

Hi team,

Here's an issue from the customer may need your help:

The customer wants to capture 1 frame of data with IWR1843BOOST only.

Utilize IWR1843BOOST, out_of_box_1843_isk.bin, CCS, multiple .cfg.

Referenced to the ADC Data Capture using Capture Demo and CCS Memory Browser IWR14xx/AWR14xx example, Mmwave Radar Device ADC Raw Data Capture and the data manual, the data from memory was successfully seen using CCS.

However, the configuration file is as follows, reading one frame of data, 3 transmit and 4 receive, and the cortex's L3 starts at 0x51000000. Number of bytes calculated = 3 * 4 * 64 * 16 * 4 = 4096 = 0xc000. So the address read is 0x51000000 -- 0x5100bffc, but it actually goes to 0x5100c7fc. That is, number of receive bytes = 0xc800(More 0x800). And the more reads you set, the greater the offset.

Here are a few test data:

Theory: 0x18000 actual: 0x19000

Theory: 0x60000 actual: 0x64000

In the previous two reference articles, memory starts at address 0x51020000, not L3 at address 0x51000000.

What does the read start address mean relative to the offset address of 0x51000000? Why does the actual collected data exceed the theoretical value?

The data for Multiframe Refresh memory has no duplicate value, meaning that all data is being refreshed. And why's this?

Could you help check this case? Thanks.

Best Regards,

Cherry

  • Hi,

    A quick update:

    The customer suspects that the operation is a problem because they have burned the following bin file and there are always different problems that prevent them from entering debug mode.

    \MmWave_SDK_03_06_00_00-LTS\packages\ti\utils\ccsdebug\xwr18xx_ccsdebug.bin

    In addition, in the above document, the raw data collection is not based on out_of_box_1843_isk.bin, but the capturexxx files. Information about the older version of SDK was found in the following directory of the newer version of SDK, but no bin file was found:

    \MmWave_SDK_03_06_00_00-LTS\packages\ti\drivers\test\mem_capture\xwr18xx

    Thanks and regards,

    Cherry

  • Hello,

    I will continue to look into your initial question, but with regards to the "\MmWave_SDK_03_06_00_00-LTS\packages\ti\drivers\test\mem_capture\xwr18xx" directory, the two files .xer4f and .xe674 files are the .mss and .dss files respectively. A binary (.bin) file is these two files combined and compiled. Using Code Composer Studio and the IWR1843BOOST board in debug mode, you are able to flash these files to their respective cores and achieve the same thing as flashing a compiled bin via Uniflash. A guide for flashing these files using CCS can be found in the Industrial Toolbox for mmWave Sensors which I will link here.

    https://dev.ti.com/tirex/explore/node?a=VLyFKFf__4.12.1&node=A__AKZl2I1OiS5ssBNGpidsCQ__com.ti.mmwave_industrial_toolbox__VLyFKFf__4.12.1

    Best Regards,

    Pedrhom Nafisi

  • Hi Pedrhom Nafisi,

    Thanks for your support.

    Correction: Flash the "\mmWave_SDK_03_06_00_00_LTS \packages/ti\drivers\test\mem_caption\xwr18xx" directory, the .xer4f and .xe674 files caused the cfg file to not be transferred, causing the transmitted data to never be replied to.

    The speed of the control serial interface is 115200.

    Thanks and regards,

    Cherry

  • Hello,

    For clarification, when you say the cfg file is not transferred are you saying that no response is ever heard from the device or that the cfg is bad? It is possible that with this different binary, the supported cfg commands are different compared to before. What I would recommend is using a serial port communication tool such as TeraTerm or PuTTY to verify a good start of the device. Using those terminals you can get error messages on any cfg line that could be causing an issue. If the device is refusing to even start, when connecting to the CFG_PORT COM port you will get no feedback when pressing the enter key or anything.

    If you want a quick guide on this, exclusively follow the serial port settings seen in this CLI guide

    https://dev.ti.com/tirex/explore/node?a=VLyFKFf__4.12.1&node=A__AITQiu2kqZjZBpM3XxDZdA__com.ti.mmwave_industrial_toolbox__VLyFKFf__4.12.1

    Best Regards,

    Pedrhom Nafisi

  • Hi Pedrhom Nafisi,

    Thanks.

    The latest response dose help.

    I will continue to look into your initial question,

    And is there anything new regarding the initial issue?

    Thanks and regards,

    Cherry

  • Hello,

    With regards to the initial question of why there is more data than expected, there is a buffer and the details of this buffer can be seen in the Doxygen documentation located at C:/ti/<mmwave_sdk_version>/packages/ti/drivers/test/mem_capture/docs/doxygen/html/index.html

    You can use the 14xx mss code and the doxygen together to understand how the payload is taken and how the final result that is sent to the L3 is put together.

    Best Regards,

    Pedrhom