AWR2944EVM: Warm Reset Behavior

Hello,

Warm reset will not reset the RAM. You can refer to the below thread for some more details on proper implementation.

https://e2e.ti.com/support/sensors-group/sensors/f/sensors-forum/1126128/awr2944-warm-reset-is-reinitializing-the-mss_l2-and-dss_l3-ram/4210848#4210848

Regards,

Adrian 

Hi Adrian,

So for understanding, what is the difference between MCU_PerformReset and SOC_rcmR5PowerOnReset(); SOC_rcmR5TriggerReset();?
Does any of them reinit RAM to zeroes? Does any of them reload SBL from external flash.

I have tried both reset methods:

1. Using MCU_PerformReset, I find random value in RAM after reset and the SW is in unknown place.

2. When I used these functions " SOC_rcmR5PowerOnReset(); and SOC_rcmR5TriggerReset(); " to trigger a reset as suggested in the threads but the issue is I am stuck in SBL in issue in relevant to clock. Please check below error and call stack hierarchy.

To explain my setup, We have SBL initially then followed by application binary which is using AUTOSAR TI MCAL. In application we have some clock initialization where parameter McuInitClock is enabled and parameter McuNoPll is enabled.
So there is no PLL initialization done in MCAL but still MCU module is doing some initialization.
The issue now is that SBL rechecks this and assert the SW. Could you please check what could be wrong here?

BR,
Andrew

Hello Andrew,

I am looping in our software expert to look into this. He should respond today or tomorrow.

Regards,

Adrian

Hello Andrew,

For the SBL can you please use the reference from the SDK 4.4.1.2 and also use the latest MCAL version 2.0.5.1.
Also in the SDK both the SOC_rcmR5PowerOnReset(); and SOC_rcmR5TriggerReset(); are required for the warm reset.
The SOC_rcmR5PowerOnReset is used to configure the chip to go into a reset when it goes to idle state only.

Regards,
Saswat Kumar

Hi Saswat Kumar,

I did exactly what you asked to integrate everything to the latest which took considerable amount of time but it didn't work out.

Now after some analysis in Bootloader_socConfigurePll function, 

First time after PoR, your code is doing the following

1. R5 frequency is being set to 400 Mhz which Efuse Boot Frequency.
2. Change R5 CLK source to XTAL.
3. Initialize ADPLL.
4. Change R5 CLK source to DPLL
5. Set R5 frequency to 300MHz

Second time after Reset using the suggested APIs.

1. SW tries to set the frequency again to 400MHz but you have a check inside SOC_rcmGetModuleClkDivVal API that inFreq%outFreq==0

This check passes after PoR because the frequencies are according to EFUSE boot frequency, and the expected frequency is indeed 400MHz but it fails after SW reset because after all PLL initialization from first initialization the frequency is 300MHz.

What is the best way to solve this? 

BR,
Andrew

Hello Andrew,

Are you using a custom board or a EVM?
If using the EVM, can you run it straight out of the SDK so I can understand whether it is an issue with the porting you did or the board itself.
In the SDK, the R5 is not set to 400 Mhz, it is set to 300 Mhz.
also please use the clock initialization from the SDK itself, and don't mix the clock configuration with MCAL+ SDK.
You can first develop it with the SDK and then port it to MCAL once its in a working condition.

Regards,
Saswat Kumar 

Initially, I had same issues with EVM regarding reset.all my previous comments and screenshots are from EVM.

But now I'm working with custom board and I see also same issue with reset.

MCAL is configured not to touch PLL. So it's only SDK.

In custom board the EFUSE returns 400 MHZ. Didn't Check that in EVM but I expect it's the same value because I had same symptom.

Please check my previous screenshots