Searching \ for '[PIC]: PCL & PCLATH' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'PCL & PCLATH'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: PCL & PCLATH'
2003\02\21@014944 by ards, Justin P

flavicon
face
Hello,

I am using MPLAB 6.12 and a 16f628.

I got bitten by the 256 byte boundary bug.  So I relocated my RETLW table to the last 256 bytes ie 1793 to 2048

When my Prog makes a call to 1793  PCL = 0 and PCLATH also equals 0.  If I execute the next ADDWF PCL,f  it jumps back to the start of the program.  If I manual set PCLATH to 7 in the SIM all goes as expected.

Why does PCLATH not change on the screen when it is another boundary. Is MPLAB going astray?
Justin

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2003\02\21@031036 by ards, Justin P

flavicon
face
Please ignore this question.

Sorry.

-----Original Message-----
From: Richards, Justin P Sent: Friday, 21 February 2003 2:48 PM
To: spam_OUTPICLISTTakeThisOuTspamMITVMA.MIT.EDU
Subject: [PIC]: PCL & PCLATH


Hello,

I am using MPLAB 6.12 and a 16f628.

I got bitten by the 256 byte boundary bug.  So I relocated my RETLW table to the last 256 bytes ie 1793 to 2048

When my Prog makes a call to 1793  PCL = 0 and PCLATH also equals 0.  If I execute the next ADDWF PCL,f  it jumps back to the start of the program.  If I manual set PCLATH to 7 in the SIM all goes as expected.

Why does PCLATH not change on the screen when it is another boundary. Is MPLAB going astray?
Justin

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2003\02\21@050812 by Wouter van Ooijen

face picon face
> When my Prog makes a call to 1793  PCL = 0 and PCLATH also
> equals 0.  If I execute the next ADDWF PCL,f  it jumps back
> to the start of the program.  If I manual set PCLATH to 7 in
> the SIM all goes as expected.
>
> Why does PCLATH not change on the screen when it is another
> boundary. Is MPLAB going astray?

I think you confuse PCLATH with the upper bits of the program counter.
PCLATH will change *only* when you make it do so, not by program
execution crossing a 256-instruction border.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2003\02\21@082255 by Olin Lathrop

face picon face
> So I relocated my RETLW table to the last 256 bytes ie
> 1793 to 2048

That could be part of the problem.  It should be 1792 - 2047, which you
might have caught yourself if you used hexadecimal notation.  Your range
was 701h - 800h, whereas the correct range is 700h - 7FFh.

> When my Prog makes a call to 1793  PCL = 0 and PCLATH
> also equals 0.

This makes no sense.  You shouldn't be calling the table entries directly
since there is no way to index into the table then.  Also, PCL doesn't
matter on a CALL, and PCLATH doesn't matter on a call in a 16F628 because
this part only has one code page.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2003\02\21@090844 by o-8859-1?Q?Tony_K=FCbek?=
flavicon
face
Hi,

Richards Justin wrote:
>I am using MPLAB 6.12 and a 16f628.
>
>I got bitten by the 256 byte boundary bug.  So I relocated my RETLW
table to the last 256 bytes ie
>1793 to 2048
>
>When my Prog makes a call to 1793  PCL = 0 and PCLATH also equals 0.
If I execute the next ADDWF PCL,f  it jumps
>back to the start of the program.  If I manual set PCLATH to 7 in the
SIM all goes as expected.
>
>Why does PCLATH not change on the screen when it is another boundary.
Is MPLAB going astray?
First this is not a bug but a feature :), the PCLATH is not the 'real'
high portion of the program counter it only serves as an buffer that enables writing the 'real' upper adress
counter. Therefore if one is to manipulate the program counter manually you always must make sure
that the content of PCLATH are setup *before*
you write the PCL. Beacuse as soon as you write to the PCL  whatever
content is in the PCLATH
will be transfered to the PCH which is the 'real' upper program counter.
Also beware that you might
need to 'reset' the PCLATH after manipulation.

/Tony

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2003\02\26@184020 by ards, Justin P

flavicon
face
Thank you all very much.

I have struggled with this and tried to figure it out.  I just could not work out why when far jumps were made PCLATH just would not change immediately.

I read the manual regarding PCLATH and found it difficult to understand and relied on the behaviour of the registers using the simulator.  Confused me even more.  I tend to do a lot of that i.e. If I cant understand the manual I put the simulator thru its paces and see how it behaves.

I did not want to bother the list as I was sure it had been dealt with countless times.

Thanks for your time.  It is so clear now.

Regards Justin

In future I will RTFM, RTFM, RTFM ...

{Original Message removed}

More... (looser matching)
- Last day of these posts
- In 2003 , 2004 only
- Today
- New search...