AWR1843BOOST: AWR18xx HWA Complex Multiplication output is all zero

HH Chen

Part Number: AWR1843BOOST
Other Parts Discussed in Thread: AWR1843,

Hi Experts,

We are working on immigrating RX antenna DBF algorithm onto AWR1843's HWA, which simply performs an element-wise complex multiplication over DFFT output and DBF twiddle factor vector (corresponding to RX antenna spacing).
I wrote a test function which generates test pattern on L3 and then copy it to HWA memory using EDMA, and then fill the HWA internal memory using HWA_configRam(), and finally start HWA and wait until complete.

Config code:

Process code:

But the HWA output is always zero if HWA complexMultiply.mode is set to HWA_COMPLEX_MULTIPLY_MODE_VECTOR_MULT,

while if complexMultiply.mode is set to HWA_COMPLEX_MULTIPLY_MODE_MAG_SQUARED, the output meets my expectation.

The main difference is that Magnitude squared mode does not use the HWA internal memory.

So I checked the configRam and added the code below to make sure that writing to the HWA internal RAM is successful, but the memcmp always fails as the verifyBuffer is always zero, it seems I simply failed to write my twiddle factor vector into the HWA internal memory even though I toggled the 24th bit of HWACCREG7.

My question is:

0. What is the correct programming sequence to start a FFT HWA param with CMULT pre-processing? A demo would be very nice.

1. What is the data width of HWA internal memory which holds CMULT complex vectors? I am assuming a 32*2bit complex vector with lower 21bit valid for both image and real part.

2. Is there a way to validate successful writing to the HWA internal memory? (over JTAG debug? or CPU readback?)

over 4 years ago

0 Jitendra Gupta over 4 years ago

TI__Guru 70100 points

Hello Chen,

mmWave SDK provides HWA unit test application which you can refer

C:\ti\mmwave_sdk_03_05_00_01\packages\ti\drivers\hwa\test

xWR18xx mmw demo uses HWA to do the FFT processing which uses DPU. DPU is available under C:\ti\mmwave_sdk_03_05_00_01\packages\ti\datapath\dpc\dpu path where is provides HWA or DSP version of processing chain.

HWA register set which applicaton write you can readback and verify but there are internal HWA register/memory which is not accessible for application to read.

Regards.

Jitendra

0 HH Chen over 4 years ago in reply to Jitendra Gupta

Prodigy 70 points

Hi Jitendra,

Thanks for the prompt reply.

Yes I found the test code under ti\drivers\hwa\test folder, but what I am looking for is a demo for the CMULT HWA pre-processing block, not the FFT functionality.

I am trying to enable HWA_COMPLEX_MULTIPLY_MODE_VECTOR_MULT mode in HWA, is there any reference or could you help me figure out what is wrong with my test code? (that lead to all-zero output in HWA_COMPLEX_MULTIPLY_MODE_VECTOR_MULT mode).

0 Jitendra Gupta over 4 years ago in reply to HH Chen

TI__Guru 70100 points

Hello Chen,

Please refer to the existing document from mmwave sdk

file:///C:/ti/mmwave_sdk_03_05_00_01/packages/ti/drivers/hwa/docs/doxygen/html/index.html

And I see reference within hwa.c for HWA_COMPLEX_MULTIPLY_MODE_VECTOR_MULT_2

https://training.ti.com/sites/default/files/docs/HWA_in_mmWave_sensor_1443.pdf

Regards,

Jitendra

0 HH Chen over 4 years ago in reply to Jitendra Gupta

Prodigy 70 points

Hi Jitendra,

I have SDK 03.05.00.04 installed on my computer.

My ti/drivers/hwa/docs/doxygen/html/index.html looks like a API documentation and does not explain how CMULT works:

My hwa.c does contains reference to HWA_COMPLEX_MULTIPLY_MODE_VECTOR_MULT_2, but it's simply used as a boundary checking criteria ...

