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

Marko Kohtala <[email protected]> Fri, 3 Jun 2011 11:20:10 +0300
Newsgroups gmane.comp.hardware.microcontrollers.gnupic
Message-ID <[email protected]>
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
<[email protected]> 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 =3D 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=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 =A0 0eff =A0 =A0 movlw =A0 =A00xff =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0movlw 0xff
> 000180 =A0 cfe8 =A0 =A0 movff =A0 =A00xfe8, 0x3 =A0 =A0 =A0 =A0 =A0 =A0mo=
vff WREG,_temp
> 000182 =A0 f003
> 000184 =A0 0e0f =A0 =A0 movlw =A0 =A00xf =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 movlw 0x0f
> 000186 =A0 6e03 =A0 =A0 movwf =A0 =A00x3, 0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0movwf _temp,ACCESS
> 000188 =A0 2a03 =A0 =A0 incf =A0 =A00x3, 0x1, 0 =A0 =A0 =A0 =A0 =A0 =A0in=
cf _temp,F,ACCESS
> 00018a =A0 2a03 =A0 =A0 incf =A0 =A00x3, 0x1, 0 =A0 =A0 =A0 =A0 =A0 =A0in=
cf _temp,F,ACCESS
> 00018c =A0 2a03 =A0 =A0 incf =A0 =A00x3, 0x1, 0 =A0 =A0 =A0 =A0 =A0 =A0in=
cf _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: =A0cfe8 =A0movff =A0 =A00xfe8, 0x3
> 000182: =A0f003
> 000184: =A00e0f =A0movlw =A0 =A00xf
> 000186: =A06e03 =A0movwf =A0 =A00x3, 0
> 000188: =A02a03 =A0incf =A0 =A0 0x3, 0x1, 0
> 00018a: =A02a03 =A0incf =A0 =A0 0x3, 0x1, 0
> 00018c: =A02a03 =A0incf =A0 =A0 0x3, 0x1, 0
>
> output from gpsim when stepping through the code:
>
> 0x0000000000002FE9 p18f4455 0x017E 0x0EFF movlw 0xff
> =A0 Wrote: 0x00FF to W(0x0FE8) was 0x0008
> 0x0000000000002FEB p18f4455 0x0180 0xCFE8 movff W,REG003
> =A0 Read: 0x00FF from W(0x0FE8)
> =A0 Wrote: 0x00FF to REG003(0x0003) was 0x0000
> 0x0000000000002FEC p18f4455 0x0184 0x0E0F movlw 0x0f
> =A0 Wrote: 0x000F to W(0x0FE8) was 0x00FF
> 0x0000000000002FED p18f4455 0x0186 0x6E03 movwf REG003
> =A0 Read: 0x000F from W(0x0FE8)
> =A0 Wrote: 0x000F to REG003(0x0003) was 0x00FF
> 0x0000000000002FEE p18f4455 0x0188 0x2A03 incf REG003,f,0
> =A0 Read: 0x000F from REG003(0x0003)
> =A0 Wrote: 0x0010 to REG003(0x0003) was 0x000F
> =A0 Wrote: 0x0002 to status(0x0FD8) was 0x0004
> 0x0000000000002FEF p18f4455 0x018A 0x2A03 incf REG003,f,0
> =A0 Read: 0x0010 from REG003(0x0003)
> =A0 Wrote: 0x0011 to REG003(0x0003) was 0x0010
> =A0 Wrote: 0x0000 to status(0x0FD8) was 0x0002
> 0x0000000000002FF0 p18f4455 0x018C 0x2A03 incf REG003,f,0
> =A0 Read: 0x0011 from REG003(0x0003)
> =A0 Wrote: 0x0012 to REG003(0x0003) was 0x0011
> =A0 Wrote: 0x0000 to status(0x0FD8) was 0x0000
>
> Any thoughts, please?
> Thanks
> Siva
>
>
>
>
>> From: [email protected]
>> To: [email protected]
>> 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 compile=
d withXINST =3D ON and with the --extended flag of gpasm.
>> The expected result of _temp is 0xf+1+1+1, but it stays at 0xff, the val=
uefrom the instruction at address 180. =A0As you can see that _temp has ana=
ddress of 0x3 and it should not be affected by the BSR. I am not sure if th=
ishas to do with the extended instruction set or if it could be something e=
lse.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=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 =A0 0eff =A0 =A0 movlw =A0 =A0 =A0 0xff =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0movlw 0xff000180 =A0 cfe8 =A0 =A0 movff 0xfe8, 0x3 =A0 =A0 =A0 =
=A0 =A0 =A0movff WREG,_temp000182 =A0 f003000184 =A0 0e0f =A0 =A0 movlw =A0=
 =A0 =A00xf =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 movlw 0x0f000186 =A0 6e03 =
