AWR1843BOOST: HWA Reset function doesn't work

Hi Daniel,

Welcome to E2E!

The only OS specific code I see in that call is disabling and restoring hardware interrupts to create a critical section. Another thing is that ctrlBaseAddr->HWACCREG4 = CSL_FINSR(ctrlBaseAddr->HWACCREG4, 31U, 16U, 0x0U); isn't there in the HWA_reset method. This exists in the ISR to clear the interrupt flag. Was your code not working without this? Perhaps this could indicate an issue with HWA_paramDoneISR not being able to clear this for the previous paramset?.

You could also put a breakpoint in HWA_doReset in the HWA driver to verify if this function is being called. It is possible that this code isn't being executed. This should narrow down the issue a little.

Regards,

Aayush

Hi Aayush,

thanks for your answer and the welcome in the E2E forum!

Good point with the critical section, which I had also already suspected, however I disabled the IRQ(value=1) and FIRQ(value=1) bits in the Current Program Status Register (CPSR) before I run the code above and disable them afterwards. so this cannot actually be it, unless this is the wrong register.

And you are right, the code line for resetting the internal state machine in the HWA:

ctrlBaseAddr->HWACCREG4 = CSL_FINSR(ctrlBaseAddr->HWACCREG4, 31U, 16U, 0x0U);

are not executed in the HWA_reset method. But if you read the Docu of the HWA and put a breakpoint on this method you will find out that the state machine will be resetted:

Also the HWA_paramDoneISR Interrupt is a good point, but in the demo code (C:\ti\mmwave_sdk_03_05_00_04\packages\ti\datapath\dpu\rangeproc) only a HWA_allParamDoneISR interrupt is thrown and in this interrupt routine the status register in the HWA will not be reset and during further debugging the status register is only set to 0 when the HWA_reset method in the DPU_RangeProcHWA_config is called.

But is it possible to put a breakpoint in HWA_doReset in the HWA driver? Because after jumping to line 503, the demo program crashes:

What I did instead was to set a breakpoint before and after the HWA_doReset and there I could see that the internal HWA state was cleared in the Demo.

But yes, I'm not sure if the HWA_doReset is executed in my Code.

Hi,

Just a clarification on the theory:

1. From the HWA user guide: "reset must be asserted by writing 111b followed by 000b to the ACCRESET register". This corresponds to the HWA_doReset function, which is called by HWA_reset. In your code, this corresponds to:

ctrlBaseAddr->HWACCREG1 = CSL_FINSR(ctrlBaseAddr->HWACCREG1, 6U, 4U, 0x7U);
ctrlBaseAddr->HWACCREG1 = CSL_FINSR(ctrlBaseAddr->HWACCREG1, 6U, 4U, 0x0U);

The following line however, is not used for HWA reset:

ctrlBaseAddr->HWACCREG4 = CSL_FINSR(ctrlBaseAddr->HWACCREG4, 31U, 16U, 0x0U);

This register is written to in the HWA driver to clear paramset done interrupt in the HWA_paramDoneISR. That line of code actually shouldn't have any effect in your code as you are just writing zeros, but I just wondered why it was there.

Coming back to the driver, and the FreeRTOS port, if HWA_doReset is called, the appropriate registers for reset are being written to.

It does seem that you can't put a breakpoint in HWA_doReset. In cases like these, I like to add a global volatile counter, increment the counter in the function of interest, let the program run for a little while, pause execution and check the counter value in CCS. You could also but a breakpoint after the HWA_reset, which will ensure that you only see the counter increment by one. Could you do the same in the HWA driver, recompile and check if the counter increments? 

I can see two scenarios with your HWA driver port: either HWA_doReset never gets called, or it does get called, but the compiler somehow ignores the volatile keywords, and optimizes out the register writes. 

Another thing to check for is the HWA_enable function. The HWA must be disabled before resetting the state machine. Could be worth ensuring that HWA_enable is working.

Please let me know if you have any findings, our HWA driver should ideally work as soon as the correct OSAL layer is provided for it, so the challenge you are facing is of particular interest.

Regards,

Aayush

Hi Aayush,

thanks for the clarification.

To the problem that I can put a breakpoint in HWA_doReset, but the program terminates after a second due to a memory read error (this happens exactly after this line: ctrlBaseAddr->HWACCREG1 = CSL_FINSR(ctrlBaseAddr->HWACCREG1, 6U, 4U, 0x7U)):

I add a global counter which will increment in the HWA_doReset. However, after executing the HWA_reset method, the counter was increased. Therefore the HWA_doReset should be executed.

In my further analysis I compared the assembler instructions of freeRTOS(left) with the TI Demo(right):

I'm not that good with assembler, but what I noticed was that when I execute HWA_reset, there is another jump to HWA_doReset and also other registers are used (maybe for optimisations). But could this be a problem and how can it solve?

I also checked, before the HWA_reset is called, that the HWA is disabled, but also this is implemented in the DPU_RangeProcHWA_config and is also executed by checking if the global variable is incremented and the ACCENABLE bits are set to 000b:

Regards,

Daniel

Hi Daniel,

It does seem that register is being written to. I will have to discuss this with my team and get back to you. Let me get back to you early next week.

Regards,

Aayush

Hi Aayush,

okey, yeah that is a bit strange.

I also look forward to hearing back from you, with perhaps possible causes.

Thanks & Regards,

Daniel

Hi Daniel,

Sorry I don't have a response for you yet. I will have this discussion. I am wondering, could you share your osal .c file? Perhaps I could have a look and see if I can spot something. If you don't feel comfortable sharing it here, you could send it as a private message on E2E to me.

Regards,

Aayush