Looking forward to more pratical advices, or could you kindly help me analyze what conditions are possbile of I've got all-zeros only in VECTOR_MULT mode (while SQUARE mode is fine).

0 Jitendra Gupta over 4 years ago in reply to HH Chen

TI__Guru 70100 points

Hello Chen,

This is a totally new scenario to me, let me check this internally and get back to you by end of this week.

Regards,

Jitendra

0 Jitendra Gupta over 4 years ago in reply to HH Chen

TI__Guru 70100 points

Hello Chen,

Our internal team requires more detailed info about your issue.

What is input, what is the functionality trying to achieve and what are HWA programming parameters and what are the observations?

It would be good if you provide a clear and elaborated version of your issue with some supported data/pictures.

Regards,

Jitendra

0 HH Chen over 4 years ago in reply to Jitendra Gupta

Prodigy 70 points

Hi,

Just to make sure you are able to see my pictures, could you please take a look at the original post? I could paste it again if the pictures are not available any more.

Direct answers:

Q1. What is input?

A1: Manually generated test pattern on L3:

00010000 00010000 00010000 00010000

00030002 00030002 00030002 00030002

00050004 00050004 00050004 00050004

...

(See picture 3 in my original post)

Q2: what is the functionality trying to achieve

A2: DBF using 4 RX bins, that is, output = MAGNITUDE(RX1*weight1 + RX2*weight2 + RX3*weight3 + RX4*weight4)

Q3: what are HWA programming parameters

A3: A very simple pass-through HWA param which enables HWA_COMPLEX_MULTIPLY_MODE_VECTOR_MULT as pre-processing unit, and use FFT as a simple complex adder (only output the 0th bin), and then outputs magnitude of the FFT bin0 result.

(See picture 1 in my original post)

Q4: what are the observations?

A4: ALL ZERO

(See picture 3 in my original post)

Please let me know if more information is required but not given in my original post (with 4 pictures showing the supported data and result).

0 Jitendra Gupta over 4 years ago in reply to HH Chen

TI__Guru 70100 points

Hello HH Chen,

Our team is still evaluating your query and try to reproduce this issue at our end. We will get back to you in two days.

Regards,

Jitendra

0 Jitendra Gupta over 4 years ago

TI__Guru 70100 points

Hello Chen,

I have tried HWA AWR1843 test application with these changes to reproduce your issue

gHWATestParamConfig[paramsetIdx].complexMultiply.mode = HWA_COMPLEX_MULTIPLY_MODE_VECTOR_MULT//HWA_COMPLEX_MULTIPLY_MODE_DISABLE;

errCode = HWA_configRam(handle, HWA_RAM_TYPE_INTERNAL_RAM/* HWA_RAM_TYPE_WINDOW_RAM*/, (uint8_t *)win_data225, sizeof(win_data225), HWA_TEST_1DFFT_WINDOW_START);

WIth These two changes, I can see data copied to HWA RAM location (0x50081000). Here are the steps I have followed

1. Flash ccsdebug.bin to AWR1843BOOST.

2. Change the test application code (main.c) as mentioned above then recompiled it.

3. Load the test application to device (MSS core) via ccs

4. Put a breakpoint in 'HWA_configRam' function and do the step by step debug and check HWA RAM location in CCS memory browser window.

hwa.c --->>>

/* copy the RAM contents */
memcpy((void *)&ramBaseAddr[startIdx], data, dataSize); /* this code execution will update the HWA RAM location */

At this point I can see the data content updated on ramBaseAddr place in CCS memory browser.

BUT next line of this function will reset the HWA RAM location selection, so RAM content will be reset to different content. Effectively HWACCREG7 [24] =0 register will change the RAM type.

Just another info, that there is HWA user guide document which a user needs to refer while feature implementation.

https://www.ti.com/lit/ug/swru527a/swru527a.pdf

Regards,

Jitendra

And in

0 HH Chen over 4 years ago in reply to Jitendra Gupta

Prodigy 70 points

Hi Jitendra,

