Searching \ for '[PIC] Writing to program memory' 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=memory
Search entire site for: 'Writing to program memory'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] Writing to program memory'
2009\03\31@114612 by Gordon Williams

flavicon
face
Using Pic16F886

I have been having problems writing some user changeable constants to the
program memory section of the PIC.  I understand about the 8 word (word = 14
bits) writes but I'm confused by the erase operation.  In the docs:

"All block writes to  program  memory  are  done  as  16-word  erase  by
eight-word  write  operations."

So as I understand it, before every 8 words that are written there is a 16
word erase of the 8 word block that is currently being written *as well as*
the following 8 words.  Therefore how do I ever get data into the following
8 words without erasing the next following block?

Could someone try and clarify what is happening here?

Gordon Williams

2009\03\31@131827 by Jan-Erik Soderholm

face picon face
Gordon Williams wrote:
> Using Pic16F886
>
> I have been having problems writing some user changeable constants to the
> program memory section of the PIC.  I understand about the 8 word (word = 14
> bits) writes but I'm confused by the erase operation.  In the docs:
>
>  "All block writes to  program  memory  are  done  as  16-word  erase  by
> eight-word  write  operations."
>
> So as I understand it, before every 8 words that are written there is a 16
> word erase of the 8 word block that is currently being written *as well as*
> the following 8 words.

No, the other 8 words in the currect 16-word block. Could be
the the following 8 words, it depends on which "half" of
the current 16-word block you are writing.


> Therefore how do I ever get data into the following
> 8 words without erasing the next following block?

You ease 16 word in 1 erase operation, then write 8+8
words in 2 write operations.

It's not a floating 16 word erase block...

Jan-Erik.

>
> Could someone try and clarify what is happening here?
>
> Gordon Williams
>

2009\03\31@140929 by Gordon Williams

flavicon
face
Hmm, maybe there is an error in the data sheet about the size of block and
where the boundary can be for the 886 chip.  It says

A  block  consists  of  eight  words  with
sequential addresses, with a lower boundary defined by
an address, where EEADR<2:0> = 000. All block writes
to  program  memory  are  done  as  16-word  erase  by
eight-word  write  operations.  The  write  operation  is
edge-aligned and cannot occur across boundaries.

...

The  user  must  follow  the  same  specific  sequence  to
initiate  the write for each  word in  the program block,
writing  each  program  word  in  sequence  (000,  001,
010,  011,  100,  101,  110,  111).  When  the  write  is
performed  on  the  last  word  (EEADR<2:0>  =  111),  a
block of sixteen words is automatically erased and the
content  of  the  eight  word  buffer  registers  are  written
into the program memory.

What it doesn't say is where the 16 words start and finish.  I thought that
the start would be at the start of the write block of 8 words, but you say,
if I understand correctly, that the 16 word erase needs to be aligned with
the edge of the 16 word boundary starting at address xxx0h.

In other words all writes should be edge aligned with the 16 word boundary
starting at xxx0h and I should do two 8 word writes to fill it.

I think that makes sense now.  Too bad the example in the datasheet didn't
bring that out :(
Text left out a few bits of critical info too.

I'll give that a try.

Thanks,

Gordon Williams

{Original Message removed}

2009\03\31@143307 by Peter

picon face
Gordon Williams <gwilliams <at> ncf.ca> writes:
> In other words all writes should be edge aligned with the 16 word boundary
> starting at xxx0h and I should do two 8 word writes to fill it.

If the 16 word erase occurs when *each* 8 word write occurs then there should be
no way to write the 'other' 8 words in a block without *another* 16 word erase
occurring. I suggest that more interpretation of the text is needed.

Peter


2009\03\31@145650 by Gordon Williams

flavicon
face
Ya that is what I was struggling with the way that it is written.  I'm now
assuming that the erase occurs after the first 8 word block, but not the
second.

They sure could have added a few more works to the datasheet.

Gordon Williams

{Original Message removed}

2009\03\31@155731 by Jan-Erik Soderholm

face picon face
Yes, it's a bit weird as it's written in the datasheet.
I would have expected an separate 16-word erase operation,
but it says that the erase is *part of* the 8-word write
operation.

Note that when programming the program memory through
ICSP from the "outside", the erase is a *separate* operation
(either a 16-word erase or an "erase all" operation).

It's not clear to me either now how you could write both
8-word "halfs" if there would be an automatic 16-word
erase at the same time...

The Programming Specification says about the ICSP 16-word
erase operation that "This command erases the 16-word row
of program memory pointed to by PC<11:4>". So the lower
4 bits (PC<3:0>) are "don't cares" so it's not a sliding
16-word erase block in that case at least (and I have
no reason to belive it is when doing self-write either).

Jan-Erik.



Gordon Williams wrote:
> Ya that is what I was struggling with the way that it is written.  I'm now
> assuming that the erase occurs after the first 8 word block, but not the
> second.
>
> They sure could have added a few more works to the datasheet.
>
> Gordon Williams
>
> {Original Message removed}

2009\03\31@172034 by Gordon Williams

flavicon
face
Weird is right.

Anyway I got it working.

Aligned with the 16 word boundary I copied the 16 words into an array, made
the changes required to the array and then wrote all 16 words back into
flash memory.

Thanks for the help,

Gordon Williams


{Original Message removed}

2009\03\31@174114 by Jan-Erik Soderholm

face picon face
Well, that's how one could expect it to work, but
not as I interpret the datasheet. :-)

