Do STCHECK,$HWCHECK,$FRAMECHECK,$SOFTCHECK work

njepsen · Joined: 13 Aug 2007 Posts: 469

I am chasing an issue where a global gets changed when it should not, and i have been chasing this for 2 days now.
The last time anyone posted on the various 4 tools (shown above) for checking stack was 8 years ago, and at that time it seemed to me that consistent results were not being seen between STcheck and the other 3 at that time.
I don't want to go down that rabbit hole right now.
I have run STCHECK in several places and only ever got 0 as a result. Ive set the stack to the maximum space allowed but I still have one particular long variable that gets corrupted. Because the code is 8000 lines long its not practical to post the relevant code other than to say that the long is only set at one place in the entire code, and is corrupted somewhere else when it should not be.

JC · Joined: 15 Dec 2007 Posts: 586 Location: Cleveland, OH

Very frustrating, I'm sure.

While it could be a stack issue overwriting the stack, other problems could cause this, also.

For a test, try disabling interrupts when you create or process that variable, then re-enable them.
It is always possible that the variable is getting trashed by an ISR.

Is the variable used within an ISR?
If so, recall that not all registers are saved, etc., when calling an ISR.
That can cause some odd bugs that are difficult to track down.

I don't know how the compiler orders the variables in memory.
But, for kicks, one could try to make the compiler place the variable causing a problem in a different location in memory.
Then, perhaps, that variable would survive correctly, and a different variable would be corrupted / over-written.
That would help to verify that the variable was being over-written by an adjacent variable / array in the stack line up.
You could Dim the variable as the first one in the list, perhaps, or DIM / add another variable of the same type.
Then do something with that variable so that it isn't optimized out of the memory.

Are all of your arrays 0 based or 1 based, and are you absolutely sure you are not trying to write to an indexed array location that isn't Dim'd, i.e. that does not exist?
That, also, can be a difficult bug to find.

Finally, can you, at least for now, replace some (lengthy) subroutines with canned data and REM the actual code.
This is to significantly shorten the program, (although it won't work quite right...).
The goal is to see if you can use some canned data, and make the program still run, and see if the variable now survives.
Then add back in the modified routines one at a time.
This both lengthens the program, and perhaps points to the subroutine that causes the problem.

Does the program run correctly on an older version of the compiler, or has it never run correctly?

Have a spare LED on the board?
Depending upon the overall structure of your program you might be able to check the specific variable's value at multiple points within your program, (i.e. at ten locations spread through your Main Loop), and at the entry or exit of some key ISRs.
The goal is to see if there is a particular place within the code that always trashes the variable, and does so reproducibly.
That helps to track down the specific routine or line of code that causes the problem.

If the variable gets trashed at totally random / different times every time the program is executed then it is harder to identify, as it might well be dependent upon specific ISR's firing and specific data processing...

JC

MWS · Joined: 22 Aug 2009 Posts: 2262

Evert :-) · Joined: 18 Feb 2005 Posts: 2156

njepsen · Joined: 13 Aug 2007 Posts: 469

Thanks Fellas for coming back to me on this, and thanks for your efforts especially JC.
I HAVE FOUND THE PROBLEM

It was your comment mws that variables are stored in the order in which they are declared which was the clincher, and the other clue was that the variable ( which is a long) was not trashed, but always only had its last 4 digits changed.
The problem was in my declarations, the previous variable was a string which was 3 bytes too short, and from time to time ( several minutes), it overflowed into my long.
DUH !!

Simple problem, hard to find, silly mistake.

Thanks guys.

AdrianJ · Joined: 16 Jan 2006 Posts: 2483 Location: Queensland

Great you solved it !

One thing I used to do to trace this sort of corruption was to rearrange the order variables are defined. Then see whether the corruption happens on the same or a different variable. If its still the same variable, its most likely an ISR or stack problem. If its a different variable, its more likely a DIM overflow error, as you found.

Its probably good practice to put all the strings after all numeric variables in the DIM list, they are the ones most likely to cause this sort of problem.

njepsen · Joined: 13 Aug 2007 Posts: 469

Hi Adrian,
yes you are probably right. All my var are in alphabetical order so i can easily find them.
Once bitten, twice shy.