Compiler/TMS570LC4357: Global variables initialization in the SDRAM

Thanks for the prompt reply, but

we already activated the SDRAM before calling _c_int00() (for example in GEL file) or before TI_auto_init() in _c_int00().

Should I use #pragma DATA_SECTION for each global variable defined in SDRAM??? It is a bit expensive.

Why this was not necessary for the TMS570LS3137 device (we already used on several products)?

Is there an alternative method?

Thank you

Ciro

Hi Wang,

I don't get any error, I just observe the unexpected behaviour descripted in my intrductive message in this topic.

I am able to use the SDRAM during the execution of my code, so I think that the SDRAM is correctly initialized (I also noticed that with the new source code generated by HALCoGen the errata EMIF#5 has been applied). But when the program starts, after the function __TI_auto_init() is executed, everything in the SDRAM is initialized to 0. This leads to a wrong behaviour in the execution of my application which expects to find tables and global variables initialized.

I try to better explain with an example of what I have observed recalling my previous example explained above with the global variable emacAddress[].

• I first execute my application and during the execution the mac Address is correctly read from the eprom and the value 001EC0AD8D1D is correctly written at SDRAM location 0x80956015

• I reset the CPU and the system without shutting down the power on the board (by this way the SDRAM keeps the old value stored).
• I restart the execution, setting a breakpoint before the function system_init() where the function emif_SDRAM_StartupInit() is called (reflecting the 14 steps foreseen by the errata EMIF#5).
• After the initialization of the SDRAM, the old value stored since the previous execution is shown at the address 0x80956015.

• I follow the execution step by step until the function __TI_auto_init() is called; at this point I notice that the SDRAM gets initialized to 0 even if in my code the global variable emacAddress[] is initialized to 0004A3474F48 (the initialization instruction of the emacAddress was already shown in the first message in this topic) and no initial values ar overwritten before the main() function is called.

For this reason my app starts with all global variables uninitialized.

This is an unexpected behaviour in my point of view.

Is there any reason that explains this behaviour?

How could I get the global variables correctly initialized at main() execution phase?

Are there any settings in build or compiler options to be foreseen to get this issue resolved?

I hope this example is helpful to better understand what I'm trying to explain.

Thank you

Ciro

Dear QJ

we have more details for you.

The SDRAM variable "emacAddress" is defined in C as global (without const) and assigned to a value:

"uint8_t emacAddress[6] = {0x00, 0x04, 0xA3, 0x47, 0x4F, 0x48};"

We build the "exe" with ccsv6  Version: 6.1.3.00034

We try to set different compiler/linker toolchain (TI v5.2.5 and TI v17.6.0) with the same result.

When we load and start debugger, "emacAddress" is 0. (OK) (see IMAGE "1.png" in the attached .zip)

When TI library "run_cinit" function is called, it calls the following 2 subsequent functions, by means of handler pointer, initialized to __TI_Handler_Table_Base [handler_idx].

The first call is "__TI_decompress_lzss" that sets "emacAddress" to the expected value (OK) (see IMAGE "2.png" in the attached .zip)

The second call is "__TI_zero_init" that clear to 0 "emacAddress" (WRONG). (see IMAGE "3.png" in the attached .zip) 

All the subsequent calls are "__TI_zero_init" , and "emacAddress" remains 0 (DONT CARE).

5706.linker_problem.zip

Note:

When we removed the "--zero_init" Linker->Miscellanea option, obviously the variable remained at expected value, but this created other problems on all the other variables that need to be cleared at startup!! This is not a solution.

2 things:

1) Is it correct the calls order (first set the values and then clear?). In which file of compiler tools, the function order is set in "__TI_Handler_Table_Base" table? We cannot found.

2) If the order is correct, why the  "emacAddress" address is included in both the area to set to (decompress) a value and also to the area to clear (zero init)?

I hope this can help your understanding.

PLEASE HELP US!!

Note that, in the best case (you answer soon), we have at least 24h of delay between the instant we wrote and your reply.

Thank you in advance

Ciro

Paolo

Hello QJ,

we have found the root cause of our issue:

the register SDCR of the EMIF module was erroneously set to 0x00004400 after emif_SDRAM_StartupInit(). The last byte is overwritten to 00, this leads to a wrong value set for page size and blocks number parameters.

The SDCR overwrite is due to the last instruction in the emif_SDRAM_StartupInit() function generated by HALCoGen (v 04.06.00)

Now, considering that my device is a TMS570LC4357 (big endian), it’s wrong to add 0x3U to the SDCR address; by correcting this instruction everything works correctly.

So, WHY does HALCoGen add 0x3U to the SDCR address like my device was little endian??? Is there any setting in HALCoGen to set the endianness of the device? (I didn’t found any, I thought that it was enough to specify the device when generating a new project).

Thank you

Ciro

Yes, but why does HALCoGen  add 0x3 even if I specify that my device is a TMS570LC43x? Is there any method to generate automatically this piece of code with 0x0? Otherwise every time that I change any setting in whatever module I have to change this value again in HL_emif.c.. it's not so comfortable!!

Ciro