Searching \ for '[PIC] 18F1320 Flash write problem' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/memory.htm?key=flash
Search entire site for: '18F1320 Flash write problem'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] 18F1320 Flash write problem'
2016\10\08@191942 by IVP

face picon face
Hi all,

I'm having trouble getting a routine to write data where I think it
should. I've not done any Flash writing for a long time so probably
missing something pretty obvious. I've checked the d/s and had a
look around for examples and can't spot anything

The routine receives a packet of 48 bytes and writes it to an address
defined by the value of a two-digit LED display. For example, if the
display is showing 09, then the 48 bytes should be written to the block
starting at (9*64) + 0x1800, where 0x1800 is the base address

What I'm getting though is a write only when display = 00 and only
to the block address in the set-up declaration, eg t_data = 0x1800

If I change t_data to 0x1840, it will write there. And explicitly setting
TBLPTR in the code doesn't make a difference. The blk_add routine
returns the correct value for TBLPTR, the code seems to ignore it

If 0x1840 is the intended target (dg = 1, t_data = 0x1800), the write
will happen only if I clear it with 0000 data statements in the program,
otherwise the locations will stay as FFFF. But that write does miss the
first byte. All 48 bytes are correct when dg=00

Below is the section of code

Can anyone see what's missing ? I'm sure there's a common cause for
what's happening

TIA

Joe

------------------

mov      macro   val,file
        movlw   val
        movwf   file
        endm

t_data = 0x1800

;multiply digits by 64 to find block, add t_data base
;
;eg
;digits = 23 in <temp1:temp0> = 05c0, + 1800 = 1dc0

;Erase block
;Write buffer48 to block

wr_block movff   buffer,postinc0 ;last byte received

;         movlw   .0              ;display value, manual test
;         movwf   dg01
;         movlw   .0
;         movwf   dg10

        call    blk_add         ;get block start address

;         clrf    tblptru         ;Flash block address, manual test
;         movlw   0x18
;         movwf   tblptrh
;         movlw   0x40
;         movwf   tblptrl

;Block command can resolve to 8 bytes
;Erase command can resolve to 64 bytes (x00,x40,x80,xc0 starts)

;Erase block

erase    bcf     eecon1,cfgs     ;erase block
        bsf     eecon1,eepgd
        bsf     eecon1,wren
        bsf     eecon1,free
        bcf     intcon,gie
        mov     0x55,eecon2
        mov     0xaa,eecon2
        bsf     eecon1,wr
        nop
        tblrd*-

;write RAM to Flash as 64-byte (8*8) block

        mov     .8,bitcnth      ;'8-bytes' counter
        lfsr    fsr1,buffer48   ;data to write

write    mov     .8,bitcntl      ;byte counter

copy8    movff   postinc1,tablat ;copy 8 bytes to write buffer
        tblwt*+
        decfsz  bitcntl         ;byte counter
        bra     copy8

        mov     0x55,eecon2
        mov     0xaa,eecon2
        bsf     eecon1,wr
        nop
        decfsz  bitcnth         ;8-byte counter
        bra     write
        bcf     eecon1,wren

        goto    wait            ;done

;================

;Get Flash address from dg10:dg01, tens:units, 00d-30d

blk_add  rlncf   dg10,w          ;combine dg10:dg01
        rlncf   wreg
        rlncf   wreg            ;(dg10 * 8) + (dg10 * 2)
        addwf   dg10,w
        addwf   dg10,w
        addwf   dg01,w          ;+ dg01
        movwf   temp1           ;temp1 = (dg10 * 10) + dg01
        clrf    temp0

        clrc                    ;* 64
        rrcf    temp1
        rrcf    temp0
        rrcf    temp1
        rrcf    temp0

        clrc                    ;add 0x1800 base address
        movlw   low(t_data)
        addwf   temp0
        movlw   high(t_data)
        addwfc  temp1

        clrf    tblptru         ;Flash block address
        movff   temp1,tblptrh
        movff   temp0,tblptrl

        return


-----
No virus found in this message.
Checked by AVG - http://www.avg.com
Version: 2016.0.7797 / Virus Database: 4656/13173 - Release Date: 10/08/16

-- http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
mailman.mit.edu/mailman/listinfo/piclist
.

2016\10\08@203955 by Christopher Head

flavicon
face
According to the datasheet (page 58), TBLWT uses TBLPTR<2:0> to decide which holding register to fill, and the long write initiated with 55/AA/WR uses TBLPTR<21:3> to decide which write block to write the holding registers into.

