AM2634-Q1: Additional inquiries regarding RAM initialization

Hi Choi Jiung,

You can use NVM memories like Flash, MMCSD (support yet to be integrated for AM263x) to retain the data across resets.

Best Regards,
Aakash

Hi, Aakash Kedia

Ultimately, we want to tell QSPI_SBL about this by writing the signature into RAM on programming request.

When writing a signature to NVM, it cannot be repeatedly written/erased. Also, issues in terms of booting speed may occur.

In the case of other MCUs, signatures are generally written in RAM or special registers that are cleared only at POR are used.

In the case of AM2634, what behavior do you expect from the application to enter the bootloader?

This should be distinguished from a normal reset request.

If there is a good way to go about this, please let me know.

Best Regards

Jiung Choi

Hi Choi Jiung,

In SBL QSPI, Bootloader_socInitL2MailBoxMemory() is called which calls, SOC_rcmMemInitL2Memory() and that initializes Bank 2 and Bank 3.

Writing to this registers, initializes the memory with 0.

Please try commenting the code, which you do not intend to initialize (here L2 Bank 3), re-initialize the library and try with the custom SBL.

Hope this helps.

Best Regards,
Aakash

Hi,  Aakash Kedia

As you said, the "Bootloader_socInitL2MailBoxMemory" function initializes the memory.
But the current problem comes before that.

Currently, right after the main function starts, I use the "loop_forever" function to hold the program counter and check the memory.

But the above problem still occurs.

However, this RAM initialization problem occurs only when Warm Reset is performed in Application SW.

RAM initialization does not occur when performing a WarmReset within QSPI_SBL.

I wonder if there is any branch before QSPI_SBL is loaded.

Here's my test method:

Initialized case

1. Load QSPI_SBL

2. Load Application SW

3. Write signature to RAM(0x701FFFE0) and trigger WarmReset

4. Check RAM area

5. Reset : Initialized to 0

Non-Initialized case

1. Load QSPI_SBL

2. Write signature to RAM(0x701FFFE0) and trigger WarmReset

3. Check RAM area

4. Reset : Signature is maintained without being initialized

Please let me know if there is any additional information you need.

Best Regards

Jiung Choi

Hi Choi Jiung,

I tried with Hello World Example and modifying the value at 0x701FFFE0 location in case of QSPI boot with the following changes in the driver.

It works for me. Please check something is not correct on your end OR check the linker file of your application. Hope you are not initialing the entire SRAM memory as this is part of your *.bss region.

Best Regards,
Aakash

Hi,  Aakash Kedia

Thank you for quick response.

However, the result is not the same as my phenomenon.

I performed a test using only the example below and reproduced the problem.

Example Project

1. sbl_qspi_am263x-cc_r5fss0-0_nortos_ti-arm-clang

I added only the loop_forever function as shown below.

2. hello_world_am263x-cc_r5fss0-0_nortos_ti-arm-clang

I added code to only write 0x1234 to the 0x701FFFE0 area and call the SOC_generateSwWarmReset function.

Test and Result

1. Invalid values stored in SRAM after POR

2. The result of changing the "loop" variable value to 0 to escape the loop_forever function and pausing after running.

The loop_forever function is before the Bootloader_socInitL2MailBoxMemory function is executed.

So my expectation is that 0x1234 is stored in the 0x701FFFE0 area due to the action in the "hello_world_am263x-cc_r5fss0-0_nortos_ti-arm-clang" project.

But the RAM has been initialized.

if the "hello_world_am263x-cc_r5fss0-0_nortos_ti-arm-clang" project hadn't been done, WarmReset would not have happened, so this is a false assumption.

Also, project "hello_world_am263x-cc_r5fss0-0_nortos_ti-arm-clang" has no other branches.

The linker in both example projects above does not define the 0x701FFFE0 region.

Can you let me know if there are any problems with my tests?

Also, if possible, could you please do the same test as me?

Regards

Hi Choi Jiung,

Choi Jiung said:

Can you let me know if there are any problems with my tests?

Is the cache enabled for the memory at which you are writing ? If yes, can you make sure to invalidate and writeback the cache on that location ?

Choi Jiung said:

Also, if possible, could you please do the same test as me?

It was same setup and it worked for me.

Best Regards,
Aakash

Hi,  Aakash Kedia

After importing the example, I didn't change anything other than the code fixes mentioned above.

Is there a separate project setting or compilation setting to disable the cache?

Best Regards

Jiung Choi

Hi,  Aakash Kedia

As you said, this was a cache problem.

Using the above two functions, we confirmed that it was normally written and maintained in RAM.

Thank you so much for your support.

Best Regards

Jiung Choi