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.

IWR6843: Injecting a test radar cube into DSS memory

Part Number: IWR6843

I am trying to inject a recorded radar cube into the DSS processing chain in order to debug the DSP AoA algorithm. It isn't working -- it appears that data is not initialized and I get all zeros as output. I am wondering what I am doing wrong.

In dss_main following the example in the sdk_user_guide, I have:


#define TEST_RADAR_CUBE_SIZE 12288
#define TEST_RADAR_CUBE_ALIGNMENT 8


/*! L3 RAM buffer for object detection DPC */
uint8_t gMmwL3[SOC_L3RAM_SIZE - TEST_RADAR_CUBE_SIZE*sizeof(cmplx16ImRe_t) - TEST_RADAR_CUBE_ALIGNMENT];
#pragma DATA_SECTION(gMmwL3, ".l3ram");


#pragma DATA_SECTION(testRadarCube, ".l3data_testradarcube");
#pragma DATA_ALIGN(testRadarCube, TEST_RADAR_CUBE_ALIGNMENT);
#include <ti/datapath/dpc/dpu/dopplerproc/include/testradarcube.h>

where testradarcube.h has the definition:

const cmplx16ImRe_t __attribute__((used)) testRadarCube[TEST_RADAR_CUBE_SIZE] = {
{96, -136}, {-179, 229}, {144, -169}, {10, 87}, {-66, -70},
{11, 41}, {1, -2}, {55, -15}, {-97, 16}, {82, -9},
{-39, 2}, {6, -7}, {10, 15}, {-7, -7}, {-6, -5}, ... }


In dopplerprocdsp.c, I have

#define TEST_RADAR_CUBE_SIZE 12288
extern const cmplx16ImRe_t testRadarCube[TEST_RADAR_CUBE_SIZE];

int32_t DPU_DopplerProcDSP_process
(
    DPU_DopplerProcDSP_Handle    handle,
    DPU_DopplerProcDSP_OutParams *outParams
)
{
    DPU_DopplerProcDSP_Obj *obj;
    DPU_DopplerProcDSP_Config *cfg;
    uint16_t rxAntIdx, rangeIdx, txAntIdx; 
    uint16_t nextTransferRxIdx, nextTransferRangeIdx, nextTransferTxIdx; 
    uint16_t rxAntIdxBPMPreviousBuffer, txAntIdxBPMPreviousBuffer;
    uint32_t nextTransferIdx, waitingTime, pingPongIdx;
    volatile uint32_t startTime;
    volatile uint32_t startTimeWait;
    int32_t  *fftOutPtr;
    int32_t  retVal;
    uint8_t  channel;
    cmplx16ImRe_t  *inpDoppFftBuf;
    cmplx16ImRe_t  *radarCubeBase;
    cmplx32ReIm_t  *windowingOutBuf;

    retVal = 0;    
    waitingTime = 0;
    obj = (DPU_DopplerProcDSP_Obj *)handle;
    
    if (obj == NULL)
    {
        retVal = DPU_DOPPLERPROCDSP_EINVAL;
        goto exit;
    }    
    
    if(obj->inProgress == true)
    {
        retVal = DPU_DOPPLERPROCDSP_EINPROGRESS;
        goto exit;
    }
    else
    {
        obj->inProgress = true;
    }

    startTime = Cycleprofiler_getTimeStamp();


    radarCubeBase = (cmplx16ImRe_t *)obj->cfg.hwRes.radarCube.data; 
    cfg =  &obj->cfg;

    dspDpu_setRadarCubeDSP(handle);

    //rest of file is as normal
    ...  

}


The function dspDpu_setRadarCubeDSP looks like this:

#pragma FUNCTION_OPTIONS(dspDpu_setRadarCubeDSP, "-O0")
void dspDpu_setRadarCubeDSP( DPU_DopplerProcDSP_Handle  handle )
{
    size_t testRadarCubeSize;
    DPU_DopplerProcDSP_Obj *obj;                
    volatile cmplx16ImRe_t  *radarCubeBase;

    // Setup
    obj = (DPU_DopplerProcDSP_Obj *)handle;
    radarCubeBase = (cmplx16ImRe_t *)obj->cfg.hwRes.radarCube.data; 


    // Copy over
    testRadarCubeSize = sizeof(testRadarCube); // Size of testRadarCube array in bytes
    memcpy((void*)radarCubeBase, (void*)testRadarCube, testRadarCubeSize);

    return; 
}

