Subject:
RE: pic18f4455 - ACCESS flag on the device working or not?
From:
Sivaram Gowkanapalli ####@####.####
Date:
3 Jun 2011 14:27:16 -0000
Message-Id: <SNT125-W1254E90FFB6353451E5630D27F0@phx.gbl>
Hello Marko,
Thanks. Your observation was spot-on. Enabling the extended instruction set breaks instructions using the access ram opcode.
Thanks again,Siva
> Date: Fri, 3 Jun 2011 11:20:10 +0300
> Subject: Re: pic18f4455 - ACCESS flag on the device working or not?
> From: ####@####.####
> To: ####@####.####
>
> When in extended mode, the memory access with access bit 0 is made
> based on FSR2. gpsim may have FSR2 initially at value 0 so it works
> much the same as standard non-extended mode.
>
> The config bit XINST does not do much else but define the bit that
> goes to the .hex file and causes the processor to run in extended
> mode. The assembler parses and compiles instructions for extended mode
> based on the --extended command line flag or LIST PE directive.
>
> Marko
>
> On Fri, Jun 3, 2011 at 9:42 AM, Sivaram Gowkanapalli
> ####@####.#### wrote:
> >
> > Hello,
> >
> > Please excuse the earlier email. The formatting ended up being a mess.
> >
> > This piece of code is not working on the pic18F4455. It has been
> > compiled withXINST = ON and with the --extended flag of gpasm.
> >
> > The expected result of _temp is 0xf+1+1+1, but it stays at 0xff, the
> > value from the instruction at address 180. As you can see that _temp
> > has anaddress of 0x3 and it should not be affected by the BSR.
> >
> > I am not sure if this has to do with the extended instruction set or if
> > it could be something else. It seems to be something simple that I am
> > missing as the below case is toostraightforward to be a bug.
> >
> > Is this how the instructions would be, with XINST= ON?
> >
> > It works perfectly fine on gpsim. I see the value of _temp = 0xf+1+1+1.
> > It is only on the device that it is not working.
> >
> >
> > from the .lst file:
> >
> > 00017e 0eff movlw 0xff movlw 0xff
> > 000180 cfe8 movff 0xfe8, 0x3 movff WREG,_temp
> > 000182 f003
> > 000184 0e0f movlw 0xf movlw 0x0f
> > 000186 6e03 movwf 0x3, 0 movwf _temp,ACCESS
> > 000188 2a03 incf 0x3, 0x1, 0 incf _temp,F,ACCESS
> > 00018a 2a03 incf 0x3, 0x1, 0 incf _temp,F,ACCESS
> > 00018c 2a03 incf 0x3, 0x1, 0 incf _temp,F,ACCESS
> >
> >
> > from the hex file which was downloaded from the pic (to confirm that
> > the hexfile was written to the pic correctly,
> > fromgpdasm -y -p p18f4455 from-pic.hex | less) :
> >
> > 000180: cfe8 movff 0xfe8, 0x3
> > 000182: f003
> > 000184: 0e0f movlw 0xf
> > 000186: 6e03 movwf 0x3, 0
> > 000188: 2a03 incf 0x3, 0x1, 0
> > 00018a: 2a03 incf 0x3, 0x1, 0
> > 00018c: 2a03 incf 0x3, 0x1, 0
> >
> > output from gpsim when stepping through the code:
> >
> > 0x0000000000002FE9 p18f4455 0x017E 0x0EFF movlw 0xff
> > Wrote: 0x00FF to W(0x0FE8) was 0x0008
> > 0x0000000000002FEB p18f4455 0x0180 0xCFE8 movff W,REG003
> > Read: 0x00FF from W(0x0FE8)
> > Wrote: 0x00FF to REG003(0x0003) was 0x0000
> > 0x0000000000002FEC p18f4455 0x0184 0x0E0F movlw 0x0f
> > Wrote: 0x000F to W(0x0FE8) was 0x00FF
> > 0x0000000000002FED p18f4455 0x0186 0x6E03 movwf REG003
> > Read: 0x000F from W(0x0FE8)
> > Wrote: 0x000F to REG003(0x0003) was 0x00FF
> > 0x0000000000002FEE p18f4455 0x0188 0x2A03 incf REG003,f,0
> > Read: 0x000F from REG003(0x0003)
> > Wrote: 0x0010 to REG003(0x0003) was 0x000F
> > Wrote: 0x0002 to status(0x0FD8) was 0x0004
> > 0x0000000000002FEF p18f4455 0x018A 0x2A03 incf REG003,f,0
> > Read: 0x0010 from REG003(0x0003)
> > Wrote: 0x0011 to REG003(0x0003) was 0x0010
> > Wrote: 0x0000 to status(0x0FD8) was 0x0002
> > 0x0000000000002FF0 p18f4455 0x018C 0x2A03 incf REG003,f,0
> > Read: 0x0011 from REG003(0x0003)
> > Wrote: 0x0012 to REG003(0x0003) was 0x0011
> > Wrote: 0x0000 to status(0x0FD8) was 0x0000
> >
> > Any thoughts, please?
> > Thanks
> > Siva
> >
> >
> >
> >
> >> From: ####@####.####
> >> To: ####@####.####
> >> Subject: pic18f4455 - ACCESS flag on the device working or not?
> >> Date: Fri, 3 Jun 2011 02:28:11 -0400
> >>
> >>
> >> Hello,
> >> This piece of code is not working on the pic18F4455. It has been compiled withXINST = ON and with the --extended flag of gpasm.
> >> The expected result of _temp is 0xf+1+1+1, but it stays at 0xff, the valuefrom the instruction at address 180. As you can see that _temp has anaddress of 0x3 and it should not be affected by the BSR. I am not sure if thishas to do with the extended instruction set or if it could be something else.It seems to be something simple that I am missing as the below case is toostraightforward to be a bug. Is this how the instructions would be, with XINST= ON?
> >> It works perfectly fine on gpsim. I see the value of _temp = 0xf+1+1+1. It is only on the device that it is not working.
> >> from the .lst file:
> >> 00017e 0eff movlw 0xff movlw 0xff000180 cfe8 movff 0xfe8, 0x3 movff WREG,_temp000182 f003000184 0e0f movlw 0xf movlw 0x0f000186 6e03 movwf 0x3, 0 movwf _temp,ACCESS000188 2a03 incf 0x3, 0x1, 0 incf _temp,F,ACCESS00018a 2a03 incf 0x3, 0x1, 0 incf _temp,F,ACCESS00018c 2a03 incf 0x3, 0x1, 0 incf _temp,F,ACCESS
> >> from the hex file which was downloaded from the pic (to confirm that the hexfile was written to the pic correctly, fromgpdasm -y -p p18f4455 from-pic.hex | less) :
> >> 000180: cfe8 movff 0xfe8, 0x3000182: f003000184: 0e0f movlw 0xf000186: 6e03 movwf 0x3, 0000188: 2a03 incf 0x3, 0x1, 000018a: 2a03 incf 0x3, 0x1, 000018c: 2a03 incf 0x3, 0x1, 0
> >> output from gpsim when stepping through the code:
> >> 0x0000000000002FE9 p18f4455 0x017E 0x0EFF movlw 0xff Wrote: 0x00FF to W(0x0FE8) was 0x00080x0000000000002FEB p18f4455 0x0180 0xCFE8 movff W,REG003 Read: 0x00FF from W(0x0FE8) Wrote: 0x00FF to REG003(0x0003) was 0x00000x0000000000002FEC p18f4455 0x0184 0x0E0F movlw 0x0f Wrote: 0x000F to W(0x0FE8) was 0x00FF0x0000000000002FED p18f4455 0x0186 0x6E03 movwf REG003 Read: 0x000F from W(0x0FE8) Wrote: 0x000F to REG003(0x0003) was 0x00FF0x0000000000002FEE p18f4455 0x0188 0x2A03 incf REG003,f,0 Read: 0x000F from REG003(0x0003) Wrote: 0x0010 to REG003(0x0003) was 0x000F Wrote: 0x0002 to status(0x0FD8) was 0x00040x0000000000002FEF p18f4455 0x018A 0x2A03 incf REG003,f,0 Read: 0x0010 from REG003(0x0003) Wrote: 0x0011 to REG003(0x0003) was 0x0010 Wrote: 0x0000 to status(0x0FD8) was 0x00020x0000000000002FF0 p18f4455 0x018C 0x2A03 incf REG003,f,0 Read: 0x0011 from REG003(0x0003) Wrote: 0x0012 to REG003(0x0003) was 0x0011 Wrote: 0x0000 to status(0x0FD8) was 0x0000
> >> Any thoughts, please?
> >> ThanksSiva
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
>
