Banks related to memory problem?

Hello,

I have been having a bit of what I think is memory trouble with a refrigeration control algorithm I wrote for an PIC18F86K22.

The symptoms are this:
setup program variables (there are a lot)
refrigeration system powers up and begins to run
superheat stops being calculated after a random amount of time (hours) and SatT is zero or a garbage number.

The superheat is calculated using a lookup table that was defined using this:

SatT var word[61]

If a word is 2 bytes, then this should require 122 bytes of memory to store this array of values. In a PIC18, from what I read on the data sheet, there is 3,862 or 4k or something bytes available. Ah, but the banks! The PIC18 has 16 banks of 256 bytes each.
We know this is not the problem though because when I did this:

SatT var word[61] bank4

It works indefinitely without error. It looks like assigning a bank to this array means that it could not get overwritten or lost.
But now I have a new problem. Compressor RPM started reading zero. There are three variables that go into calculating RPMActual:

SecAvgCount var word bank1
RPMSum var long bank1
RPM var long

As I'm programming this remotely I could not test to see which variable was reading incorrectly, but my guess is that the problem was the unassigned variable RPM.

This should provide us with a hint as to what the problem is. Only one variable is getting lost at a time, and if I apply a bank to the variable that is getting lost, it suddenly never gets lost, but then a new one gets lost. It seems as though I am getting close to the memory limit and it just loses a random variable that was not assigned to a bank. The problem with that is that I don't think I am close to the memory limit. Attached is a guess at how much memory my variables are taking up and what banks they are in. I didn't account for constants, but even so I'm not even at half of the supposed available memory. I could try applying banks to everything, but I thought PICBasic was supposed to do that automatically for everything you don't assign.

Would anyone else know why a variable might get lost because it was not assigned to a bank?

Attachment 7134

Secret code is tough to debug. My first GUESS is a stack overflow due to an un_returned sub routine somewhere. Sorry I do not unzip files from people strange to me.

the strange thing is ...

PBP states there is ( should be ? ) no problem with banks spanking with 18F devices ...

PBP manual $ 2.6.2 :

Quote:

---

Arrays may span banks on PIC18 devices.
On PIC18 devices, BYTE, WORD and LONG-sized arrays are only limited in length by the amount of available memory. The compiler will assure that arrays, as well as scalar variables, will fit in memory before successfully compiling.

---

so, one also could have a look to $ 7.2 " Code Pages and RAM Banks" if some assembler coding is included somewhere ...

Alain

I am now able to share the code for debugging, so attached are the five .pbp files that go into this whole software. OACIS-Main is the main program and includes the other 4 codes. R134a_R404a_K contains the conversion table that was having problems disappearing before, but now that it is in bank 4, it is having no trouble.

The new problem is the RPMAvg variable being lost (or one of the three variables that goes into calculating RPMAvg).

Another thing I noticed is that I have an array of 166 longs for my temperature conversion table. This makes for 664 bytes and is way bigger than the theoretical maximum bank size of 256. Could this be causing the problem of kicking other variables out of memory?

I am more likely to be one of your customers than someone who can give you any meaningful help,BUT
I sort of think the subroutines should endif before the return is called, so you do not overflow the stack. I might be wrong, but that is my thoughts.

Yup, always end your IFs before returning.

Robert

Thanks for your help.

I am assuming you are talking about the cases below where this problem occurs?

I found this problem to occur once in the OACIS-Main code:

if fButtonHold = 1 then 'If a button is being held, return to prevent too quick button responses.

if MenuPage = 8 and fHoldEnable = 1 then 'Or if we are on page 8 force the Valve on holds
if RightButton = 0 then 'but only if the code was put in to enable forcing.
pEvapEEV = 1
pBuzzer = 1
elseif LeftButton = 0 then
pEvapEEV = 0
pBuzzer = 1
endif
'Update the display to reflect forced valve
hserout2[$FE, $47, 20, 2, dec1(pEvapEEV)]
endif

return
endif



And in three locations in the PCB6_3 Setup.txt:

if(AOValue > 1023) then AOValue = 1023 ; limit value
if(AOValue < 0) then AOValue = 0
if(AOCh > 7) then return ; limit value
if(AOCh < 0) then return

EEWRITE:
if(EEAddress > 131071) then EEAddress = 131071 ; limit value

....

return


EEREAD:
if(EEAddress > 131071) then EEAddress = 131071 ; limit value

....

return

• 
  I'll see what I can do to fix these and then get back to you guys with whether or not that fixed the problem.
  
  Thanks again.
  
  
  
  
  
  
  
  
  

Does this work?

Code:

---

Routine:
If bla bla then goto exitroutine
Bla
Bla
Bla
Endif

Exitroutine:
Return

---

If you use this in multiple routines, then just suffix with a number so the labels are unique.
Robert