AWRL1432: retain memory after warm reset

James,

Bank 3 range is from 0x460000 to 0x47FFFF.

I tried MMWAVE_L_SDK_05_04_00_01\examples\drivers\watchdog\watchdog_reset. After load the test code, I changed the value at 0x460000 and 0x470000 to non-zero. After wdt demo run, I suspended the m4 core and I found the value at 0x460000 and 0x470000 are turned to zero in CCS memory viewer.

Would you pls help to double check?

Thanks,

Chris

James,

Customer found if only calling SOC_triggerWarmReset API, the bank3 memory content can be retained.

I checked the watchdog_reset demo again and found before handleWdtRst(), the value in bank3 is retained, but after this api, the value in bank3 will clean to 0. After handleWdtRst(), RBL will run again to reload flash. Does this clean the value in bank3? There is no APP code or data at 0x460000. Why it is cleared to 0?

Thanks,

Chris

Hello Chris, I am checking with my team on this.

Hi Chris,

Please check our watchdog example documentation in the SDK. There are two demonstrations of functionality in that example. I believe there is a flag to decide which route is taken.

The route which you are going through will perform a whole reload from flash on warm reset so it will not retain ram3.

Regards,

Tim

Tim,

Customer would like to save some data/flag after warm reset in app. On AWR1843, customer used retained memory to implement it.

Would you pls kindly advise how to achieve it in AWRL1432?

Thanks,

Chris

Hi Tim,

Any comment?

Thanks,

Chris

Tim,

Yes. I also suspected this causes the clearance. But I tried to modify the cmd file(see below) and let the test app not use bank 3 at all. The bank 3 is still cleared to 0 with the new test app.

Test steps with new warm reset test app (using below cmd file)

1. Burn the image to flash

2. Power on the EVM. Connect the M4 in CCS. Load symbol. Change the value at 0x460000 to 0xAAA.

3. Continue to run at CCS. See print on CCS consol.

4. After print stops and see below, stop M4 core in CCS and check the value at 0x460000 and it turns to 0.

Would you pls help to check if anything is missed in the test process?

1538.linker.cmd

Thanks,

Chris

Tim,

Yes. handleWdtRst() is called. But in this API, it  calls warm reset SOC_triggerWarmReset() at last. Why do you say a full reset will be performed?

Thanks,

Chris

Tim Henderson said:

the bootloader actually performs an entire reload from flash.

Chris Meng said:

But I tried to modify the cmd file(see below) and let the test app not use bank 3 at all.

Tim,

The app image doesn't use bank 3 so I think even RBL copied the flash content to RAM it will not clear the bank 3 as it will only copy the flash content based on section info to internal memory.

Thanks,

Chris

Chris,

I believe that memory will be invalid after the reload from flash, even though there is no load to it.

Can I understand better the amount of memory that's trying to be saved over a warm reset?

Regards,

Tim

Tim,

Would you pls double check with RBL team? I think RBL will only copy the flash data based on RPRC info.

Thanks,

Chris

Hi Chris,

Let me check and get back to you.

Regards,

Tim

Tim,

Would you pls help? Customer is pushing for feedback.

Thanks,

Chris

Hi Chris,

Our RBL initializes memory when it goes through this flow... so it will be expected that the region of memory is set back to 0x0 in this flow.

Regards,

Tim

Tim，

Thanks for your reply. Seems bank3 can not be used in this case.

Is there any register can be used by customer to save some flags after warm reset on AWRL1432?

Best regards,

Chris

Hi Chris,

This was my next question as well. I don't believe so but checking with that team. I'll have a response next week.

Regards,

Tim

Tim,

Any update? 

Thanks,

Chris

Hi Chris,

Can you actually try the same procedure at HWASS RAM at 0x60000000, and see if you can see data being retained?

Regards,

Tim

Tim,

I found below code in gesture_ recognition.c.

So I tried the memory at 0x60067FFC and 0x60040000. These memory can be retained after the watchdog test code. But these memory will be clear after above memory init. I will check with customer to see if it is ok to check the value before the memory init in their application.

Thanks,

Chris