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

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
 		 	   		  

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
>  		 	   		  
 		 	   		  

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
>>
>

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: ####@####.####
>