Briefly, maximum number of vars?

[Jerson]

Chris,

I am not really sure, but, you seem to be on the right track thinking that PBP may need to be guided around the RAM banks.

I haven't worked on any project that uses a lot of RAM, so my comments may be totally invalid.


However, my understanding is - PBP sets the banks by looking at the starting address of a variable before accessing it. What this means, PBP knows where to find the first element of a multibyte array, but the moment the array wraps over to the next RAM page, PBP brings you back to the start of the existing/selected page.

A possible workaround would be to place large arrays in their own RAM page where they cannot wrap around without PBP knowing.

I wonder if this helps

[Darrel Taylor]

I would suspect Array overflows.

All arrays are zero based.
It's easy to forget that a 32 byte array only goes to 31.

PBP does not check "Bounds" for arrays.
And if you go past it, something else gets corrupted.

With 18F's, banks don't matter with BYTE arrays.
WORD/LONG array's are a little different.
<br>

[Chris Barron]

I would suspect Array overflows.

All arrays are zero based.
It's easy to forget that a 32 byte array only goes to 31.

PBP does not check "Bounds" for arrays.
And if you go past it, something else gets corrupted.

With 18F's, banks don't matter with BYTE arrays.
WORD/LONG array's are a little different.
<br>

Thanks Darrel.
Part of my faultfinding included checking for overflow, as well as increasing the size of my arrays, just to be sure.

The SDFS code variables include several WORD and LONG arrays. You have said that they are handled differently, can you suggest what might be going wrong, and a possible solution ? Would it be wise to force the location of such arrays ? How would that be best achieved ? Could I locate LONG and WORD arrays at the beginning of my code to ensure those variables begin at the start of a page ?

Is it important to also point out that none of these WORD and LONG arrays are ever used in my code at the moment. I commented out all code which used them, to successfully eliminate the program itself.

TIA
Chris

[Chris Barron]

Chris,


A possible workaround would be to place large arrays in their own RAM page where they cannot wrap around without PBP knowing.

I wonder if this helps

I guess it has something to do with my understanding of PBP as much as anything else, your description of the array pointer system ties in with my own thoughts.

Darrel can confirm that the only array types which might give cause for concern are WORD and LONG. The variables which I am pasting in contain a single LONG array of 8 elements. All other arrays being byte sized. I've just tried putting the LONG array at the start of the declaration section, but do you think it would be better to ORG it to somewhere ?

What pains me is that I took a piece of working code which I have been working on for months, imported some variables which are not duplicates and which are never implemented in my own code, and I end up with non-working code.

The shift to linear memory can't come soon enough !

Chris

[rmteo]

.... The shift to linear memory can't come soon enough !

Chris

Don't count on it happening any time soon. Right now the only Microchip products that have it (4Gb linear addressing space) is the PIC32 line.

[Darrel Taylor]

Darrel can confirm that the only array types which might give cause for concern are WORD and LONG. The variables which I am pasting in contain a single LONG array of 8 elements.

Well, they are handled a little different, but they are still no cause for concern.

The compiler simply makes sure that no single element of an array crosses a bank boundary. The array can span multiple banks, but LONGs or WORDs will always be on one side or the other, never split.

If you want to make sure that an array is completely inside a single bank ... specify the bank in the variable declaration.

MyArray VAR WORD[16] BANK3

This forces PBP to put the entire array in bank3 and will not allow it to cross a boundary.
However, I do not think that's your problem.

Can you at least post the interrupt routine.
That's the most likely place.
The second most likely is any ASM code (doesn't have to be the INT handler).
<br>

[Jerson]

Chris

Is it possible to let us have just "all" your variable declarations so that we can test it out?

I am suspecting that the compilers' symbol table is unable to cope with so many variables.

[Chris Barron]

Chris

Is it possible to let us have just "all" your variable declarations so that we can test it out?

I am suspecting that the compilers' symbol table is unable to cope with so many variables.

That is what I was alluding to.
If that is the case then one workaround may be to declare a large array, called 'MY_VARS' and then declare the existing program variables to be related to that one as aliases, because the number of aliases seems not to make a difference in the same way that the number of vars do.

[Bruce]

Chris,

Accessing your vars in your asm routine without knowing which bank they're in, or handling BSR, is most, if not all, of the problem I suspect.

If all of your vars will fit into 1 bank, just tell PBP to place them all in the same bank, then set BSR to this bank on entry to your int handler.

[Chris Barron]

Chris,

Accessing your vars in your asm routine without knowing which bank they're in, or handling BSR, is most, if not all, of the problem I suspect.

If all of your vars will fit into 1 bank, just tell PBP to place them all in the same bank, then set BSR to this bank on entry to your int handler.

Thanks Bruce. What i've assumed is that because all of my vars do fit into one bank if i put them at the start of the declarations they will be placed there. The problem with the extra vars is happening whether I place the extra vars before or after my own. it doesn't seem to matter where I put them the fault doesn't go away until I comment out enough of them to get the total number down. But I take your point about using the BSR in the interrupt. I think I have relied too much on PBP and overseen the fact that I still need to obey Microchip's laws !