=A0 =A0 movwf 0x3, 0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0movwf _temp,ACCESS00018=
8 =A0 2a03 =A0 =A0 incf =A00x3, 0x1, 0 =A0 =A0 =A0 =A0 =A0 =A0incf _temp,F,=
ACCESS00018a =A0 2a03 =A0 =A0 incf =A0 =A0 =A0 =A00x3, 0x1, 0 =A0 =A0 =A0 =
=A0 =A0 =A0incf _temp,F,ACCESS00018c =A0 2a03 =A0 =A0 incf =A0 =A0 =A0 =A00=
x3, 0x1, 0 =A0 =A0 =A0 =A0 =A0 =A0incf _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-p=
ic.hex | less) :
>> 000180: =A0cfe8 =A0movff =A0 =A00xfe8, 0x3000182: =A0f003000184: =A00e0f=
 =A0movlw =A0 =A00xf000186: =A06e03 =A0movwf =A0 =A00x3, 0000188: =A02a03 =
=A0incf =A0 =A0 0x3, 0x1, 000018a: =A02a03 =A0incf =A0 =A0 0x3, 0x1, 000018=
c: =A02a03 =A0incf =A0 =A0 0x3, 0x1, 0
>> output from gpsim when stepping through the code:
>> 0x0000000000002FE9 p18f4455 0x017E 0x0EFF movlw =A0 =A0 =A0 0xff =A0Wrot=
e: 0x00FF to W(0x0FE8) was 0x00080x0000000000002FEB p18f4455 0x0180 0xCFE8 =
movff =A0 =A0 =A0W,REG003 =A0Read: 0x00FF from W(0x0FE8) =A0Wrote: 0x00FF t=
o REG003(0x0003) was 0x00000x0000000000002FEC p18f4455 0x0184 0x0E0F movlw =
=A0 =A0 =A0 =A00x0f =A0Wrote: 0x000F to W(0x0FE8) was 0x00FF0x0000000000002=
FED p18f4455 0x0186 0x6E03 movwf =A0 =A0 =A0REG003 =A0Read: 0x000F from W(0=
x0FE8) =A0Wrote: 0x000F to REG003(0x0003) was 0x00FF0x0000000000002FEE p18f=
4455 0x0188 0x2A03 incf =A0 REG003,f,0 =A0Read: 0x000F from REG003(0x0003) =
=A0Wrote: 0x0010 to REG003(0x0003) was 0x000F =A0Wrote: 0x0002 to status(0x=
0FD8) was 0x00040x0000000000002FEF p18f4455 0x018A 0x2A03 incf =A0 =A0 =A0R=
EG003,f,0 =A0Read: 0x0010 from REG003(0x0003) =A0Wrote: 0x0011 to REG003(0x=
0003) was 0x0010 =A0Wrote: 0x0000 to status(0x0FD8) was 0x00020x00000000000=
02FF0 p18f4455 0x018C 0x2A03 incf =A0 =A0 =A0REG003,f,0 =A0Read: 0x0011 fro=
m REG003(0x0003) =A0Wrote: 0x0012 to REG003(0x0003) was 0x0011 =A0Wrote: 0x=
0000 to status(0x0FD8) was 0x0000
>> Any thoughts, please?
>> ThanksSiva
>>
>