Was you able to "see" if the programming runed after
wring 8 words or after writing all 16 words ?
If it erased and re-programed in chunks of 16 words
it would make sense.

Jan-Erik.



Gordon Williams wrote:
{Quote hidden}

> {Original Message removed}

2009\03\31@195852 by Gordon Williams

flavicon
face
I could see with the code that I have.

Thanks for your help,

Gordon Williams

----- Original Message -----
From: "Jan-Erik Soderholm" <spam_OUTjan-erik.soderholmTakeThisOuTspamtelia.com>
To: "Microcontroller discussion list - Public." <.....piclistKILLspamspam@spam@mit.edu>
Sent: Tuesday, March 31, 2009 4:41 PM
Subject: Re: [PIC] Writing to program memory


{Quote hidden}

made
{Quote hidden}

the
{Quote hidden}

there
> >>> should be
> >>>> no way to write the 'other' 8 words in a block without *another* 16
> > word
> >>> erase
> >>>> occurring. I suggest that more interpretation of the text is needed.
> >>>>
> >>>> Peter
> >>>>
> >>>>
> >>>> --
>


'[PIC] Writing to program memory'
2009\04\01@072925 by olin piclist
face picon face
Jan-Erik Soderholm wrote:
> Well, that's how one could expect it to work, but
> not as I interpret the datasheet. :-)
>
> Was you able to "see" if the programming runed after
> wring 8 words or after writing all 16 words ?
> If it erased and re-programed in chunks of 16 words
> it would make sense.

I haven't looked at that issue in that datasheet, but there is pretty much
only one way it can work.  It appears the erase size is 16 words and the
write buffer is 8 words.  This sort of thing isn't unusual.  I'd expect the
erase block to always be 16-word aligned and write blocks 8-word aligned.
That would mean you'd erase a block of 16 words, but it would require two
write operations to load new data into them.  How else could it work?


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\04\01@101411 by Jan-Erik Soderholm

face picon face
Olin Lathrop wrote:
> Jan-Erik Soderholm wrote:
>> Well, that's how one could expect it to work, but
>> not as I interpret the datasheet. :-)
>>
>> Was you able to "see" if the programming runed after
>> wring 8 words or after writing all 16 words ?
>> If it erased and re-programed in chunks of 16 words
>> it would make sense.
>
> I haven't looked at that issue in that datasheet, but there is pretty much
> only one way it can work.  It appears the erase size is 16 words and the
> write buffer is 8 words.  This sort of thing isn't unusual.  I'd expect the
> erase block to always be 16-word aligned and write blocks 8-word aligned.
> That would mean you'd erase a block of 16 words, but it would require two
> write operations to load new data into them.  How else could it work?

The point that was a bit unclear was that the second 8-word write
would erase the same 16-word area (and then erase what was written
in the first 8-word write).

How else ? Well, it could have a 16-word write buffer that you'd
have to write. That would match the automatic 16-word erase better.

If the erase would have been a separately initiated operation (as
in the case of ICSP-programming) there would be no issue.

Jan-Erik.

>
>
> ********************************************************************
> Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
> (978) 742-9014.  Gold level PIC consultants since 2000.

2009\04\04@211422 by Byron Jeff

flavicon
face
On Wed, Apr 01, 2009 at 07:30:08AM -0400, Olin Lathrop wrote:
> Jan-Erik Soderholm wrote:
> > Well, that's how one could expect it to work, but
> > not as I interpret the datasheet. :-)
> >
> > Was you able to "see" if the programming runed after
> > wring 8 words or after writing all 16 words ?
> > If it erased and re-programed in chunks of 16 words
> > it would make sense.
>
> I haven't looked at that issue in that datasheet, but there is pretty much
> only one way it can work.  It appears the erase size is 16 words and the
> write buffer is 8 words.  This sort of thing isn't unusual.  I'd expect the
> erase block to always be 16-word aligned and write blocks 8-word aligned.
> That would mean you'd erase a block of 16 words, but it would require two
> write operations to load new data into them.  How else could it work?

That's exactly how it's organized on the 16F88. You have to erase 32 word
blocks and program 4 word blocks.

BAJ

2009\04\05@072734 by Jan-Erik Soderholm

face picon face
Byron Jeff wrote:
> On Wed, Apr 01, 2009 at 07:30:08AM -0400, Olin Lathrop wrote:
>> Jan-Erik Soderholm wrote:
>>> Well, that's how one could expect it to work, but
>>> not as I interpret the datasheet. :-)
>>>
>>> Was you able to "see" if the programming runed after
>>> wring 8 words or after writing all 16 words ?
>>> If it erased and re-programed in chunks of 16 words
>>> it would make sense.
>> I haven't looked at that issue in that datasheet, but there is pretty much
>> only one way it can work.  It appears the erase size is 16 words and the
>> write buffer is 8 words.  This sort of thing isn't unusual.  I'd expect the
>> erase block to always be 16-word aligned and write blocks 8-word aligned.
>> That would mean you'd erase a block of 16 words, but it would require two
>> write operations to load new data into them.  How else could it work?
>
> That's exactly how it's organized on the 16F88. You have to erase 32 word
> blocks and program 4 word blocks.
>

Correct. But note that the datasheet (for the F88) clearly describes
the erase operation as an *separate* operation (separate from the
write operation). The datasheet for the device *this* thread is about
(16F886) says that the 16-word erase is done autmaticly as a part
of the 8-word write operation. And that is what the whole thread
was about from the beginning...

Jan-Erik.




> BAJ

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