RAM corruption (I don't think it's my fault!)

[markie]

Hi all,

I am using v4.057 and a PIC18F2520. At first all seemed well and everything worked fine, but as my project grew (a digitally controlled preamp, so growth was inevitable) seemingly random faults kept popping up. I would add some code, and other code would stop working or produce gibberish on the LCD, etc etc.

I have spend three days now trying to figure it out, and it seems that it is *not* my coding that's been at fault. I only use a couple of simple arrays so far, and have a primitive Fault() functions which stores a value in eeprom then calls a reset_cpu(). I use this to check for various array overflow conditions or other things which aren't supposed to happen. This function isn't getting called (though I have verified it works), so I have concluded that the problem isn't anything to do with my code overwriting the RAM and corrupting things.

Today I found out about the .lst and .sym stuff. As it happens I could get my program to near enough work, with just one piece of array data corrupted and everything else functioning fine, and to completely fail - simply by moving a single loop variable (k) declaration a few lines up in the program. Working = declare at beginning of main function, broken = declare just before the for loop!

I compared the .lst and .sym for the "working" code and the broken code. When declared at the top of the main function, I saw the variable in the .sym file. When declared just before the loop, the variable completely disappeared from the .sym file. I assume the compiler decided to locate it in some kind of temporary memory. This would actually explain the exact behaviour I was seeing!

The loop in question was the main loop for my primitive task system. It looked at each task and ran the appropriate function if it was scheduled. The broken compile was never exiting the for loop around the task array, and was only ever executing task 0, even though other tasks were being scheduled. I figure the loop variable being in some kind of temporary space made the variable keep being reset to 0 after calling the task execution function.


Here's the part of code that was failing. Where the "int k" is currently, it "works". If I move it to just before the for(), it dies.

[markie]

Aha!

With some more searching (I have been searching these forums for a few hours too), I came across this post:

http://www.ccsinfo.com/forum/viewtopic.php?t=32221&highlight=linker

I read the three links posted and rearranged my source files to do it the 'traditional' CCS way, rather than using the linker. It seems to keep it modular-ish, and I flashed this compile...... no more corruption on the text! I guess it must be the linker to blame.

I guess it has to recompile the lot each time, rather than just changed modules and relinking....... but at least it seems to be working now. I'm over the moon!

Thanks PCM! Should the problem reappear using this method I will post back, but I have a feeling it won't