• State Resolved
  • Locked Locked
  • Replies 12 replies
  • Answers 2 answers
  • Subscribers 30 subscribers
  • Views 812 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

AWR1843: Setting up DPEDMA addresses for CQ data

Titan Yuan
Prodigy 150 points
Part Number: AWR1843


Hello,

I am trying to output the CQ data from the CQ RAM into L3RAM on AWR1843 via DPEDMA.  The documentation says that the CQ RAM is a ping-pong memory, so I'm wondering how I should configure the DPEDMA_syncACfg ping/pong addresses to transfer the data from each chirp into L3RAM.  The buffers have all been allocated correctly and I already calculated the size of the CQ data outputted during each chirp.

static int32_t rangeProcDSP_ConfigCqSatDataEDMA(
    rangeProcDSPObj* rangeProcObj, DPU_RangeProcDSP_HW_Resources* hwRes) {
  int32_t retVal = 0;

  DPEDMA_syncACfg syncACfg;
  rangeProc_dpParams* dpParams = &rangeProcObj->DPParams;

  uint32_t satDataSizePerChirp =
      (dpParams->numSatDataSlices + 1) * sizeof(uint8_t);

  // Copy data from CQ2 into L3 memory.
  syncACfg.aCount = satDataSizePerChirp;
  syncACfg.bCount = dpParams->numChirpsPerChirpEvent;
  syncACfg.srcBIdx =
      MATHUTILS_ROUND_UP_UNSIGNED(satDataSizePerChirp, CQ_DATA_ALIGNMENT);
  syncACfg.dstBIdx = satDataSizePerChirp;

  // Ping configuration.
  syncACfg.srcAddress = (uint32_t)rangeProcObj->cqSatDataBuf;
  syncACfg.destAddress = (uint32_t)rangeProcObj->cqSatDataOut;

  retVal = DPEDMA_configSyncA_singleFrame(
      hwRes->edmaCfg.edmaHandle, &hwRes->edmaCfg.cqSatDataPing,
      NULL,  // no chaining
      &syncACfg, false, true, true, NULL, NULL);
  if (retVal < 0) {
    return retVal;
  }

  // Pong configuration.
  syncACfg.srcAddress = (uint32_t)rangeProcObj->cqSatDataBuf + offset?;
  syncACfg.destAddress = (uint32_t)rangeProcObj->cqSatDataOut + offset?;

  retVal = DPEDMA_configSyncA_singleFrame(
      hwRes->edmaCfg.edmaHandle, &hwRes->edmaCfg.cqSatDataPong,
      NULL,  // no chaining
      &syncACfg, false, true, true, NULL, NULL);

  return retVal;
}

What should be the offset for the pong DPEDMA?  I know that mmwave_sdk_03_03_00_03/packages/ti/control/mmwavelink/test/common/link_test.c has an example with normal EDMA, but I would like to set up DPEDMA.  Thank you!

  • 0
    TI__Guru 70100 points

    Hello,

    mmWavelink test application provides reference to copy CQ data to L3 memory using eDMA.

    Application doesn't need to bother about ping pong scheme, as Hardware itself takes care of this scheme. Same memory address buffer is being filled by the HW ping-pong scheme at every chirp interval. At every chirp interval DFE internally switch ping to pong (or other way around). And same memory buffer visible to application will be updated.

    So you just need to follow test application to get the CQ data at every chirp internval.

    Regards,

    Jitendra

  • 0 in reply to Jitendra Gupta
    Prodigy 150 points

    Thank you for the quick response, Jitendra!  That was very helpful.

    Just to confirm, if I configure the CQ data as follows:

    ADCBuf_CQConf cqConfig;
memset((void*)&cqConfig, 0, sizeof(ADCBuf_CQConf));
cqConfig.cqDataWidth = 0;  // 16 bits
cqConfig.cq1AddrOffset = CQ_SIGIMG_ADDR_OFFSET; // 0x800U
cqConfig.cq2AddrOffset = CQ_RXSAT_ADDR_OFFSET; // 0x1000U

retVal = ADCBuf_control(gMmwMssMCB.adcBufHandle, ADCBufMMWave_CMD_CONF_CQ,
                        (void*)&cqConfig);

    Then, on the DSS core, the signal/image band energy data will be at address SOC_XWR18XX_DSS_CHIRPINFO_BASE_ADDRESS + 0x800 and the saturation data will be at address SOC_XWR18XX_DSS_CHIRPINFO_BASE_ADDRESS + 0x1000?

    Thanks in advance!

  • 0 in reply to Titan Yuan
    TI__Guru 70100 points

    In OOB demo, CQ data is configured to stream over LVDS interface, But if you need to consume internally then you can copy that CQ data to L3 memory as test application is doing.

    If you are planning to detect & mitigate interference in mmwave sensor then we have a reference application available on TI-Rex which you can refer for your development.

    https://dev.ti.com/tirex/explore/node?node=AFA0ogxohdCEX-9UJxRsVA__Z2F8GEn__LATEST

    Hope this new application would help in your development.

    Regards,

    Jitendra

  • 0 in reply to Jitendra Gupta
    Prodigy 150 points

    Thank you Jitendra!  I have one last question regarding the CQ saturation data, where I'm running into a weird bug.

    This is the CQ saturation monitoring configuration:

    cqSatMonCfg.primarySliceDuration = (uint16_t)4;  // 1 LSB = 0.16 us