You start by loading the address of your first byte into TBLPTR, then you do eight TBLWT*+ instructions. As these are post-incrementing, the last such instruction should roll TBLPTR over an 8-byte boundary, leaving it pointing at the wrong block.
-- Christopher Head
-- http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
mailman.mit.edu/mailman/listinfo/piclist
.

2016\10\08@221928 by IVP

face picon face
part 1 1331 bytes content-type:text/plain; charset="iso-8859-1" (decoded quoted-printable)

Hi Chris,

thanks for the reply

I'm at odds with the d/s. I believe the example they give is missing
a tblrd*- after the erase. I already thought that for some reason and
others on the web have commented on it. Yet at least one post in
the MC forum includes the d/s example verbatim and says it works.

Compare my code with the d/s example. AFAIK it's identical, with
the addition of the tblrd*- (tblwt*- seems to work too)

Consider the results in the attached gif. buffer48 has test data in it,
from 0x17 to 0x46. There are two "successful" outcomes.

One is that the 1st byte of a group of 8 (eg 0x17) is written as the
8th, ie the group has been rotated. In the other, the bytes are in the
correct order but +8 bytes offset in the block

I've tried putting things in and taking things out but not found a
sequence or alteration which makes sense, right or wrong

And I still can't write to a block unless I include these data statements
in the code, 0000s which are written to the chip when programmed

org t_data

data 0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000
data 0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000
data 0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000
data 0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000

Joe

part 2 5939 bytes content-type:image/gif; name="1320_flash_writes.gif" (decode)


part 3 181 bytes content-type:text/plain; name="Certification"
(decoded base64)

-----
No virus found in this message.
Checked by AVG - http://www.avg.com
Version: 2016.0.7797 / Virus Database: 4656/13173 - Release Date: 10/08/16
part 4 197 bytes content-type:text/plain; name="ATT00001.txt"
(decoded base64)

--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
mailman.mit.edu/mailman/listinfo/piclist

2016\10\08@223611 by IVP

face picon face
PS, I should have said that at times my code is consistent with the
d/s example. I have tried swapping tblwt+* for tblwt*+ etc

Joe


-----
No virus found in this message.
Checked by AVG - http://www.avg.com
Version: 2016.0.7797 / Virus Database: 4656/13173 - Release Date: 10/08/16

-- http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
mailman.mit.edu/mailman/listinfo/piclist
.

2016\10\09@193125 by Christopher Head

flavicon
face

On October 8, 2016 7:18:57 PM PDT, IVP <spam_OUTjoecolquittTakeThisOuTspamclear.net.nz> wrote:
>I'm at odds with the d/s. I believe the example they give is missing
>a tblrd*- after the erase. I already thought that for some reason and
>others on the web have commented on it. Yet at least one post in
>the MC forum includes the d/s example verbatim and says it works.

I already thought that. The example code in the datasheet uses preincrement TBLWT+* if I remember correctly, which should yield an off by one error in which byte goes into which holding register in the absence of a TBLPTR decrement. I just chalked it up to the usual rule of not trusting datasheet sample code.

>
>Compare my code with the d/s example. AFAIK it's identical, with
>the addition of the tblrd*- (tblwt*- seems to work too)

I thought your code that you posted earlier used TBLWT*+, not +*? That was the basis of my comment. I also didn’t see a decrement before the write.

>Consider the results in the attached gif. buffer48 has test data in it,
>from 0x17 to 0x46. There are two "successful" outcomes.

>One is that the 1st byte of a group of 8 (eg 0x17) is written as the
>8th, ie the group has been rotated. In the other, the bytes are in the
>correct order but +8 bytes offset in the block
>
>I've tried putting things in and taking things out but not found a
>sequence or alteration which makes sense, right or wrong

The first of the three examples in your attachment looks perfect. What’s wrong with that example?

>And I still can't write to a block unless I include these data
>statements
>in the code, 0000s which are written to the chip when programmed

That part is very odd. I assume t_data is an equ or something similar which is defined earlier?
--
Christopher Head
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
mailman.mit.edu/mailman/listinfo/piclist

2016\10\09@200958 by IVP

face picon face

> The first of the three examples in your attachment looks perfect. What’s
> wrong with that example?

Note that the 17 would be pulled out as the 8th byte when it should be
the first written. ie in the RAM buffer the bytes are 17 18 19 1a 1b 1c
1d 1e 1f. In Flash they end up as 18 19 1a 1b 1c 1d 1e 1f 17. The data
block has been rotated 1 byte

>>And I still can't write to a block unless I include these data
>>statements in the code, 0000s which are written to the chip when
>>it's programmed
>
> That part is very odd. I assume t_data is an equ or something
> similar which is defined earlier?

