Odd problem

[rackley]

Edit: Disregard, I think I know the reason for this.

Twice now with 4.0 and now 4.02 something has happened in my project or code or generated code that causes my compiled project to not output to the LCD. I don't know if it's outputting at all or if the timing is messed up, but there are no values on the LCD. I still get serial output initially but at some point before the LCD is written to the PIC locks up and becomes completely unresponsive in terms of input and output.

The last time this happened I had to roll back to code that was about 2 days old and reconstruct all my additions piece by piece. It took me a few hours but once everything was back in, it worked fine.

This is the second time now, so it doesn't seem to be a random conincidence. I'll try to use serial output to debug exactly where in the code it's dying, but last time it happened I commented out so much code that I went from 63% of my 18F452's ROM to 17% and it was still dying

[rackley]

Ha! Well the good news is the strategy of serial output debugging paid off bigtime. I didn't have to comment out a single line of code and I found the spot where the problem is pretty darn quick.

My main routine is a while loop. Specifically,

Code: Select all

Dim Run as Byte
Main:
  run = 1
  intcounter = 0
  Init()
  StartupSound()
  
  SerOutTextLF("Before while(run=1)")

   while(run = 1)
     SerOutTextLF("After while(run=1)")

     SerOutTextLF("ReadFuel() entry ")
     FuelLevel = ReadFuel()
     SerOutTextLF("ReadTemps() entry ")
     ReadTemps(VTempCurrent, CTempCurrent)

     SerOutTextLF("MainLogic() entry ")
     MainLogic()

     {more stuff}
   wend
end.

It runs this just fine:

Code: Select all

  run = 1
  intcounter = 0
  Init()
  StartupSound()
  
  SerOutTextLF("Before while(run=1)")

But the serial output immediately after the while loop begins never gets sent out. If I move run=1 to the line immediately before the while loop begins, it runs fine. So the value of run is being corrupted or changed somehow, but not by my code.

A serial output of the value of run shows:

Code: Select all

Before while(run=1)
Run =  84

More to come...

[rackley]

Update... now it's an 80! LOL...

[rackley]

I think it has something to do with the placement of the variable declaration. When the declaration is below my functions and above Main:, it can get corrupted. However, if I place it above my functions the corruption goes away. At least it did when the only change I made was to move it from above Main: to above all functions... we'll see if it stays that way.

[rackley]

Well that turned out to be a VERY temporary fix. Apparently the placement of the variable isn't a fix after all.

[rackley]

OK I think this all boiled down to a structure array. I had Dim'd it to hold 14 elements but then added at 15th. I overpopulated the structure array and I think that was causing the overflow and corrupting the other data. I fixed the Dim statement, hopefully that will prevent this from happening.

[jpc]

Hi rackley,

Good to see it is not the compiler after all . Probably it would be substantial work to have this checked by the compiler and maybe the index is generated at runtime only , anayway , great that you solved it ! In similar cases i like to study the exact ram-allocations , sometimes these already explain where the interaction ( overlap ) is to be found.