• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 56 subscribers
  • Views 2460 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CCS/TMS320C28344: Initializing Static and Global Variables

Antenna_Head
Genius 11395 points
Part Number: TMS320C28344
Other Parts Discussed in Thread: C2000WARE, CONTROLSUITE

Tool/software: Code Composer Studio

Note: This is actually for TMS320C28075, but E2E didn't recognize that part number.

According to the TMS320C28x C/C++ compiler manual, in the section “Initializing Static and Global Variables”, static and global variables that are not explicitly initialized will remain uninitialized, in violation of the C standard which requires that they be initialized to zero.

 

We just noticed this statement in the manual, and we are at a late stage where it would be cause some pain to change our code to account for it.  And according to experiments that I have run, the manual actually does not seem to be correct.  As far as I can tell, static and global variables are correctly initialized –  I assume in some startup code that is run before our application code.  I have tested this when booting either from internal flash memory or from an external EEPROM (we utilize both).  Each time that I pull on the processor’s reset pin to reboot it, variables that were previously set to non-zero values are reset to zero, without explicit initialization in our code.

 

A couple of other details:

  • We are using the --rom_model linker option.
  • We do not specify a fill value in the linker command file.

 

Can you confirm that we can count on this initialization of all static and global variables, despite the contrary statement in the manual?

  • 0
    TI__Genius 9520 points

    Antennahead,

    Several comments to your question:

    1. The P/N should be F28075 rather than C28075;

    2. It's more likely a compiler issue rather than a CCS issue so it's better you move it to compiler forum;

    3. Which version of  TMS320C28x C/C++ compiler manual you looked at? The latest one should be SPRU514M, and you can review the whole session of

    6.12 Initializing Static and Global Variables again;

    4. F28075 has ECC function and we'll support RAM initialization (to zero) by setting related INIT bit in corresponding RAM block registers (see 2.11.1.9 RAM Initialization chapter in TRM), which is different with previous legacy C2000 devices.

    I'm not an expert from neither C2000 BU nor Compiler team, so you should also hear more ideas from them.

    Best Regards,

    Ricky Zhang

  • 0
    TI__Guru**** 232700 points

    Antennahead said:
    Can you confirm that we can count on this initialization of all static and global variables, despite the contrary statement in the manual?

    Unfortunately, no.  The manual is correct.  The wiki article Uninitialized Static Objects Not Set to Zero in COFF discusses this issue in more detail, while concluding the same way.

    Antennahead said:
    As far as I can tell, static and global variables are correctly initialized –  I assume in some startup code that is run before our application code.

    If that is occurring, it is not because of anything the compiler did, or anything in the RTS library supplied with the compiler.  I'm afraid you have no choice but to dig into the details of the startup code, and understand precisely how this initialization happens.

    Thanks and regards,

    -George

  • 0 in reply to Ricky Zhang
    Prodigy 80 points
    Ricky, thanks very much for your response. Antennahead posted the original question on my behalf.

    As you pointed out, all of the RAM in the F28075 has either ECC or parity, and therefore must be initialized to prevent errors. And section 3.2 of the TRM indicates that this initialization is performed by the boot ROM.

    This seems to be very good news, as it says that I can count on the initialization always occurring at boot. To confirm this, I tried one final experiment, and unfortunately I was disappointed with the result. With my code running I examined the contents of the LSxINITDONE register (my static variables are stored in LS RAM). I expected to see the LSxINITDONE bits set to 1, indicating that the memory had been initialized by the boot ROM. But I was surprised to find that all the bits were 0. If I use the LSxINIT register to cause an initialization, then the bits in LSxINITDONE change to 1.

    Any thoughts about this experimental result?
  • 0 in reply to Dan Schwartz
    TI__Mastermind 30255 points
    Dan

    Did you perform a power-on-reset or XRS type reset for the device? RAM initialization isn't performed on all resets. If you reset through the debugger, it won't run RAM initialization.
    Note if you want to see the boot source, it's in C2000Ware (~\libraries\boot_rom\f2807x)

    Best Regards
    Chris
  • 0 in reply to Christopher Chiarella
    Prodigy 80 points
    Bingo! Thank you Chris (and Ricky and George and Antennahead). The problem was that I was resetting through the debugger so I could observe the registers. I instead set up an LED to tell me the register state, and got the expected result when I reset by cycling power.

    And thanks for the pointer to the boot source. I have ControlSuite installed, not C2000Ware, but I found the files and found the memory initialization statements in c1brom_Init_Boot.asm.

    Thanks again -- this is a big help.

    Dan