topic Re: rouge memory changes in Classic/Legacy CodeWarrior

rouge memory changes

NZ_Design — Mon, 15 Jan 2007 06:13:42 GMT

I have an issue where buy if I reset my design by pressing the reset button it works fine. Values are as they should be.

If I reset it by turning the power off and on the values are changed.

This is happening in portion of code that has no access to the values that are changing. The value in question is in the middle of the internal memory allocation. It is not close to the Stack or the end of the memory area. I have increase the stack to be sure it is not being over flowed. The value is corrict dirrectly prior to calling a routine and as soon as the routine is entered it is incorrect.

This value doesent chage when the code is reset by hardware!!!!!!!!!!!!!

Has anybody come accross anything like this before.

Re: rouge memory changes

NZ_Design — Mon, 15 Jan 2007 07:57:48 GMT

Additional infomation here is the code

cnt starts at 640.

do {
if (cnt != 208) { // cLiveProgLoadStatus is changed when cnt is = 208

// this dosent matter if you start cnt at 0 and go to 640

                                                                                   // or if go from 640 to 0
      ghw_auto_wr(dat,1);
   }
   else {
     Program[1].Outlet[2].cSize2 = cLiveProgLoadStatus; // value is still 15 at this point.
     cLiveProgLoadStatus = 15;                                 // load backup with 15

}

}while (cnt-- != 0);

If the "else" part is romeved cLiveProgLoadStatus will be set to 2.

It cant have anything to do with the calling of the routine as this is not done if cnt is 208. It must have something to do with cnt.

Any ideas

Remember only under power up reset.

Re: rouge memory changes

bigmac — Mon, 15 Jan 2007 14:02:03 GMT

Hello,

I assume cnt variable is global and that it needs to be initialised to a value of 640 for either POR or other reset. If your project uses minimal start-up code (not ANSI compliant start-up code), my understanding is that the globals will not be correctly initialised. This might account for what you are observing. Suggest running the code under simulation to see whether the variable is being initialised.

Regards,

Mac

Re: rouge memory changes

NZ_Design — Tue, 16 Jan 2007 03:31:33 GMT

no cnt is not global.

Yes it is always being initalize just prior to the snipit of caod I have supplied.

My experiance with the code initalization of the global variables is not very trust worthy and I are now initalizing my variables my self.

Re: rouge memory changes

bigmac — Tue, 16 Jan 2007 10:01:21 GMT

Hello,

If the variable is not global (or static), it will actually reside on the stack, whilst it is in existence. So your problem is not clear to me.

I can only reiterate that using full chip simulation should reveal which variables have been initialised correctly, and may point to the problem area of your code.

Regards,

Mac

Re: rouge memory changes

NZ_Design — Tue, 16 Jan 2007 10:41:53 GMT

The problem is that this point in the code changes global variable cLiveProgLoadStatus when it is not even accessesed in this routine.

the only relevence cnt has it that it does it when this value is 208.

running in the debugger is no use as it only happens when the system is powered up ie 0v to 5v on vcc.

it is fine if run by pressing reset or in the debugger.

there are no interrupts enabled at this point in the code so it is not another interrupt causing the issue.

The problem has to be solved without using the debugger

Re: rouge memory changes

bigmac — Tue, 16 Jan 2007 11:43:29 GMT

Hello,

Then the global initialisation issue may lie with the global variable cLiveProgLoadStatus - after POR this will contain some random value, but for a manual reset the value will remain unaltered from prior to the reset (assuming initialisation does not occur in the start-up code).

Also assuming the function ghw_auto_wr() does not alter the global value, I would expect its value to be set to 15 only when cnt reaches a value of 208 (during the "else" portion).

My reason for suggesting use of the debugger is that it will specifically indicate when a variable remains "uninitialised" since reset.

Regards,

Mac

Re: rouge memory changes

NZ_Design — Tue, 16 Jan 2007 11:56:07 GMT

cLiveProgLoadStatus is always initalized prior to reaching this code.

the correct code without the diagnostics is this

do {

ghw_auto_wr(dat,1);

}
while (cnt-- != 0);

upuntil cnt reaches 208 cLiveProgLoadStatus is 15 as it was initalized to

while cnt is 208 cLiveProgLoadStatus changes

the previous code is what I have put in to diagnoise when cLiveProgLoadStatus changes.

there is no code inside ghw_auto_wr that reads or writes to cLiveProgLoadStatus.

I accecpt that cLiveProgLoadStatus will have a random value in it at POR but between POR and ghw_auto_wr it has been set to 15 whiches what it is ment to be.

The problem isnt that cLiveProgLoadStatus is set to 15 when cnt is 208 the problem is that when the code is without the doagnostic it is changed from 15.

"My reason for suggesting use of the debugger is that it will specifically indicate when a variable remains "uninitialised" since reset." How???

Re: rouge memory changes

CrasyCat — Tue, 16 Jan 2007 22:10:00 GMT

Hello

I am not sure I understand the issue here.

Are you looking for a way the debugger should notify you when a specific memory area is changed?

Or what are you looking for exactly?

CrasyCat

Re: rouge memory changes

NZ_Design — Wed, 17 Jan 2007 03:33:51 GMT

No I wont to no why cLiveProgLoadStatus changes when there is no code accessing it.

Re: rouge memory changes

NZ_Design — Wed, 17 Jan 2007 11:10:24 GMT

For those that would like to know

The problem arises from the time between powering up and reset going high is to short.

The development board time is 1.3mS standard.

I have changed the reset device and it is now 180mS and the system is performing correctly.

Re: rouge memory changes

bigmac — Wed, 17 Jan 2007 11:29:07 GMT

Hello,

By altering the PRM file, have you already tried varying the position of the global variables in RAM? Have you already checked that no other global variable is also affected?

Something you might try -

At the position in your code where the global variables are defined, try swapping the position of cLiveProgLoadStatus with an adjacent variable, to alter position in memory. Then see if the problem remains with cLiveProgLoadStatus, or shifts elsewhere. Alternatively, you could define new global variables, with one preceeding cLiveProgLoadStatus definition, and another one following it. Use the debugger to check the actual address of the global variables, both before and after the change.

This won't solve your problem, but may give additional insight into the problem.

Regards,

Mac

Re: rouge memory changes

bigmac — Wed, 17 Jan 2007 11:48:18 GMT

NZ-Design wrote:
For those that would like to know

The problem arises from the time between powering up and reset going high is to short.

The development board time is 1.3mS standard.

I have changed the reset device and it is now 180mS and the system is performing correctly.

Hello again,

The likely cause is that the ramp-up slope for the power supply is too slow for the MCU - the minimum rate is specified. I assume you are applying power to the board by turning on mains power - if you switch the DC output going to the board, the problem should disappear for the normal reset delay.

Regards,
Mac