My mmw_dss_linker.cmd file looks like

/*----------------------------------------------------------------------------*/
/* Linker Settings                                                            */
--retain="*(.intvecs)"

/*----------------------------------------------------------------------------*/
/* Section Configuration                                                      */
SECTIONS
{
    systemHeap : {} >> L2SRAM_UMAP0 | L2SRAM_UMAP1
    .l3ram: {} >> L3SRAM
    .l3data_testradarcube :
    {
        *(.l3data_testradarcube)
    } load = L3SRAM PAGE 0 (HIGH)
    .dpc_l1Heap  : { } > L1DSRAM
    .dpc_l2Heap: { } >> L2SRAM_UMAP0 | L2SRAM_UMAP1
    .demoSharedMem: { } >> HSRAM
}
/*----------------------------------------------------------------------------*/


And the map file shows the test cube:

MEMORY CONFIGURATION

         name            origin    length      used     unused   attr    fill
----------------------  --------  ---------  --------  --------  ----  --------
PAGE 0:
  ...
  L3SRAM                20000000   000c0000  000bfff8  00000008  RWIX
  ...
  
  
  SEGMENT ALLOCATION MAP

run origin  load origin   length   init length attrs members
----------  ----------- ---------- ----------- ----- -------
  ...
  20000000    20000000    000b3ff8   00000000    rw- .l3ram
200b4000    200b4000    0000c000   0000c000    r--
  200b4000    200b4000    0000c000   0000c000    r-- .l3data_testradarcube
  ...

SECTION ALLOCATION MAP

 output                                  attributes/
section   page    origin      length       input sections
--------  ----  ----------  ----------   ----------------
  ...

.l3data_testradarcube 
*          0    200b4000    0000c000     
                  200b4000    0000c000     dss_main.oe674 (.l3data_testradarcube)
  ...


GLOBAL SYMBOLS: SORTED BY Symbol Address 

address   name                                                         
-------   ----                    
...       ...
20000000  gMmwL3                                                       
200b4000  testRadarCube                                                
21080000  gHSRAM       
...       ...