Yes, t_data = 0x1800

I put a pin toggle around the erase routine and measure it at 2.4ms, so
it does appear that an erase happens, or at least the mechanism to do
an erase is performed

I had a look through errata and find a mention for LDVCON and
EEPROM. Tried the workaround in case it also applies to Flash but
no change. PSU and /mclr seem clean. I've got a few other 18F
types to try the routines on, it might just be this particular batch of
1320

Thanks

Joe



-----
No virus found in this message.
Checked by AVG - http://www.avg.com
Version: 2016.0.7797 / Virus Database: 4656/13179 - Release Date: 10/09/16

--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
mailman.mit.edu/mailman/listinfo/piclist

2016\10\10@011615 by IVP

face picon face
> not trusting datasheet sample code

I checked my drives for old projects and found one for an 18F452
which I now remember copies 6 pages of RAM to Flash. The erase
routine is within a loop to erase 24 blocks for writing 5FF of RAM

Comparing it with the 452 datasheet I see that back then I knew
to add a tblrd*- because the 452 d/s has it. The 1320 example is not
a complete copy/paste of examples in older datasheets or for some
other reason does not include the tblrd*-

The 452 code still works and is functionally identical to what doesn't
work in this 1320. I'm going to try a 14K22 or 2520 instead and if
that's OK give using the 1320 for this project a miss

Joe


-----
No virus found in this message.
Checked by AVG - http://www.avg.com
Version: 2016.0.7797 / Virus Database: 4656/13179 - Release Date: 10/09/16

-- http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
mailman.mit.edu/mailman/listinfo/piclist
.

2016\10\10@034439 by Christopher Head

flavicon
face
part 1 1309 bytes content-type:text/plain; charset="utf-8" (decoded base64)

On Mon, 10 Oct 2016 13:08:56 +1300
IVP <.....joecolquittKILLspamspam@spam@clear.net.nz> wrote:

> > The first of the three examples in your attachment looks perfect.
> > What’s wrong with that example?  
>
> Note that the 17 would be pulled out as the 8th byte when it should be
> the first written. ie in the RAM buffer the bytes are 17 18 19 1a 1b
> 1c 1d 1e 1f. In Flash they end up as 18 19 1a 1b 1c 1d 1e 1f 17. The
> data block has been rotated 1 byte

Oh, yes, sorry. I didn’t know what the intended data actually was; I
assumed it was meant to start with 18.

The third row in your image is described as, “tblrd*- omitted after
erase.” Does that mean in the other examples you are doing the tblrd*-
after the erase and *BEFORE* the tblwt*+s? Because that would produce
exactly the result that you see in the first row: the tblrd*- sets
TBLPTR<2:0> to 7, the first tblwt*+ writes 0x17 into holding register 7
and increments TBLPTR<2:0> to 0, the second tblwt*+ writes 0x18 into
holding register 0, and so on—one byte of rotation.

I thought you would do the tblrd*- after the tblwts and before the bsf
WR. If you want to do the tblrd*- between the erase and the tblwts
instead, then I think you want tblwt+* instead of tblwt*+.
--
Christopher Head

part 2 197 bytes content-type:text/plain; name="ATT00001.txt"
(decoded base64)

--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
mailman.mit.edu/mailman/listinfo/piclist

2016\10\10@040243 by Anthony Nixon

picon face
Have you tried simulating the code.

Sometimes the mistake you cannot see in the code pops up in a simulator.

It should be easy to fill the buffer with values from 0 to 63 and
write the buffer to verify that all the values appear where they are
supposed to.

Is the chip receiving and buffering the data properly. This can be
verified by reading the buffer back after writing.


cheers

Tony



On Sun, Oct 9, 2016 at 10:19 AM, IVP <joecolquittspamKILLspamclear.net.nz> wrote:
{Quote hidden}

-- http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
mailman.mit.edu/mailman/listinfo/piclist
.

2016\10\10@063010 by IVP

face picon face
Hi Tony,

> It should be easy to fill the buffer with values from 0 to 63 and
> write the buffer to verify that all the values appear where they are
> supposed to.

Yes. I've added a small routine to fill buffer48 with the consecutive
values 0x17 - 0x46, overwriting the received data

Something interesting happened. This evening, they are writing in the
correct order, as are the received bytes. This evening, without the
code being changed at all. Same PSU, programmer, everything

However, I still have that problem of the block not being written
to if any of the 64 bytes in the target block is not 00. I thought there
might have been a glimmer of hope. I have buffer48 at 0xd0 in RAM,
so to read 64 bytes would mean reading past the end of RAM. I
moved it down to 0xa0 and tried again, but no luck. I'll have to
look around the d/s for something. Maybe one of the EECON1
bits, like FREE, isn't working properly

