AWR2944EVM: Acces and compression of radar cube data

Hi, thank you for your reply!

Samhitha Bobba said:

Decompression is performed in the Doppler processing DPU. You will have decompressed 1D FFT available for a given range bin during doppler processing.

So do you suggest that the best way to access the decompressed radar cube is within the "dopplerprochwaDDMA.c" file? Is there any feasible way of accessing the uncompressed data form within the scope of the objectdetection.c file?

I understand that after it finishes executing the radarcube returns to the compressed form, is this correct?

Samhitha Bobba said:

You can configure the compression ratio to be 1. But this will increase the size of radar cube. So, you need to ensure that you have sufficient memory available on DSS_L3.

Assuming that it will fit into the L3, won't the data still be in the compressed format (, i.e. EGC or BFP)? If they are then to my understanding, I still won't be able to read them as raw cmplx16ReIm_t data, is this correct? This is because they will be stored as shown in the image, the difference being that the compression will be of a factor 1, which will make it lossless, but still not directly interpretable as the raw cmplx16ReIm_t.

Best regards,

Mark

Hello Samhitha, thank you for your reply!

My idea to tap into the decompressed data is to create an additional L3 buffer in which I will store the samples from a single range bin per CPI. To do that I allocate this buffer once in preStartConfig which works fine. Next I try to pass the pointer to this buffer inside the function DPC_ObjDet_dopplerConfig to the doppler processing struct:

Inside DPC_ObjDet_dopplerConfig:

DPU_DopplerProcHWA_HW_Resources *hwRes;
hwRes->stftInputBuf = objDetObj->stftInputBuf;

For that I have modified the struct inside dopplerprochwaDDMA.h:

typedef struct DPU_DopplerProcHWA_HW_Resources_t
{
...
cmplx16ImRe_t * stftInputBuf;

}DPU_DopplerProcHWA_HW_Resources;

The idea is that then I can access the L3 buffer inside the file dopplerprochwaDDMA.c and write there the decompressed cube data, for later usage inside objectdetection.c.

However the addition of the single entry into the DPU_DopplerProcHWA_HW_Resources struct inside dopplerprochwaDDMA.h crashes the whole demo directly upon initialization with this error:
[C66xx_DSP] Debug: DPM Module Sync is done
Error: DPM Report 4 received with error:-30712 arg0:0x64 arg1:0x84eb44
[Cortex_R5_0] Error: DPM Report 4 received with error:-30712 arg0:0x64 arg1:0x1025a858
ASSERT: 20.759033s: ../mss/mss_main.c:MmwDemo_DPC_ObjectDetection_reportFxn:2638: 0 failed !!!

This error can be traced to
* File mmwave_error.h -> DPU base error -30000
* File dp_error.h -> DOPPLER DDMA BASE -700
* File dopplerprochwaDDMA.h -> DPU_DOPPLERPROCHWA_ERROR_NUMCHIRPSPERPING -12 

However this is clearly not the root cause as commenting out the single described modification of the struct DPU_DopplerProcHWA_HW_Resources results in the code running normal again.

So with that being said I would be more than happy if you could:
1.) Explain why the modification of this struct leads to the complete failure of the demos code.
2.) Please suggest an approach (or confirm my current one) of how to retrieve some decompressed data from dopplerprochwaDDMA.c scope to the objecdetection.c file scope where I have my DPC/DPM custom transport chain setup.

Hi Mark,

Place a breakpoint in CCS at the line where this error occurs. Check if there is any change in the value of any of the variables before and after addition of the additional member in the structure. Since this is a custom change, it's not possible to check this at my end. 

If you want the 1D FFT of a specific range bin and then you can add a DMA to copy the data from decompression scratch buffer to a given address. You can add this change in the loop where we process each of the range gate in Doppler processing -> DPU_DopplerProcHWA_process.

Regards,

Samhitha

Hello Samhitha,

thank you for your support! 

Could you please provide some guidance on setting a breakpoint inside the file dopplerprochwaDDMA.c please? This file is not within the CCS project and it is not being compiled during build only during the linker's operation the pre-compiled binary is pulled in from this location:  "C:\ti\mmwave_mcuplus_sdk_04_07_00_01\mmwave_mcuplus_sdk_04_07_00_01\ti\datapath\dpu\dopplerprocDDMA\lib\libdopplerproc_hwa_ddma_awr2944.ae66"

Recompiling the contents of this folder C:\ti\mmwave_mcuplus_sdk_04_07_00_01\mmwave_mcuplus_sdk_04_07_00_01\ti\datapath\dpu\dopplerprocDDMA with "gmake all" did solve the issue. It turns out that the default binary (obviously) didn't pick up the changes made to the .h file which is used during CCS project build. But nevertheless for future development it would be great if you could clarify how to set a breakpoint in the non-project scope file of dopplerprochwaDDMA.c.

You probably mean this loop? Where after the semaphore check the data from a single block will be present in the  L3 scratch. 

Best regards

Mark 

Hello Samhitha,

Samhitha Bobba said:

I think you are seeing something like the error shown in the below screenshot -

I don't see any error as of now, during build my CCS project's linker pulls in a prebuilt .ae66 file located here: 

• C:\ti\mmwave_mcuplus_sdk_04_07_00_01\mmwave_mcuplus_sdk_04_07_00_01\ti\datapath\dpu\dopplerprocDDMA\lib\libdopplerproc_hwa_ddma_awr2944.ae66

I can rebuild this .ae66 file by running setenv and then gamke all in the dopplerprocDDMA directory. So that's why I wonder how can I set a breakpoint in this external library (,which I only pull in during linking operations)?

Samhitha Bobba said:

I meant in the loop which processes each range gate

That's a very good insight, thank you! One more question concerning this, what is the format of the decompressed outer block which we access here? From what I was able to find it is [numChirps][rangeBinsPerBlock (indexed via rangeBinIdx)][rxAntennas]  is this correct?

Thanks for your help!

Mark

Hi Samhitha,

Thank you for the tip concerning the disassembler. It revealed the reason why only zeros are arriving at my PC (as I am currently outputting the slow-time sequence via TLV for debugging).

It did reveal that the actual logic inside my condition isn't executed. The problem being that the pointer which I assign inside objetdetection.c doesn't get picked up by the DPU.

Therefore this condition inside DPU_DopplerProcHWA_process isn't met:

Are there any additional considerations (like cache invalidation, or similar) that need to be made when exchanging information/pointers with, a precompiled DPU?

 Currently my approach is following:

1. Inside DPC_ObjDet_preStartConfig I assign (just once) memory for my buffer:
   1. ptrObjDetObj->stftInputBuf = DPC_ObjDet_MemPoolAlloc(L3ramObj, stftInputBuf, sizeof(cmplx16ImRe_t));
      ptrObjDetObj->stftOutputBuf = DPC_ObjDet_MemPoolAlloc(L3ramObj, ptrObjDetObj->stftBufBytes, sizeof(cmplx16ImRe_t));
2. Inside DPC_ObjDet_dopplerConfig at the top before/after (doesn't change the outcome) memset((void*)dopCfg, 0, sizeof(DPU_DopplerProcHWA_Config)); I do these 2 assignments:
   1. hwRes->stftInputBuf = objDetObj->stftInputBuf;
      hwRes->stftRangeBinIdx = objDetObj->stftRangeBinIndex; 
3. Inside DPU_DopplerProcHWA_process I have placed my logic inside the discussed for loop under the condition (which is never met):
   1.  if (cfg->hwRes.stftInputBuf != NULL)

Best regards,

Mark