AWR1843BOOST: Crash of OOB demo

Hi Kazuki,

Let me run this configuration on a device on my end to see what the problem might be. I will get back to you with a definitive answer by Monday.

For now though, one likely culprit could be the frame periodicity being too low for the chirps and processing to finish. Perhaps try Increasing that in the configuration? You could start with frameCfg 0 2 33 0 50 1 0 and if that works, you can experiment with other values of frame periodicity.

Regards,

Aayush

Hi Aayush,

Thank you for quick response.

I tried to change frame periodicity from 33ms to 100ms.

But the program doesn't seem to work well.

The program seems to work well with 30fps(frame periodicity=33ms) when I decreased the number of ADC sample from 349 to 256.

Does this program have any limitation of memory or calculation time?

Regards,

Kazuki

Hi Kazuki,

I was able to run your configuration and root cause the issue. When debugged with CCS, I could see that the program terminates with error number -30311. This error originates from the CFAR data processing unit: DPU_CFARCAPROCHWA_ENOMEM__DET_MATRIX_EXCEEDS_HWA_INP_MEM.

This error essentially means that for your configuration, the detection matrix couldn't fit into the HWA memory banks when needed by the CFAR data processing unit. The CFAR data processing unit (DPU) uses two HWA memory banks to hold the detection matrix during processing. As one bank is 16K, this means that the detection matrix must fit in 32K memory to be copied into HWA memory during CFAR computation.

Size of detection matrix needed is: numRangeBins * numDopplerBins * sizeof(uint16_t) or numRangeBins * numDopplerBins * 2

mmWave demo rounds up numAdcSamples to the nearest power of two to get numRangeBins. For your configuration, 349 ADC samples rounds up to 512 range bins.

Similarly, it rounds up numChirpsPerFrame/numTxAntennas to the nearest power of two to get numDopplerBins. For your configuration, (3*33)/3 = 33 rounds up to 64 doppler bins.

For this configuration, size of detection matrix is  512*64*2  = 65,536 bytes, which exceeds the 32K limit.

When you reduce numAdcSamples to 256, this number is halved and becomes 32,768 bytes, which just fits into two HWA memory banks.

On the other hand, if you use the other configuration you mentioned, numDopplerBins becomes (3*32)/3 = 32. This configuration also allows detection matrix to fit into HWA memory.

I hope this answers your question. You can look into how to debug the demo in CCS in section 3. 2. 2. of the mmWave SDK user guide.

You can have a look at demo/utils/mmwdemo_rfparser.c to see how numRangebins, numDopplerBins, etc are calculated from user configuration. You can have a look at datapath/dpc/objectdetection/objdethwa/src/objectdetection.c to see memory allocation details.

Alternatively, information on memory constraints imposed by DPUs is usually available in the doxygen documentation of all DPUs. For example, from the doxygen documentation of CFAR DPU: "...This matrix must be no bigger than what can fit in M0+M1 memory (error checking is done during DPU_CFARCAProcHWA_config and violation will generate error code DPU_CFARCAPROCHWA_ENOMEM__DET_MATRIX_EXCEEDS_HWA_INP_MEM)."

You can find this page on your local SDK install location, probably here: file:///C:/ti/mmwave_sdk_03_03_00_03/packages/ti/datapath/dpc/dpu/cfarcaproc/docs/doxygen/html/index.html

Regards,

Aayush

Hi Aayush,

Thank you for your detailed answers.

I understood well.

I guess this problem would be resolved by using DSP for CFAR processing because L2 memory of DSP is bigger than HWA memory.

But this would cause slower calculation time/

Do you have any solution for this problem?

Btw, you said data size of HWA memory is rounded up.

Is it same in L3 memory (radar cube)?

Regards,

Kazuki

Hi Kazuki,

Let me have a look into this and get back to you by Monday.

Regards,

Aayush

Hi Aayush,

Thank you for your reply.

I look forward to hearing back from you.

Regards,

Kazuki

Hi Kazuki,

It is the mmWave demo that does this rounding up. So, it'll be the case for both HWA and DSP. numRangeBins, numDopplerBins, etc are calculated on the basis of numAdcSamples, numChirpsPerFrame/numTxAntennas provided by the user. It is these that are rounded up to the power of two.

numRangeBins and numDopplerBins are used to allocate space for the detection matrix, the ADC In buffer and the radarcube, so this rounding up would affect all of them. This calculation of numRangeBins and numDopplerBins happens in demo/utils/mmwdemo_rfparser.c.

I am not sure of a way around this, but to my knowledge, the datapath in itself doesn't impose a hard constraint of needing these bins to be a power of two (I could be wrong here). Let me experiment, go through the code and ask the wider team about why this rounding up is needed. Perhaps you could also experiment on your end by removing this round-up from the rfparser file, recompiling the demo and checking if that has an impact.

Regards,

Aayush

Hi Aayush,

Thank you for your reply

I understood rounding up would be done on all memory (HWA,L1,L2 and L3 memory)

By the way, I found below document.

www.ti.com/.../swra663.pdf

Is memory compression compatible with HWA memory?

Best Regards,

Kazuki

Hi Kazuki,

I'm not sure. Let me check with the wider team and get back to you on this next week.

Regards,

Aayush

Hi　Aayush,

Thank you!

I look forward to your reply.

Best Regards,

Kazuki

Hi Kazuki,

I checked the documentation and conferred with the wider team, compression/decompression support is not available for HWA 1.0 with AWR1843. 

Regards,

Aayush