Banking Pic 16F877

Hi all. I'm having a strange problem here with some debugging. Got an ide
that the problem is perhaps relatet to some sort of bank-switching. My
qustion is :

I'm in program bank ?.
Make a call to a routine in bank1.
In here i recieve an INT whitch takes me to some code in programbank 0. In
the INT i save PCLATH, then make several call's. When done, i restore
PCLATH, then retfie.
Now i'm back with the routine in bank 1, but after return it seemes like
sometimes i'm not returning to the bank from where the original call was
made (this could be any one).

The datasheet states that you need to set PCLATH only on the way OUT - not
on return? Is that also true after servicing a INT in a nother bank,
containing call's of it's own ?
If not - is it "wrong" to have "common routines" like switch-reading which
need to be called from different banks - out of bank 0? Or is there some
other way round this?

If there's a "simple" problem here, i would really like to know - before
spending even more time debugging .

Thanks Niels

NDS wrote:
> Hi all. I'm having a strange problem here with some debugging. Got an ide
> that the problem is perhaps relatet to some sort of bank-switching. My
> qustion is :
>
> I'm in program bank ?.
> Make a call to a routine in bank1.
> In here i recieve an INT whitch takes me to some code in programbank 0. In
> the INT i save PCLATH, then make several call's. When done, i restore
> PCLATH, then retfie.
> Now i'm back with the routine in bank 1, but after return it seemes like
> sometimes i'm not returning to the bank from where the original call was
> made (this could be any one).
>
> The datasheet states that you need to set PCLATH only on the way OUT - not
> on return? Is that also true after servicing a INT in a nother bank,
> containing call's of it's own ?
> If not - is it "wrong" to have "common routines" like switch-reading which
> need to be called from different banks - out of bank 0? Or is there some
> other way round this?
>
> If there's a "simple" problem here, i would really like to know - before
> spending even more time debugging .
>
> Thanks Niels
>
>
How are you making the call to the routine in bank 1? The PIC midrange
reference manual has the following:

call k where k is between 0 and 2047

It doesn't appear that you can call a routine in another bank unless you
manually twiddle with the bank select bits and save pclath yourself.

Hi Niels,

some common mistakes and errors are:

1. PCLATH != PCH
2. PCLATH will _only_ copyed to PCH on GOTO, CALL or a write operation
to PCL. So unnecessary writing to PCLATH can make confusion on other
3. Remember to the stack depth of the used PIC, i.e. nesting of your
code. Bear in mind that the interrupt also need 1 stack level.
4. Call statement to code that not ends with a return statement.
5. Jump to a subroutine.
6. Jump to an adress outside the current subroutine.


HTH
Michael

"Tom" wrote:
> It doesn't appear that you can call a routine in another bank unless you
> manually twiddle with the bank select bits and save pclath yourself.

Sorry, i explained myself too bad.
I shift the bank with a macro before call :

pbank1 macro
banksel PCLATH
bcf PCLATH, 4
bsf PCLATH, 3
endm

Like this:

pbank1
call routine
.......
.......
return
(set correct bank in STATUS right after the call is returned)

If no INT happens in the middle of routine ( i tried killing it) i return OK
no matter from where the call was made..
If INT, i _sometimes_ returns OK.
AND - it seemes like when it goes wrong it takes me someplace new every
time.

And - Michael - i'm not (as i see it) pushing the stack more than 8 adresses
even with INT.

Niels

Just found the bug. Just a few thousand lines above where i was looking for
it.

cblock 0x20
...
...
; cblock 0x70
status_temp
pclath_temp
w_temp
...

cblock 0xA0
...

Guess what line was accidently commented out.
This way, succesfull saving of PCLATH depended on the selected databank
before INT.

Niels

Glad to hear you figgered it out. The banking in PICs can be a real
P.I.T.A.



NDS wrote:
> Just found the bug. Just a few thousand lines above where i was looking for
> it.
>
> cblock 0x20
> ...
> ...
> ; cblock 0x70
> status_temp
> pclath_temp
> w_temp
> ...
>
> cblock 0xA0
> ...
>
> Guess what line was accidently commented out.
> This way, succesfull saving of PCLATH depended on the selected databank
> before INT.
>
> Niels
>
>