> Is the chip receiving and buffering the data properly. This can be
> verified by reading the buffer back after writing.

The data is being sent from an F88. Initially I checked the analyser
trace for correct data, as at that time I was setting up the clock and
data line timings. The 48 are being sent in order, starting with 0x17.
The receive routine is a straight 0-47 counter using fsr and postinc,
no provision for it to loop back and swap byte order

Joe


-----
No virus found in this message.
Checked by AVG - http://www.avg.com
Version: 2016.0.7797 / Virus Database: 4656/13181 - Release Date: 10/10/16

-- http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
mailman.mit.edu/mailman/listinfo/piclist
.

2016\10\10@063011 by IVP

face picon face

> The third row in your image is described as, “tblrd*- omitted after
> erase.” Does that mean in the other examples you are doing the tblrd*-

Hi Christopher,

well, I started with the d/s example (plus their omitted tblrd*-) and
am now back to it. As I mentioned to Tony, the write does seem
to be working at the moment, but seemingly not the erase

I've got projects out there using 1320 from another batch which I
can borrow back to see if there could be a chip issue with the tube
I have here

Joe



-----
No virus found in this message.
Checked by AVG - http://www.avg.com
Version: 2016.0.7797 / Virus Database: 4656/13181 - Release Date: 10/10/16

--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
mailman.mit.edu/mailman/listinfo/piclist

2016\10\10@072956 by Anthony Nixon

picon face
Sorry for my ignorance, I haven't used any 18Fxxxx chips yet.

Does the access bit [a] default to 0 (ie bypass the BSR) for any
instructions that do not explicitly set it.

Example:

movwf EECON2 is the same as movwf EECON2,0

Is that a default compiler setting?

cheers

Tony



On Sun, Oct 9, 2016 at 10:19 AM, IVP <.....joecolquittKILLspamspam.....clear.net.nz> wrote:
{Quote hidden}

-- http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
mailman.mit.edu/mailman/listinfo/piclist
.

2016\10\10@081250 by IVP

face picon face
> Example:
>
> movwf EECON2 is the same as movwf EECON2,0
>
> Is that a default compiler setting?

I'd imagine so, or at least I don't ever recall setting it otherwise

movlw 0x55
movwf eecon2

disassembles as

MOVLW 0x55
MOVWF EECON2, ACCESS

Similarly bsf eecon1,eepgd

BSF EECON1, 0x07, ACCESS

Joe


-----
No virus found in this message.
Checked by AVG - http://www.avg.com
Version: 2016.0.7797 / Virus Database: 4656/13181 - Release Date: 10/10/16

-- http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
mailman.mit.edu/mailman/listinfo/piclist
.

2016\10\10@095424 by Anthony Nixon

picon face
You have buffer and buffer48 defined

Any conflict there?

On Mon, Oct 10, 2016 at 11:12 PM, IVP <EraseMEjoecolquittspam_OUTspamTakeThisOuTclear.net.nz> wrote:
{Quote hidden}

-- http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
mailman.mit.edu/mailman/listinfo/piclist
.

2016\10\10@105456 by Anthony Nixon

picon face
I wrote this test program and simulated with MPLAB

It writes values 64 down to 1 into a RAM buffer

Then it writes those bytes to ROM from BCD address in dg10 and dg01

There were 2 faults that I think failed in your code

(1)  the tblrd*- instruction after erasing the ROM block causes an
invalid TBLPTR address - see below

(2) If you execute the code as written in your code and the data
sheet, then the TBLPTR will be set to the next 8 byte ROM block
"before" the write takes place. The data will then be written to the
following 8 bytes in ROM which is wrong

I modified the code to tblwt*+ the TBLPTR for the first 7 bytes then
it does a tblwt* on the 8th to keep the TBLPTR in the correct block

The write then takes place followed by another tblwt*+ which sets the
TBLPTR at the start of the next 8 byte block and continues the process
until all 64 bytes are written.

It works ok in MPLAB


You can probably optimize it further if you like.

cheers

Tony




   list P = PIC18F1320
;
   include "P18f1320.inc"
t_data = 0x1800
CBLOCK 0X80
temp0
temp1
bitcntL
bitcntH
dg10
dg01
buffer
ENDC
mov      macro   val,file
         movlw   val
         movwf   file
         endm

org 0x0000

