memoryinitializationembeddedgreenhills

Value of variables are changed unexpectedly


I am writing embedded code in GHS environment and I am facing such a strange issue that I have never encountered before. All global variables except for constant ones which are initialized before run-time are set the highest value of a data type. For example:

I define a global variable:

static uint8 Dcm_Cbk_Gu8_FirstReqAfterReset = 1;

However, the value of the variable is always set to 255 no matter what the initial value is. I am sure that the variable is not used yet anywhere in the code. If the data type is uint16, the value shall always be 65535 until It is changed in run-time. Well, It happens to all global variables no what the data type is.

Note that the situation doesn't occur if the variable is declared globally and initialized in run-time, but this way violates the coding convention.

Actually, Everything works well in another environment (built by make) but when I Merged the code (*.c,*h) and move the whole linker file to a different environment (built by Scon struct), I got the issue. The MCU that is used is chorus 10M (SPC58NH92).

Anybody knows about the reason, could you please broaden my knowledge? Thank you!


Solution

  • With the limited information in the question, it is hard to give a definitive answer. I can tell you what it looks like to me though.

    The initialized global or static variables make up the .data section. These values should be stored within the read-only memory (typically within .text) and should be copied into the .data segment during the start-up routine of the program.

    If there is no proper code in the start-up routine to copy these values, they will be uninitialized. So, check whether you have such code. (I did work in a GreenHills environment where we did not have such code provided by the compiler. We had the choice of writing it ourselves or not using the .data segment and initializing everything towards the beginning of main).

    However, this is unlikely to be your whole problem. You may or may not have the correct startup code. If you had your memory segments set up correctly but were missing startup code, I would expect to see random values in RAM. Consistent 0xFF looks to me like one of two things:

    1. Startup code which preinitializes all of RAM to 0xFF, and the values either loaded before that (and overwritten) or not loaded at all
    2. Your linker file is not set up correctly, and is located the .data segment in flash memory rather than RAM (uninitialized flash memory is generally all 0xFF, which is what you are seeing.

    I think the second one is more likely, but I know neither the memory map of your hardware nor the setup in your linker definition file. You will have to check that yourself.