Thanks a lot for the clue and hint.

I tried your test steps and now know why I cannot write INTERNAL MEM in my project, and I can reproduce this issue in SDK hwa_test project as well.

The internal mem will be inaccessible (non-readable and non-writable) ever since HWA is triggered:

    errCode = HWA_setDMA2ACCManualTrig(handle,HWA_TEST_SRC_TRIGGER_DMACH1);

And it will be accessible again after HWA is closed:

    /* Close the driver: */
    errCode = HWA_close(handle);

To be more accurate, the internal mem will be accessible (readable and writable) only after HWA is reset (the code below is called in HWA_close()):

static inline void HWA_doReset(DSSHWACCRegs  *ctrlBaseAddr)
{
    ctrlBaseAddr->HWACCREG1 = CSL_FINSR (ctrlBaseAddr->HWACCREG1, 6U, 4U, 0x7U);
    ctrlBaseAddr->HWACCREG1 = CSL_FINSR (ctrlBaseAddr->HWACCREG1, 6U, 4U, 0x0U);

    return;
}

While a typical beam steering DBF use case would require multiple different DBF calls per frame, each of which would need a different set of twiddle factors in the internal RAM. I believe it's usually not a good practice to RESET HWA during normal operation, is there any solution for us to be able to update internal window ( with new DBF twiddle factors ) without reseting the HWA engine?

0 Jitendra Gupta over 4 years ago in reply to HH Chen

TI__Guru 70100 points

Hello HH Chen,

Which Internal HWA RAM you are trying to RD/WR? As per HWA test application, I was able to write to HWA RAM from test code. Is it not the same thing you are seeking??

Regards,

Jitendra

0 HH Chen over 4 years ago in reply to Jitendra Gupta

Prodigy 70 points

Hi Jitendra,

We are refering to the same INTERNAL HWA RAM.

You are able to write the HWA RAM because you set breakpoint before triggering HWA , I could read/write before trigger as well.

The internal mem will be inaccessible (non-readable and non-writable) ever since HWA is triggered, please set breakpoint at the line below and then try to read/write internal mem using CCS debug:

    errCode = HWA_setDMA2ACCManualTrig(handle,HWA_TEST_SRC_TRIGGER_DMACH1);



The internal mem will be all zero, and all writes to the internal memory will be ignored (until HWA is reset and get ready again).

0 Jitendra Gupta over 4 years ago in reply to HH Chen

TI__Guru 70100 points

Hello HH Chen,

Apologies for the delayed response.

Based on our simulation result for this particular scenario here are my comments.

HWA Internal RAM is not accessible under these two scenarios

while it is in process of doing some requested task (FFT or compression etc.)
Or even if current task is over but it is set with subsequent paramSet for the next task.

HWA Internal RAM can be accessed while executing a NULL ParamSet, with the next ParamSet triggered only when the internal RAM access is done.
Need to confirm with You about the timing of internal RAM access, if that is falling under the above-mentioned scenario.

Please confirm these points at your end.

Regards,

0 HH Chen over 4 years ago in reply to Jitendra Gupta

Prodigy 70 points

Hi Jitendra,

I guess scenario 2 is my case.

We've taken the workaround that requires an additional HWA reset before configuring the INTERNAL RAM.

Thanks for the help.

0 Jitendra Gupta over 4 years ago in reply to HH Chen

TI__Guru 70100 points

Hello,

Good to know that you have proceeded with the workaround, however, I need to change my above statement a bit around '"NULL pramset"

Instead of NULL Param SET, I should say a paramset with REG_ACCEL_MODE=00b (FFT Engine Path), CMULT_MODE=000b (Disabled) and FFT_EN=0b (FFT-Disabled). Only this setting would allow internal RAM to be written and not the NULL ParamSet (ACCEL_MODE=11b).

Regards,

Jitendra

Sensors

Sensors forum

AWR1843BOOST: AWR18xx HWA Complex Multiplication output is all zero