Declaring variables in wrong order breaks it (Solved!)

[Scottzilla]

I'm writing code for a project, and I've got two hardware prototypes. The code works great in one, but when I program it into the other it acts funny (continuously restarts, etc.). The weird part is that if I go back into the C and randomly change the order in which I declare my variables, I can get it to work on both versions. The "problem" unit isn't always the same one, either, so I don't think it's a bad chip.

The only difference between the two units is that one is SMT and one is through-hole.

Has anyone ever run into an issue where variable declaration order causes things not to run?

Chip: PIC18F4553 (both rev. 7)
Programmer: PICkit3
IDE: MPLAB X
Compiler version: 4.130

I can't really boil the problem down into simple sample code unfortunately.

[PCM programmer]

Look for a pointer that's writing past the end of an array. Or look for a
non-array variable which is accessed with a pointer, which is writing
beyond the size limit of the variable.

When you change the declaration order, you change the variable that
is corrupted. If the variable is a loop counter, or is a flag that controls
an if() statement, you will see weird program operation.

[Ttelmah]

Some 'extra' possibilities:

A simple text array, used for a string, where the original programmer has forgotten that a string always needs one more character of storage, than it's 'length' (basically the same as the pointer suggestion from PCM_programmer, but perhaps less obvious).
Another slightly less 'obvious' problem is that changing the order may also change the speed with which variables can be accessed. If something is very timing critical, this may become significant.
If you have access to a slightly older compiler, it might also be worth 'switching back' (around the mid 4.12x if available). A few of the latest versions seem to give incorrect results with some arrays that cross page boundaries, 're-introducing' a problem here, that existed on much older compilers...

Best Wishes

[Scottzilla]

Thanks for the ideas. I'll go see what I can figure out.

[Scottzilla]

Just wanted to provide an update just in case anybody else experiences this weirdness.

Rearranging memory declarations (but not what was declared) and getting different results indicated it was a memory problem. Changing the length of the code (but not the function) and getting different results indicated it was a code problem. It didn't seem like both theories would be correct, so I just combined all the individual weird things the chip was doing into one symptom, "acts crazy".

It acted crazy in the PCB version, but not the hand-wired version. I verified that they were both electrically identical. Eventually I started hooking the two boards together, replacing sections of the PCB version one-by-one with the corresponding sections on the hand-wired version. Finally I found the answer.

I needed to run fatter power traces to the PIC.

The meter/scope didn't see any significant power drops originally and I added plenty of caps with no change, so I didn't think that would be the problem. Turns out it was.

So simple now that I know what it is.

Anyway, I hope this helps somebody someday.

[temtronic]

Happy you you found the problem and a solution!
In the good old days, I'd run 50thou traces for power as well as a perimeter ground 'guard ring' and copper was 2oz back then.
I've even soldered bare wirewrap wire or 22ga 'phone quad' to ensure solid reliable power on PCBs,especially those driving 'noisy' relays or valves.
Today's 'gotta be ultramicro small' mentality can bite back, as you found out.
Cheers
jay