It all compiles just fine. So I think the memcpy should work -- but when I output the radar cube, I get all zeros. Why? What am I doing wrong?


  • Hello.

    Have you tried going through CCS Debug to see what is happening to the test radar cube as it goes through the processing chain?  You can check the contents of the radar cube in memory via the memory browser to see what is happening to the data.  Are you overwriting the current radar cube with your test radar cube or is your test radar cube something separate?

    Sincerely,

    Santosh

  •  I am working on using CCS to look at the details today. 

    And yes, I am trying to overwrite the current radar cube with the test radar cube. The issue is that switching to the majority of the processing chain to the DSP is causing some wonky pointclouds, even after bringing in the aoa2dprocdsp.c as the AoA DPU. The HWA chain works fine (MMWave OOB), so, I am trying to inject a recorded radar cube from the HWA chain into the DSP based chain to see the differences and thus discover why the DSP based chain is giving such poor outputs. 

    I've already injected a synthetic (simulated) radar cube into the DSP processing chain and everything worked as expected. So there seems to be something going on with the phase compensation of the inputs to the angle FFT. At least that is my hunch because the synthetic cube wasn't recorded, it was generated, and thus the phase errors aren't present and the chain works fine (after bypassing the compensation routines of course).

    If you have any insight into this bigger problem it would be appreciated as well, or just more help with this current debug issue. I thought I followed all the platform specific steps, but, perhaps there is something I am missing? What would you need to see to help debug the issue? 

  • Hi Alex,

    Let me make sure I understand this correctly. You are testing the entire demo, not just a single DPU. You have two radar cubes that you've injected into the DSP processing chain. One of these radar cubes comes from a measurement taken from the HWA chain, and one you generated yourself. When you use the radar cube from measurement, you get an erroneous point cloud. When you use the hand-generated radar cube, the point cloud looks like what you would expect.

    Why do you think the problem is with the phase compensation? If that is the case, I would expect to see the point cloud at the right ranges, but at incorrect angles. These offset angles should be constant throughout the entire recording, meaning that if a person approaches the radar from a constant angle in real life, then even the erroneous point cloud should detect them approaching at a constant angle, although the estimated angle itself may be incorrect. Is that what you see?

    Best,

    Nate

  •    Yes. You've got it. Of course for the hand generated one I need to remove all phase/bias compensation because it is a simulated cube and thus doesn't have those problems. 

    I think the problem is with the phase compensation in the DSP chain because the detection matrix looks good and so do the detections themselves. The algo has been tuned to accurately find the peaks in the matrix. However the resulting angles are all over the place. So there must be something wrong with the radar cube values at the given range and Doppler indices. 




    Above is an example of what I am seeing from the DSP chain. Hopefully you can access that...

    Example  <-- Here is another link

    It could be I am not applying the correct phase inversions, it could be something wrong with the Doppler compensation, or it could be that noise is throwing off the phase.  I put a recorded radar cube from the HWA chain into a simulated pipeline, written in python off device, and it gave me similar results to what is happening on device. Since I am not doing any phase or range bias compensation etc (because it is meant for simulated data) the implication is that the DSP DPC isn't either. Or at least it isn't doing it properly....

  • Hi Alex,

    Aren't you using the IWR6843ISK EVM? That EVM shouldn't necessarily require range bias compensation for the antenna feed lines. See any of the ISK configuration files:

    compRangeBiasAndRxChanPhase 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0

    Are you perhaps referring to the antenna geometry configs?

    antGeometry0 0 -1 -2 -3 -2 -3 -4 -5 -4 -5 -6 -7
    antGeometry1 -1 -1 -1 -1 0 0 0 0 -1 -1 -1 -1
    antPhaseRot 1 1 1 1 1 1 1 1 1 1 1 1

    What I understand from what you're saying is that the angle estimation is happening incorrectly somewhere between the detection matrix and the point cloud, but we're not completely sure about where the problem is within that. My recommendation would be to record data in an open area of a single corner reflector with the clutter removal CLI turned off, and the CFAR threshold set high. This should ensure that you only get a single reflection from the field of view. At this point, collect the data again, and run your offline processing so you can be sure that what you're running offline is correct. I suspect the problem is with DPU_AoAProcDSP_process().

    What is the difference between your code and the out-of-box software also? The out-of-box software should do the angle calculation correctly.

    Best,

    Nate



  • I am using a custom board with the ODS antenna built into it.

    We don't have corner reflectors but we do have a single person standing test that we run. I know the location and I have been working the trying to get a small number of detections from that test to go that route. Stay tuned!

    But I was not aware of antGeometry0 and antGeometry1 and antPhaseRot... I don't think these are documented in the mmwave sdk. Could you link me some documentation about these commands? 

  • But I was not aware of antGeometry0 and antGeometry1 and antPhaseRot... I don't think these are documented in the mmwave sdk. Could you link me some documentation about these commands? 

    Yes - the mmwave sdk accomplishes these through the antenna_geometry.c file that you should see in your project, whereas the people counting project does them through CLI. The docs here refer to the configuration lines above, but they may be implemented differently in the mmwave sdk. They may not be relevant to your project.

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

    Additionally, have you looked at this thread here? It seems related and perhaps may help?

    https://e2e.ti.com/support/sensors-group/sensors/f/sensors-forum/1022381/iwr6843isk-ods-misreported-xyz-data-on-mmwave-demo-visualizer---data-rotated-and-split-along-center

    Best

    Nate

  •  The problem was that our original firmware used the 6443 chain on 6843 hardware. This meant that the  compRangeBiasAndRxChanPhase coefficients were reversed in sign. Changing the signs fixed the issue. 

  • Excellent! I'm glad we were able to debug this.

    Best,

    Nate

  • Thanks for that link. It looks like that person was having almost the same issue. Thanks for your support!