TMS570LC4357: No init memory on reset for storing reset information

Hi,

Memory HW initialization will clear the memory content, and RAM PBIST will also clear the content too.

 NOINIT_RAM      (RW)  : origin = NOINIT_RAM_START_ADDR      length = NOINIT_RAM_SIZE  

This is out of the valid range of SRAM which is 0x0800_0000~0x0808_0000

Hi,

I don't think my NOINIT_RAM section is out of valid range. NOINIT_RAM_START_ADDR is RAM_START_ADDR + RAM_SIZE which is 0x08005600+0x0007A900=0x0807FF00 and NOINIT_RAM_SIZE is 0x000000100. So it should fit in the valid RAM, that is not an issue. Also I could validate these sections in the map file:

  STACKS                08000000   00004e00  00000000  00004e00  RW  
  KRAM                  08004e00   00000800  00000168  00000698  RW  
  RAM                   08005600   0007a900  0006b5cf  0000f331  RW  
  NOINIT_RAM            0807ff00   00000100  00000070  00000090  RW  

About the HW memory initialization and the RAM PBIST: as I can see these are performed during the c_init inside the mem_init function. Before even getting to this point with the debugger the content of the NOINIT_RAM section is cleared right on the reset trigger.

In the reference manual at section 8.3.8 L2RAMW Memory Initialization Domain Register (MEMINIT_DOMAIN) I ound that the MEMINIT_ENA bits are all set to enabled on reset. Could this cause the ram to be initialized?

So, is there any other settings to prevent clearing the ram on warm reset?

Hi Marton,

Sorry for my wrong calculation.

Marton Zsebok said:

the MEMINIT_ENA bits are all set to enabled on reset. Could this cause the ram to be initialized?

No, this doesn't initiate the SRAM auto-Initialization. The MEMINIT_ENA bits are used to turn on the RAM domains (8 domains in total), and those domains are enabled by default. The auto-init starts when MINITGENA is set (0xA) , and MSINENA[0] is set. So the default settings of MEMINIT_ENA doesn't start the memory init.

Do you enable the cache by calling  _cacheEnable_() before your read the variable? When you enable cache, it will first invalidate all data in the cache memory. Your data is first stored in the level-2 SRAM. As the data is read, it is then stored in cache for fast access in the future. When you do a reset, the CPU starts from _c_init00() and will execute the _cacheEnable_() to invalidate the cache. The data in cache is cleared while the level-2 SRAM is not updated  due to the cache write-back scheme.

One question for you:

I am not sure if the following declaration is valid or not, and I don't have HW board to try now.

#define NON_VOLATILE_DATA __attribute__ ((section(".noinit")))
NON_VOLATILE_DATA static char data[16];

Before I try them, can you use the following way which is listed in compiler (TI ARMCL compiler) user guide:

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

#pragma NOINIT (x )
int x;

Hi Marton,

You may find useful info from this thread:

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/422177/__ti_auto_init-and-gcc-questions-for-tms570lc43/2002436?tisearch=e2e-sitesearch&keymatch=NOINIT%252525252520AND%252525252520SRAM#2002436

Hi,

Thanks for the link, but I think my problem is not linker related.

I've tried the #pragma NOINIT (x ) declaration, and according to the map file my non volatile variable will be placed in a section called .TI.noinit, but it is still initialized to zero upon reset.

This is what I see from the debug session when the non volatile variable have been written:

And this is right after the warm reset, the PC is still on the resetEntry before c_init, and the non volatile variable is cleared:

Marton Zsebok said:

This is what I see from the debug session when the non volatile variable have been written

Is the non volatile variable in an address which is Write-Back cacheable?

If so, after the warm reset occurs the variable might not have been written to actual SRAM before the warm reset occurred.

I've checked my mpu configurations, the cache is enabled but all mpu regions are set to default in Halcogen, and the cache has been disabled for the SRAM range.

I even tried to create a new mpu region with parameters: shared and the cache disabled:

The issue is the same as before, after reset the PC is on the reset vector, and the RAM has been cleared.

Is there any way to disable Write-Back cache for this memory region?

Hi Marton,

If the memory region (#7) is "Normal_OINC_SHARED", the data in this region will not be cleared if this region is type=NOINT

If the memory region (#7) is "Normal_OIWTNOWA_NONSHARED", the data in this region will not be cleared if this region is type=NOINT

sys_main.c:

#define NON_VOLATILE_DATA __attribute__ ((section(".noinit")))
NON_VOLATILE_DATA static char data[16];

sys_link.cmd:

.noinit : {} > NOINIT_RAM  type=NOINIT

sys_startup.c:

the _memInit_() should be commented out

// _memInit_();

You can select the OIWT (write-through) or OIWB(write-back) from the drop-down menu:

I've disabled the cache write back for the whole SRAM region, and the result is the same: after the warm reset the debugger is on the "resetEntry:b   _c_int00" and the RAM has been cleared.

I have also tried with the above configurations with memInit() commented out, the RAM still has been cleared.

I have no clue what would I have missing.
I'm starting to doubt that no-init ram on warm reset on this MCU is not possible.

Are there any working example for this scenario? (for no-init ram to store data on warm reset)?

Hi Marton,

I don't have a working standalone project. I will create a simple one for you later.

After reset, the variables at 0x0807f000 memory region are not cleared:

TMS570LC43x_GlobalVariables_NoInit.zip

Here is the ccs project used for my test

Hi QJ,

Thank you for the example, it is working just fine. I tried to modify my own project with the settings from this example and it still not worked for me for the first time.

Then I realized that I am using FreeRTOS in my project and in the rtos port implementation the MPU has been re-initialized by the RTOS, so that was the cause of my changes in the MPU settings were not working.

With changing the RTOS mpu settings everything works fine.
Thank you for the support!

Best regards,
Marton