CodeWarrior not initializing Vars

Repent!

That's not right.

You're right, you shouldn't.

I don't really know, but maybe I can get you pointed in the right direction...

What is your environment? How are you examining the value of GLOBAL_VAR? Is there something in your environment that is interfereing with your application? E.g., a debug monitor whose RAM space overlays your application?

What does your linker map file look like? Where is GLOBAL_VAR located? What is the name of the memory section? What does you compiler documentation say about that section? What happens if you remove the "= 0" from the variable declaration? (Uninitialized static data should be zeroed).

Have you examined the startup code? You know, the stuff that gets executed before the function "main" gets called? Does your environment support the automatic initialization of global variables? Is such support optional? Do you have such support selected in your build configuration? Do you link in the memory section that contains the initialization records?

All just guesswork, but you didn't give me much to work with. HTH,

-=Dave

Maybe the name space conflict, use watch window to figure out the exact problem. Did you try to use name other than GLOBAL_VAR? I've never experienced such problem with CW.

ali

Hello Try increasing stack size, maybe it is stack overflow. How did you create your project, with ANSI startup code or minimal startup code? Regards Petr

... snip ...

Indeed. It appears as if your system doesn't properly initialize static memory on program start.

"Hawker" a écrit dans le message de news: snipped-for-privacy@mid.individual.net...

Hi, You have to use the ANSI Initialization when you're creating your project. All the RAM area will be clear to zero BEFORE your main function, your future global variables and your future stack (local variables).

Yvan

Hmm. Good suggestion. My stack is, I think 0x50 bytes long only. Whatever the default was. Code is small though, under 1k. Not to many vars.

I'm using the minimal startup code and I have all global vars in zero page RAM, of which there isn't much 0x7f - stack (0x50).

On 6/1/2007 2:33 AM, The digits of Petr Cach's hands composed the following:

On 5/31/2007 9:55 PM, The digits of Ali's hands composed the following:

Global Var was a made up name to simplify my explanation and not exactly what I am doing. The reality is I am having this issue with a few global vars.

On 6/1/2007 3:53 AM, The digits of Yvan BOURNE's hands composed the following:

But wouldn't the fact that I assign the var to 0x00 when defined over ride that need? I'm using the quick start up, not ANSI because I need the processor to start VERY fast so I want as little overhead as possible.

Any hardware designer that can't write basic code to help debug their designs should not have a job!

Thanks for learning. Keep up the good work.

Scott

No. Because that is not actually you assigning a value to the variable. That's you telling the start-up code to _initialize_ the variable with that value. Which means if you tell the start-up code not to do the job required of it by the C language, then the job won't be done.

Well, you got exactly what you asked for --- computer have been known for that since before I was born.

You didn't quite get what you wanted, granted. That happend because you didn't quite understand what you asked for.

... snip ...

One method of initializing static variables is by loading them from the executable file. In embedded, you probably don't have such a file, so initialization is not done on a restart. In other cases the start-up code may zero that memory. If you restart (under a debugger) that code isn't exercized.

Gotcha. Now I think I understand. I think I misunderstood a C command in essences. You are right. Unfortunatly given client schedules and budgets I more often then not have to just dive into a tool and guess than take the time to really get to know the tool. Then there is the issue of what disty owns a project (AKA politics). For example when it is an Avnet project we use TI MPS430s or ADI Blackfin, but this was a Future project so we had to use something else - Mot. It has been several years since I put a Mot - err Freescale processor on a board. Infact it was Motorola still last time.

Course I was always taught back in the Pascal days that defining a var and assigning it a value in the same place was not good coding practice anyway so that just means I need to assign a value to a var before I use it the first time. Not a big deal really.

Thanx

I'm surprised you would jump to such a conclusion. The method is just the same in embedded, except instead of an executable file on some file system you have a code image with some extra segments sitting in flash or ROM. The copying is basically a variant of "memcpy", i.e. it copies an image of the entire set of initial values from ROM to their position in RAM on start-up.

What the OP did was turn off an option in the tools described as "ANSI-compliant startup code". Well, what that startup code would have done for him (if he hadn't turned it off) is to perform initialization of static variables as defined by the language, and expected by the OP. I.e. he told the tools he didn't want initialization to take place, and ended up being surprised that variables weren't initialized. As Homer Simpson would put it: "Duh."

Not necessarily. For example, the power on reset code clears all memory and copies the code and non-zero initialized data over. Now the system runs. Halting, and restarting at main, doesn't clear memory. All we know is that he is using an 'embedded system'.

Which is why one should never just restart at main(), and that's not what any self-respecting tools would do. Not in embedded systems, and not in hosted programming either. You restart at the actual start-up vector, which will eventually call main() after all initialization has been done. Tools will sometimes make it _apper_ like they restarted from main(), by running all the way to the beginning of main(), and stopping there. But that's an option that can always be turned off.

In embedded toolchains, the re-start function is usually called "reset", because that's what it does: jump to the reset vector. Some embedded debuggers offer an extra function to more completely simulate an actual hardware reset, for which they re-load all registers with their reset values.

IF everything is optimally set-up. We don't know much about the OPs systems, so I just stuck out another possibility.