RE: pic18f4455 - ACCESS flag on the device working or not?

--_39092b6f-6f90-4c10-b150-60b7813687b0_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Hello Marko=2C
Thanks. Your observation was spot-on. Enabling the extended instruction set=
 breaks instructions using the access ram opcode.
Thanks again=2CSiva

> Date: Fri=2C 3 Jun 2011 11:20:10 +0300
> Subject: Re: pic18f4455 - ACCESS flag on the device working or not?
> From: [email protected]
> To: [email protected]
>=20
> When in extended mode=2C 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.
>=20
> 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.
>=20
> Marko
>=20
> On Fri=2C Jun 3=2C 2011 at 9:42 AM=2C Sivaram Gowkanapalli
> <[email protected]> wrote:
> >
> > Hello=2C
> >
> > 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 =3D ON and with the --extended flag of gpasm.
> >
> > The expected result of _temp is 0xf+1+1+1=2C but it stays at 0xff=2C th=
e
> > 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=2C with XINST=3D ON?
> >
> > It works perfectly fine on gpsim. I see the value of _temp =3D 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=2C 0x3            movff WREG=2C_temp
> > 000182   f003
> > 000184   0e0f     movlw    0xf                   movlw 0x0f
> > 000186   6e03     movwf    0x3=2C 0                movwf _temp=2CACCESS
> > 000188   2a03     incf    0x3=2C 0x1=2C 0            incf _temp=2CF=2CA=
CCESS
> > 00018a   2a03     incf    0x3=2C 0x1=2C 0            incf _temp=2CF=2CA=
CCESS
> > 00018c   2a03     incf    0x3=2C 0x1=2C 0            incf _temp=2CF=2CA=
CCESS
> >
> >
> > from the hex file which was downloaded from the pic (to confirm that
> > the hexfile was written to the pic correctly=2C
> > fromgpdasm -y -p p18f4455 from-pic.hex | less) :
> >
> > 000180:  cfe8  movff    0xfe8=2C 0x3
> > 000182:  f003
> > 000184:  0e0f  movlw    0xf
> > 000186:  6e03  movwf    0x3=2C 0
> > 000188:  2a03  incf     0x3=2C 0x1=2C 0
> > 00018a:  2a03  incf     0x3=2C 0x1=2C 0
> > 00018c:  2a03  incf     0x3=2C 0x1=2C 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=2CREG003
> >   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=2Cf=2C0
> >   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=2Cf=2C0
> >   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=2Cf=2C0
> >   Read: 0x0011 from REG003(0x0003)
> >   Wrote: 0x0012 to REG003(0x0003) was 0x0011
> >   Wrote: 0x0000 to status(0x0FD8) was 0x0000
> >
> > Any thoughts=2C please?
> > Thanks
> > Siva
> >
> >
> >
> >
> >> From: [email protected]
> >> To: [email protected]
> >> Subject: pic18f4455 - ACCESS flag on the device working or not?
> >> Date: Fri=2C 3 Jun 2011 02:28:11 -0400
> >>
> >>
> >> Hello=2C
> >> This piece of code is not working on the pic18F4455. It has been compi=
led withXINST =3D ON and with the --extended flag of gpasm.
> >> The expected result of _temp is 0xf+1+1+1=2C but it stays at 0xff=2C t=
he 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 i=
f thishas to do with the extended instruction set or if it could be somethi=
ng 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=
=2C with XINST=3D ON?
> >> It works perfectly fine on gpsim. I see the value of _temp =3D 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=2C 0x3            movff WREG=2C_temp000182   f0030001=
84   0e0f     movlw      0xf                   movlw 0x0f000186   6e03     =
movwf 0x3=2C 0                movwf _temp=2CACCESS000188   2a03     incf  0=
x3=2C 0x1=2C 0            incf _temp=2CF=2CACCESS00018a   2a03     incf    =
    0x3=2C 0x1=2C 0            incf _temp=2CF=2CACCESS00018c   2a03     inc=
f        0x3=2C 0x1=2C 0            incf _temp=2CF=2CACCESS
> >> from the hex file which was downloaded from the pic (to confirm that t=
he hexfile was written to the pic correctly=2C fromgpdasm -y -p p18f4455 fr=
om-pic.hex | less) :
> >> 000180:  cfe8  movff    0xfe8=2C 0x3000182:  f003000184:  0e0f  movlw =
   0xf000186:  6e03  movwf    0x3=2C 0000188:  2a03  incf     0x3=2C 0x1=2C=
 000018a:  2a03  incf     0x3=2C 0x1=2C 000018c:  2a03  incf     0x3=2C 0x1=
=2C 0
> >> output from gpsim when stepping through the code:
> >> 0x0000000000002FE9 p18f4455 0x017E 0x0EFF movlw       0xff  Wrote: 0x0=
0FF to W(0x0FE8) was 0x00080x0000000000002FEB p18f4455 0x0180 0xCFE8 movff =
     W=2CREG003  Read: 0x00FF from W(0x0FE8)  Wrote: 0x00FF to REG003(0x000=
3) was 0x00000x0000000000002FEC p18f4455 0x0184 0x0E0F movlw        0x0f  W=
rote: 0x000F to W(0x0FE8) was 0x00FF0x0000000000002FED p18f4455 0x0186 0x6E=
03 movwf      REG003  Read: 0x000F from W(0x0FE8)  Wrote: 0x000F to REG003(=
0x0003) was 0x00FF0x0000000000002FEE p18f4455 0x0188 0x2A03 incf   REG003=
=2Cf=2C0  Read: 0x000F from REG003(0x0003)  Wrote: 0x0010 to REG003(0x0003)=
 was 0x000F  Wrote: 0x0002 to status(0x0FD8) was 0x00040x0000000000002FEF p=
18f4455 0x018A 0x2A03 incf      REG003=2Cf=2C0  Read: 0x0010 from REG003(0x=
0003)  Wrote: 0x0011 to REG003(0x0003) was 0x0010  Wrote: 0x0000 to status(=
0x0FD8) was 0x00020x0000000000002FF0 p18f4455 0x018C 0x2A03 incf      REG00=
3=2Cf=2C0  Read: 0x0011 from REG003(0x0003)  Wrote: 0x0012 to REG003(0x0003=
) was 0x0011  Wrote: 0x0000 to status(0x0FD8) was 0x0000
> >> Any thoughts=2C please?
> >> ThanksSiva
> >>
> >
>=20
> ---------------------------------------------------------------------
> To unsubscribe=2C e-mail: [email protected]
> For additional commands=2C e-mail: [email protected]
>=20
 		 	   		  =

--_39092b6f-6f90-4c10-b150-60b7813687b0_--