; write 48 bytes to buffer
mov .64,bitcntL
lfsr FSR1,buffer   ;data to WRite
fillBuff movff bitcntL,POSTINC1
decfsz bitcntL
goto fillBuff
;multiply digits by 64 to find block, add t_data base
;
;eg
;digits = 23 in <temp1:temp0> = 05c0, + 1800 = 1dc0
;Erase block
;Write buffer48 to block
;WR_block movff   buffer,POSTINC0 ;last byte received
        movlw   .0              ;display value, manual test
        movwf   dg01
        movlw   .0
        movwf   dg10
         call    blk_add         ;get block start address
;         clrf    tblptru         ;Flash block address, manual test
;         movlw   0x18
;         movwf   TBLPTRH
;         movlw   0x40
;         movwf   TBLPTRL
;Block command can resolve to 8 bytes
;Erase command can resolve to 64 bytes (x00,x40,x80,xc0 starts)
;Erase block
erase    bcf     EECON1,CFGS     ;erase block
         bsf     EECON1,EEPGD
         bsf     EECON1,WREN
         bsf     EECON1,FREE
         bcf     INTCON,GIE
         mov     0x55,EECON2
         mov     0xAA,EECON2
         bsf     EECON1,WR
         nop
        ; tblrd*- ; CAUSES TBLPTRHL = 0x17FF  ????
;WRite RAM to Flash as 64-byte (8*8) block
         mov     .8,bitcntH      ;'8-bytes' counter
         lfsr    FSR1,buffer   ;data to WRite
Write    mov     .7,bitcntL      ;byte counter
copy8    movff   POSTINC1,TABLAT ;copy 8 bytes to WRite buffer
         tblwt*+
         decfsz  bitcntL         ;byte counter
         bra     copy8
        movff   POSTINC1,TABLAT ;copy 8 bytes to WRite buffer
         tblwt*
         mov     0x55,EECON2
         mov     0xaa,EECON2
         bsf     EECON1,WR
         nop
         tblwt*+
         decfsz  bitcntH         ;8-byte counter
         bra     Write
         bcf     EECON1,WREN
wait goto    wait            ;done
;================
;Get Flash address from dg10:dg01, tens:units, 00d-30d
blk_add  rlncf   dg10,W          ;combine dg10:dg01
         rlncf   WREG
         rlncf   WREG            ;(dg10 * 8) + (dg10 * 2)
         addwf   dg10,W
         addwf   dg10,W
         addwf   dg01,W          ;+ dg01
         movwf   temp1           ;temp1 = (dg10 * 10) + dg01
         clrf    temp0
         bcf STATUS,C                    ;* 64
         rrcf    temp1
         rrcf    temp0
         rrcf    temp1
         rrcf    temp0
         bcf STATUS,C                    ;add 0x1800 base address
         movlw   Low(t_data)
         addwf   temp0
         movlw   High(t_data)
         addwfc  temp1
         clrf    TBLPTRU         ;Flash block address
         movff   temp1,TBLPTRH
         movff   temp0,TBLPTRL
         return
end

On Tue, Oct 11, 2016 at 12:54 AM, Anthony Nixon <tnixon059spamspam_OUTgmail.com> wrote:
{Quote hidden}

-- http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
mailman.mit.edu/mailman/listinfo/piclist
.

2016\10\10@110512 by Anthony Nixon

picon face
It's late at night......


This listing might be better to read


   list P = PIC18F1320
;
   include "P18f1320.inc"
t_data = 0x1800
CBLOCK 0X80
temp0
temp1
bitcntL
bitcntH
dg10
dg01
buffer
ENDC
mov      macro   val,file
         movlw   val
         movwf   file
         endm

org 0x0000

; write 64 bytes to buffer
mov .64,bitcntL
lfsr FSR1,buffer
fillBuff movff bitcntL,POSTINC1
decfsz bitcntL
goto fillBuff

; write to first data block
        movlw   .0
        movwf   dg01
        movlw   .0
        movwf   dg10
         call    blk_add         ;get block start address

;Erase block
erase    bcf     EECON1,CFGS     ;erase block
         bsf     EECON1,EEPGD
         bsf     EECON1,WREN
         bsf     EECON1,FREE
         bcf     INTCON,GIE
         mov     0x55,EECON2
         mov     0xAA,EECON2
         bsf     EECON1,WR
         nop

; ????????????????????
        ; tblrd*- ; CAUSES TBLPTRHL = 0x17FF  ????
; ????????????????????

; 8 loops for 8 bytes = 64 bytes
         mov     .8,bitcntH      ;'8-bytes' counter
         lfsr    FSR1,buffer   ;data to WRite