// Primary and secondary time slices.
cqSatMonCfg.numSlices = 2 * floor((RAMP_END_TIME_US - ADC_START_TIME_US) /
                                  (cqSatMonCfg.primarySliceDuration * 0.16)) -
                        1 // equal to 57;

    The number of time slices I get is 57 given my chirp configuration.  However, when I print out the CQ saturation data I get from one chirp, I get the following:

    Total length: 58 bytes (expected)

Byte 0 (numSlices): 55 (incorrect)
Byte 1:             55
Bytes 2 through 55: 0
Byte 56:            68
Byte 57:            11

    It looks like the data is malformed because numSlices is not set correctly to 57.  This happens for any numSlices greater than 55.  From the docs, it looks like 127 is the maximum number of slices, so 57 should be within spec.

    However, if I change numSlices to 55 or fewer, I get the following, which is correct:

    Total length: 56 bytes (expected)

Byte 0 (numSlices): 55 (correct)
Bytes 1 through 55: 0

    Any ideas on what might be wrong here?  Thanks in advance!

  • 0 in reply to Titan Yuan
    TI__Guru 70100 points

    Hi,

    Please provide me a day or two to check same at my end (for slice len>55).

    Hopefully you are not blocked with this and the original issue is being resolved at your end.

    Regards,

    Jitenda

  • 0 in reply to Jitendra Gupta
    Prodigy 150 points

    Hi Jitentra, any updates on this?  Thanks in advance!

  • 0 in reply to Titan Yuan
    TI__Guru 70100 points

    Hello Titan,

    Apologies but I didn't get any update or feedback on this yet. Let me get back to you on this.

    Regards,

    Jitendra

  • 0 in reply to Jitendra Gupta
    TI__Guru 70100 points

    Hi Titan,

    I have done an experiment today using mmwavelink test application C:\ti\mmwave_sdk_03_05_00_04\packages\ti\control\mmwavelink\test\:

    with these changes on default applcation

    main_mss.c:  bool cqDataVerifyTest = true; //false

    link_testcase_config.c

    const rlRxSatMonConf_t rxSatMonCfg =
    {
        .profileIndx   = 0U,
        .satMonSel     = 3U,
        .reserved0     = 0U,
        .primarySliceDuration = 4,//5U, TODO E2e test
        .numSlices     = CQ_NUM_SLICES,

    link_testcase_setting.h

    #define CQ_NUM_SLICES    57    //13U TODO FOr E2e

    ANd I get the right no. of slice in the CQ1 and CQ2 data, please see below snapshot-

    I would request you to refer the same test application if you are missing any device configuration.

    Regards,

    Jitendra

  • 0 in reply to Jitendra Gupta
    Prodigy 150 points

    Hi Jitendra,

    Thank you for following up!

    In your screenshot, with CQ_NUM_SLICES set to 57, I would expect to see the numSlices byte 0x39 followed by 57 bytes of zero.

    However, in the screenshot you attached, I see the numSlices byte 0x39 followed by only 55 bytes of zeros.  This is similar to what I'm seeing where I only get 55 bytes of correct RX saturation data.

    Would you be able to find out why only 55 bytes of RX saturation data are correct please?  Thank you!

  • 0 in reply to Titan Yuan
    TI__Guru 70100 points

    Hi Titan,

    I would request you to follow ICD (chapter:10) which explains the CQ2 data formatting on the memory, 

    https://software-dl.ti.com/ra-processors/esd/MMWAVE-DFP/01_02_06_03/exports/mmWave-Radar-Interface-Control.pdf

    So as per above snapshot here is calculation: 0x51000800+1 (length)+57 (data) = 0x5100083A (ends at this location).

    Last two bytes of this CQ2 slices are part of 0x51000838 memory WORD. Thus CQ2 memory fill up is correct here, just the angle of view is slightly different to understand it.

    I hope I am clear here.

    Regards,

    Jitendra

  • 0 in reply to Jitendra Gupta
    Prodigy 150 points

    Hi Jitendra,

    Sorry, my bad, I overlooked the zeroes of the next word.  I will run the mmwavelink test application and get back to you if I run into any other issues.  Thank you!

  • +1 in reply to Titan Yuan
    Prodigy 150 points

    Hi Jitendra,

    I have found the issue on my side - I was setting the number of slices incorrectly because I was using the entire ramp time instead of just the ADC sampling time.  Thanks for your help!