Lpc2000

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 
flash
> >  > > bits can change without an erase.
> >  > >
> >  > > best regards,
> >  > > Leighton
> >  > >
> >  > >