; write 7 bytes first
Write    mov     .7,bitcntL
copy7    movff   POSTINC1,TABLAT
         tblwt*+
         decfsz  bitcntL
         bra     copy7
; do 8th byte - write the latch without post inc
        movff   POSTINC1,TABLAT
         tblwt*
; write to ROM
         mov     0x55,EECON2
         mov     0xaa,EECON2
         bsf     EECON1,WR
         nop
; set ready for next 8 byte block
         tblwt*+
; do another 8 bytes ??
         decfsz  bitcntH
         bra     Write           ; yes
; no - all done
         bcf     EECON1,WREN
wait goto    wait
;================
;Get Flash address from dg10:dg01, tens:units, 00d-30d
blk_add  rlncf   dg10,W          ;combine dg10:dg01
         rlncf   WREG
         rlncf   WREG            ;(dg10 * 8) + (dg10 * 2)
         addwf   dg10,W
         addwf   dg10,W
         addwf   dg01,W          ;+ dg01
         movwf   temp1           ;temp1 = (dg10 * 10) + dg01
         clrf    temp0
         bcf STATUS,C                    ;* 64
         rrcf    temp1
         rrcf    temp0
         rrcf    temp1
         rrcf    temp0
         bcf STATUS,C                    ;add 0x1800 base address
         movlw   Low(t_data)
         addwf   temp0
         movlw   High(t_data)
         addwfc  temp1
         clrf    TBLPTRU         ;Flash block address
         movff   temp1,TBLPTRH
         movff   temp0,TBLPTRL
         return
end

On Tue, Oct 11, 2016 at 1:54 AM, Anthony Nixon <KILLspamtnixon059KILLspamspamgmail.com> wrote:
{Quote hidden}

--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
mailman.mit.edu/mailman/listinfo/piclist
.

2016\10\10@143228 by Christopher Head

flavicon
face
part 1 492 bytes content-type:text/plain; charset="utf-8" (decoded base64)

On Mon, 10 Oct 2016 23:29:32 +1300
IVP <TakeThisOuTjoecolquittEraseMEspamspam_OUTclear.net.nz> wrote:

> well, I started with the d/s example (plus their omitted tblrd*-) and
> am now back to it. As I mentioned to Tony, the write does seem
> to be working at the moment, but seemingly not the erase

Mm, don’t know. I don’t see anything obvious in the code that would
cause trouble with erasing. I also don’t have any 1320s around to test
with.
--
Christopher Head

part 2 197 bytes content-type:text/plain; name="ATT00001.txt"
(decoded base64)

--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
mailman.mit.edu/mailman/listinfo/piclist

2016\10\10@170157 by IVP

face picon face

> Mm, don’t know. I don’t see anything obvious in the code that would
> cause trouble with erasing. I also don’t have any 1320s around to test
> with.

I got a couple of different 1320 back and tried them. They do the just
same thing. All the 1320s I have or have used are Rev 7, spanning 3
years of date codes

Looking through the d/s nothing preventing erasing jumps out at me.
The protection bits appear to be correct in the hex file, as viewed in
either MPLAB or Notepad

 CONFIG  CP0 = OFF
 CONFIG  CP1 = OFF
 CONFIG  WRT0 = OFF
 CONFIG  WRT1 = OFF

Besides, the chip is writeable if the block is previously blanked

Joe



-----
No virus found in this message.
Checked by AVG - http://www.avg.com
Version: 2016.0.7797 / Virus Database: 4656/13181 - Release Date: 10/10/16

--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
mailman.mit.edu/mailman/listinfo/piclist

2016\10\10@173001 by IVP

face picon face
>I wrote this test program and simulated with MPLAB

Thank you for your effort Tony.

Your code does indeed write a block correctly. As did mine,
which for some reason came right (at least twice anyway) last
evening

However, the chip will still not write without the block being
blanked by 0000 at programming time. If I can't solve that
then anything else is academic

Thanks again

Joe


-----
No virus found in this message.
Checked by AVG - http://www.avg.com
Version: 2016.0.7797 / Virus Database: 4656/13181 - Release Date: 10/10/16

-- http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
mailman.mit.edu/mailman/listinfo/piclist
.

2016\10\10@185234 by Anthony Nixon

picon face
The chip internal programming must work because it programs properly.
The programmer algorithm would have to write the data in a similar
way. (from memory I think this is the case for 18F series)

Have you tried writing a new and simple program that just writes 8
bytes to 0x1840 and then read the chip back in a programmer?

Any floating input pins? - they can cause weird things to happen -
"for some reason it came right twice" :-)

cheers

Tony

