• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 32 subscribers
  • Views 933 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

IWR1642: L3 Memory Calculation

Mustafa Homsi
Expert 1171 points
Part Number: IWR1642

Hello,

Is there an equation to calculate L3 memory size based on a chirp/frame settings?

Thanks!

Mustafa

  • 0
    TI__Expert 5235 points

    In 3.x release, you can see the L3 allocations in objectdetection.c:

        /* L3 allocations */

        /* L3 - radar cube */

        radarCube.dataSize = staticCfg->numRangeBins * staticCfg->numDopplerChirps *

                             staticCfg->numVirtualAntennas * sizeof(cmplx16ReIm_t);

        radarCube.data = DPC_ObjDet_MemPoolAlloc(L3ramObj, radarCube.dataSize,

                                                 DPC_OBJDET_RADAR_CUBE_DATABUF_BYTE_ALIGNMENT);

     

        /* L3 - detection matrix */

        detMatrix.dataSize = staticCfg->numRangeBins * staticCfg->numDopplerBins * sizeof(uint16_t);

        detMatrix.data = DPC_ObjDet_MemPoolAlloc(L3ramObj, detMatrix.dataSize,

                                                 DPC_OBJDET_DET_MATRIX_DATABUF_BYTE_ALIGNMENT);

    Note the variable numDopplerChirps which you wouldn't notice in 2.x release, you can locate its definition in code below:

       /*! @brief Number of chirps for Doppler computation purposes.

                  For example, in TDM/BPM-MIMO scheme, this is the physical chirps

                  in a frame per transmit antenna

                  i.e numDopplerChirps = @ref numChirpsPerFrame / @ref numTxAntennas */

       uint16_t    numDopplerChirps;

    This was introduced because in 3.x release, compared to 2.x, we are allowing non power of 2 chirps for doppler computation.

    The chirp profile will determine the parameters involved in the calculation above, which you can further figure out from seeing how they are calculated in the code (numRangeBins = next power of 2 (numAdcSamples), numDopplerChirps as seen above, numDopplerBins is next power of 2 of numDopplerChirps.

  • 0 in reply to Piyush_
    Expert 1171 points
    Thank you Piyush for the detailed response. Just to confirm with numbers if my frame settings call for 128 range bins, 8 virtual antennas (4 receivers and 2 transmitters ) and 174 chirps then my L3 memory should add up to 760 kB which is lower than max size. Do you agree?
    Also, is it guaranteed that all other memory usage will be acceptable (L1/L2) assuming we confirm L3 size is not violated or do I need to make other verification calculations as well? Thanks! Mustafa
  • 0 in reply to Mustafa Homsi
    TI__Expert 5235 points

    Yes you need to do check L1/L2 also, just fitting in one kind of memory does not guarantee you will fit others. You can navigate the code to find out what is allocated in the memories, there is also a section in doxygen documentation of the demo that shows the buffer layout. If you don't want to model what is in the code separately, you can actually try the configuration you wish with the proper profile cfg file and try to run the demo, if any of the memory exceeds available size, the code will generate an exception and you will know where it happened and you can then debug further to see how much memory limit was exceeded.

    Our support role primarily is to provide you with any information that may be missing in our release or pointers to existing information so you can help yourself, please do not expect us to repeat basic arithmetic you have done to check your calculations or recall information correctly (like how much max L3 size is there in 1642), these kind of things we cannot easily commit to memory due to the plethora of information we have to deal with and so we end up doing the same that you would have done yourself i.e search the device and SDK documentation and code or worse, may make mistakes in responding to you, so I would encourage you to get more familiar with device documentation and SDK documentation. Thanks.

  • 0 in reply to Piyush_
    Expert 1171 points

    Piyush,

    I was not asking you about the size of L3 in IWR1642. I am aware it is 768KB. I just wanted to confirm if my frame settings occupies less than the max size. According to my calculation it is but when I use it for the ppl counting demo, it doesn't work. I followed your recommendation of running it in debug mode and check the terminal window which it shows the following error code: "Error: MMWDemoMSS mmWave Configuration failed [Error code -203685690]" Could you please let me know how can I interpret the error number? I attached a screen capture for reference.

    Also, according to the documentation / code, beside making sure L3 size is not violated, I only need to check that 4 x numRxAntennas x numTxAntennas x numDopplerChirps <= 16384 and 2 x numRxAntennas x numTxAntennas x numDopplerBins <= 16384 for the local ram memory. All other variables in that memory location seems to be driven by the number of detected objects and their size is not affected by the frame profile.

    Mustafa

  • 0 in reply to Mustafa Homsi
    TI__Expert 5235 points

    The memory limits are not the only limits to the configuration, there are limits imposed by the RF control firmware also, the mmWave error you see is related to such a limit. You can rfer to the radar ICD (Interface control document) to find out about the limits but this may require you a lot of guessing where specially in your configuration the problem is so you will need to decode the error code. You are using the people counting demo which I do not support [others may jump in] but most of these kind of outside SDK demos are based on some degree of reuse from the oob demo in SDK (at least parts that are not required to be specialized for the vertical application demo), so from what I see here, the error code is representing a combination of two error codes, so you will need to first manually decode this error by reading MMWave_decodeError function implementation (you can grep this in the source tree in .c/.h files, it will be in ti/control/mmwave/ ). In post 2.0 SDK releases, we used this decode API in the oob demo itself to print two codes instead of the one you see here so as to avoid the manual off line decode step. Your interest will be primarily in finding the "subSysError" code in the function mentioned, once you find this code, you can then look-up this number in mmwavelink API (ti/control/mmwavelink/mmwavelink.h, defines with names like *_RET_CODE_*) to find out what configuration may be in error. In order to understand at a high level the purpose of and connection between MMWave and mmwavelink, you can look up the SDK user guide, there are some descriptions and call flow diagrams. A basic understanding of this is important to be able to understand and debug the application.

    TIP: when you see a string with error information printed out and you want to locate where in the source it is happening, grep the part of the string without the code (e.g "mmWave Configuration failed") in the entire source tree. Then you can navigate the source tree to understand the code flow leading up to the error and also put breakpoints to step in the code and find out what API call resulted in the error.