Post by thread:[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

Please ignore this question. Sorry. -----Original Message----- From: Richards, Justin P Sent: Friday, 21 February 2003 2:48 PM To: spam_OUTPICLISTTakeThisOuTMITVMA.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

> 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

> 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

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

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}