On Tue, Oct 11, 2016 at 8:29 AM, IVP <RemoveMEjoecolquittspamTakeThisOuTclear.net.nz> wrote:
{Quote hidden}

-- http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
mailman.mit.edu/mailman/listinfo/piclist
.

2016\10\10@193616 by IVP

face picon face
> The chip internal programming must work because it programs properly.

That hasn't gone unthought about ;-)

Although /mclr is pulled up to ~13V during programming

> Have you tried writing a new and simple program that just writes 8
> bytes to 0x1840 and then read the chip back in a programmer?

Ignoring the outer '8-byte' loop ? Yes

> Any floating input pins? - they can cause weird things to happen -
> "for some reason it came right twice" :-)

All pins except /mclr are o/p, which has 10k/100n. There's about
30mV noise below Vcc on the pin during the self-write

Joe


-----
No virus found in this message.
Checked by AVG - http://www.avg.com
Version: 2016.0.7797 / Virus Database: 4656/13185 - Release Date: 10/10/16

-- http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
mailman.mit.edu/mailman/listinfo/piclist
.

2016\10\10@201937 by Anthony Nixon

picon face
> CONFIG  CP0 = OFF
>  CONFIG  CP1 = OFF
>  CONFIG  WRT0 = OFF
>  CONFIG  WRT1 = OFF

what about EBTR1 EBTR0 ?


Cheers
Tony

On Tue, Oct 11, 2016 at 10:36 AM, IVP <joecolquittEraseMEspam.....clear.net.nz> wrote:
{Quote hidden}

-- http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
mailman.mit.edu/mailman/listinfo/piclist
.

2016\10\10@214348 by IVP

face picon face
> what about EBTR1 EBTR0 ?

 CONFIG  EBTR0 = OFF
 CONFIG  EBTR1 = OFF

Swing an' a miss

Sorry

I've also tried LVP = ON, and adding another erase/write routine
with all 0000 before trying to write the actual data

Meant to mention that the mV activity on /mclr and Vcc during the
self-write does seem to imply that extra current is being drawn. Don't
know if that's during the attempted erase or attempted write

The project started with just a 16F88, then I thought it would be
nice to add a display and storage, hence two chips

A couple of sighs away from porting the whole lot to a 2520 or
43K20

Joe


-----
No virus found in this message.
Checked by AVG - http://www.avg.com
Version: 2016.0.7797 / Virus Database: 4656/13185 - Release Date: 10/10/16

-- http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
mailman.mit.edu/mailman/listinfo/piclist
.

2016\10\11@045456 by IVP

face picon face
part 1 1261 bytes content-type:text/plain; charset="utf-8" (decoded base64)

> Mm, don’t know. I don’t see anything obvious in the code that would
> cause trouble with erasing. I also don’t have any 1320s around to test
> with.

Hi Christopher, Tony

I moved the code over to an 18F14K22

Bam, perfect erase and block write first time with the d/s example, ie
the same routines that should have worked on the 1320

Used CONFIG settings from my last K22 project (below). I realised
that I have to keep it as a two-chip system so it'll replace the 1320.
The F88 is running on RC osc with a pot for the R so that the speed
of functions of the data can be analoguely varied. If I meld everything
into one chip I don't think it would work as well overall. Maybe use
T1OSC but it's a lot of messing about and more code

Thanks for the input

Joe

        CONFIG FOSC = IRC

        CONFIG PLLEN = ON

        CONFIG PWRTEN = ON

        CONFIG WDTEN = OFF

        CONFIG LVP = OFF

        CONFIG CP0 = OFF, CP1 = OFF

        CONFIG CPB = OFF, CPD = OFF

        CONFIG WRT0 = OFF, WRT1 = OFF

        CONFIG WRTC = OFF, WRTB = OFF, WRTD = OFF

        CONFIG EBTR0 = OFF, EBTR1 = OFF

        CONFIG EBTRB = OFF

        CONFIG MCLRE = ON


part 2 2009 bytes content-type:image/gif; name="16F88_RC_osc.gif" (decode)


part 3 183 bytes content-type:text/plain; name="Certification"
(decoded base64)

-----
No virus found in this message.
Checked by AVG - http://www.avg.com
Version: 2016.0.7797 / Virus Database: 4656/13185 - Release Date: 10/10/16

part 4 197 bytes content-type:text/plain; name="ATT00001.txt"
(decoded base64)

--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
mailman.mit.edu/mailman/listinfo/piclist

2016\10\11@055303 by Anthony Nixon

picon face

Glad to hear it is running, odd about the chip though.

Nice to see I'm not the only one getting a grey hair or two.

I'm trying to decipher the microcode of an old HP printing calculator
to add to my emulator. It is really testing out my old brain box :-)

