Hi,
First off, I now realize that I was missing the ECC interaction in my
earlier post (http://groups.yahoo.com/group/lpc2000/message/4102)
Thanks to Leighton for posting the reference to article 2681, as I
hadn't gone far enough back in the archive to find it.
Since ECC is intended to correct single bit errors, it seems to me
that I might be able to construct multi-bit changes ("errors") that
will not affect the computed ECC value. Thus the 4-byte word I use
to track my image state might potentially have several usable values
that are compatible with the original ECC entry. My sectoring
arrangement requires only 4 states, so I don't need too many patterns
and the 16 writes per row limit is a distant worry.
Trouble is, I don't know how the ECC value is calculated, so I don't
know how to work out bit patterns to use. There are books available
on the subject, but what I really need to know is how the LPC works.
Philips, can you help with this?
Here's an illustrative example. Would a simple progression such as
the following work? E.g., for one particular word in the row
changing, all other values constant:
0xFFFFFFFF (erased)
0xFFF0FFF0 (ECC calculated here)
0xFF00FF00 (compatible ECC?)
0xF000F000
0x00000000
Thanks,
Tom
--- In lpc2000@yahoogroups.com, onestone <onestone@b...> wrote:
> Bugger! that totally screws up the filing system I use for flash
> database management, and probably the main application I have in
mind
> for this part. My response was purely a generic one related to
flash, as
> I've not yet got my hands on any LPC silicon.
>
> philips_apps wrote:
>
> >
> > Hi Al,
> >
> > even changing some bits from 1 to 0 would generate a wrong
reading.
> > The LPC2000 devices have an error correction ECC mechanism build
in.
> > This is part of the flash and will be written the first time
(after
> > erasing) the block of 128-bits is programmed. Any changes
thereafter
> > will result in reading garbage because the ECC mechanism will try
to
> > correct anything changed after the initial write.
> >
> > The idea was to write one 128-bit block after the other, NOT
writing
> > the same 128-bit block several times. This is possible 16 times
within
> > a 4k block. So 16 writes to 16 different sections of 128-bit each
> > within a 4k block, then erase the 4k block.
> >
> > Hopefully this clarifies this issue a little more.
> >
> >
> > --- In lpc2000@yahoogroups.com, onestone <onestone@b...> wrote:
> > > Flash bits can only be written to '0'. They erase to a '1'
state.
> > > Therefore unless you are only changing a couple of bits to '0'
you MUST
> > > erase flash everytime before reprogramming it.
> > >
> > > Al
> > >
> > > Leighton Rowe wrote:
> > >
> > > >
> > > > Concerning Philips Apps' post on Partial Flash Programming I
> > > > understand lpc flash memory can be updated 128 bits
(minimum) at a
> > > > time, and that a each 4K area can be written 16 times (max).
> > > >
> > > > (http://groups.yahoo.com/group/lpc2000/message/2681)
> > > >
> > > > However, I'm currently having trouble updating 128-bit
(quadword
> > > > aligned) locations in flash memory. The first write always
> > > > show up OK (as long as the location has all 1's), but on the
2nd
> > > > write (on the same location) results in some bit(s) not
displaying
> > > > correctly.
> > > >
> > > > Is it possible for me to re-write a 128-bit (quadword
aligned) flash
> > > > locations? Or must I erase the flash location first? I can
do the
> > > > second question, but I'm a little confused about how often
flashShow quoted textHide quoted text
> > > > bits can change without an erase.
> > > >
> > > > best regards,
> > > > Leighton
> > > >
> > > >