cheers

Tony

On Tue, Oct 11, 2016 at 7:48 PM, IVP <EraseMEjoecolquittspamclear.net.nz> wrote:
{Quote hidden}

--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
mailman.mit.edu/mailman/listinfo/piclist

2016\10\11@062142 by IVP

face picon face
> Glad to hear it is running, odd about the chip though.

I'm almost tempted to get a couple of new 1320 next time I shop
at MC or Mouser just to see if it's this Rev. But I've been there
before with another problem and ended up with the same Rev.
Just going to let this one go I think, the chips seem to work fine
otherwise

> Nice to see I'm not the only one getting a grey hair or two.

Thankfully major headscratchers are rare so micros are still fun  
> I'm trying to decipher the microcode of an old HP printing
> calculator to add to my emulator. It is really testing out my
> old brain box :-)

BTW, did you notice that we have letters on consecutive
pages in the July 2016 Silicon Chip ?

Joe


-----
No virus found in this message.
Checked by AVG - http://www.avg.com
Version: 2016.0.7797 / Virus Database: 4656/13188 - Release Date: 10/11/16

-- http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
mailman.mit.edu/mailman/listinfo/piclist
.

2016\10\11@090720 by Anthony Nixon

picon face
>BTW, did you notice that we have letters on consecutive
>pages in the July 2016 Silicon Chip ?


I missed that. I'll have a look.

The last project they published of mine was a programmable ignition
system based on a 16F84 many moons ago. Amazing what you can fit in 1K
of ROM.

cheers

Tony

On Tue, Oct 11, 2016 at 9:21 PM, IVP <RemoveMEjoecolquittEraseMEspamEraseMEclear.net.nz> wrote:
{Quote hidden}

-- http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
mailman.mit.edu/mailman/listinfo/piclist
.

2016\10\11@180805 by James Cameron

flavicon
face
On Tue, Oct 11, 2016 at 11:21:32PM +1300, IVP wrote:
> > Glad to hear it is running, odd about the chip though.
>
> I'm almost tempted to get a couple of new 1320 next time I shop
> at MC or Mouser just to see if it's this Rev. But I've been there
> before with another problem and ended up with the same Rev.
> Just going to let this one go I think, the chips seem to work fine
> otherwise
>  
> > Nice to see I'm not the only one getting a grey hair or two.
>
> Thankfully major headscratchers are rare so micros are still fun
>  
> > I'm trying to decipher the microcode of an old HP printing
> > calculator to add to my emulator. It is really testing out my
> > old brain box :-)
>
> BTW, did you notice that we have letters on consecutive
> pages in the July 2016 Silicon Chip ?

I'm continually astounded that Silicon Chip is still alive; but they
continual to exhibit signs of good business management in the face of
change.

-- James Cameron
http://quozl.netrek.org/
-- http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
mailman.mit.edu/mailman/listinfo/piclist
.

2016\10\11@191534 by IVP

face picon face
> I'm continually astounded that Silicon Chip is still alive; but they
> continue to exhibit signs of good business management in the face
> of change

They do have a good mix of information and things to make. It must
be a struggle to come up with novel and viable projects. Looking back
at my mags from the 70s and 80s - before micros, before everything
came on a ship from China for $5 - the simplicity of many projects is
very noticeable. Sunday afternoon, garden shed, Veroboard, make a
doorbell that chirps like a canary. Kind of.

Now and then you'll see a letter to the editor about "too many micro
or SMT projects" but if you want functions and flexibility then a micro
is the only economic option, vs a big board full of DIP logic.

Some of the simpler SC projects, particularly those using the smaller
PICs or PICAXEs, I pass on to a group of high school students who
in earlier times could not have gone straight to Sparkfun or eBay as
they can now and not learn anything on the way. They are still keen
to get busy with a soldering iron and a full SC project article is about
as good as it gets. A lot of them are pretty competent with Arduino
etc but not so with basic components and interfacing. SC projects
are very helpful in that regard, and counter some of the bad practices
found on the web all too easily.

For example, I recently passed on a very good NiMH charger project.
The student had asked for advice and offered up some awful thing he'd
got off the web as a circuit he would have made otherwise. His poor
poor batteries if he had

Joe


-----
No virus found in this message.
Checked by AVG - http://www.avg.com
Version: 2016.0.7797 / Virus Database: 4656/13192 - Release Date: 10/11/16

-- http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
mailman.mit.edu/mailman/listinfo/piclist
.

More... (looser matching)
- Last day of these posts
- In 2016 , 2017 only
- Today
- New search...