Lpc2000

Hello,

N1: In the ECC section of the user manual, it is stated that flash can be 
written to in units of 16-bytes, aligned on any 16-byte boundary.

N2: In the ISP/IAP COPY commands documentation, it is stated that byte 
count must be one of 256, 512, 1024 or 4096.

Q1: N1+N2 implies that to update 16 bytes (on 16-byte boundary), one must 
read 256 bytes, modify 16 bytes at the appropriate offset, and then write 
256 bytes.  Is this correct?

Q2: What is the rational for what appears to be arbitrary limits on the 
values for byte counts in N2.

Thanks

Jaya

Send instant messages to your online friends http://au.messenger.yahoo.com

At 11:49 PM 1/28/06 +0800, Jayasooriah wrote:
>N1: In the ECC section of the user manual, it is stated that flash can be
>written to in units of 16-bytes, aligned on any 16-byte boundary.
>
>N2: In the ISP/IAP COPY commands documentation, it is stated that byte
>count must be one of 256, 512, 1024 or 4096.
>
>Q1: N1+N2 implies that to update 16 bytes (on 16-byte boundary), one must
>read 256 bytes, modify 16 bytes at the appropriate offset, and then write
>256 bytes.  Is this correct?

Correct.

>Q2: What is the rational for what appears to be arbitrary limits on the
>values for byte counts in N2.

No idea, could be that it matches some internal structure of the flash, the 
fact that the write must occur on a 512 byte boundary (LPC2106) implies 
that's the case.  Maybe that's the smallest block they can address when 
flashing?

BTW the size of the block and the multiples that can be written varies from 
device to device.

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,   be 
they legal, genetic, or physical.  If you don't believe me, try to chew a 
radio signal. "  -- Kelvin Throop, III
http://www.aeolusdevelopment.com/

> >Q1: N1+N2 implies that to update 16 bytes (on 16-byte boundary),
> >one must read 256 bytes, modify 16 bytes at the appropriate
> >offset, and then write 256 bytes.  Is this correct?
> Correct.

Well; for areas that already has information but fall inside my 256 
byte chunk I am writing 0xFF instead of the original content. The 
reason I do this is to avoid forcing a "huge" 0 where there is 
already one. I read some long time ago about how EPROMs worked (yes, 
old UV EPROMs, like 2732, 2764); the idea was that holes and 
electrons are pushed from one side to the other, and every time you 
push a hole or an electron, it is more difficult to put it in the 
other place again. I have no idea if I've got the concept correctly 
(I was 16 old!) or if this applies to flash memories as well, but the 
fact that they have a limited number of writing cycles seems to 
suggest so.

"1s" are suppossed to be neutral, whilst "0s" actively attempt to 
modify the memory contents. Writing 0xFF instead of the original 
contents seems to work just fine as far as my tests go. Besides, the 
EE_Demo project in the Files section of this group does likewise.

It would be great to know for sure which method is best with some 
explanation of why.

Guille

I would have said the same, except that there are missing multiples of
512 in the allowed values for byte count.

--- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@a...> wrote:

> No idea, could be that it matches some internal structure of the
flash, the  
> fact that the write must occur on a 512 byte boundary (LPC2106) implies 
> that's the case.  Maybe that's the smallest block they can address when 
> flashing?
> 
> BTW the size of the block and the multiples that can be written
varies from 
> device to device.

Like you my knowledge is from early days.  I can confirm that writing
the value that the cells are in erased state does not affect endurance
cycles.  But writing value that is different to the erased state does
consume endurance cycles even if the cell is already in the state that
is being written into.  This applies to both NAND and NOR types.

I would like to add -- be careful about using flash as replacement for
EEPROM.  It will work well for initial tests but it fails in the field
because EEPROM and FLASH technologies have very difference endurance
limits.

In this sense, as someone else said, the EE_Demo IMHO is an example of
perfect demo -- works only for the purpose it was designed for but is
of little or no use in real life otherwise.

Jaya

PS:  If flash can be used as EEPROM, manufactures will not bother to
have both flash *and* EEPROM embedded in the same SoC.

--- In lpc2000@yahoogroups.com, "Guillermo Prandi"
<yahoo.messenger@m...> wrote:

> "1s" are suppossed to be neutral, whilst "0s" actively attempt to 
> modify the memory contents. Writing 0xFF instead of the original 
> contents seems to work just fine as far as my tests go. Besides, the 
> EE_Demo project in the Files section of this group does likewise.
> 
> It would be great to know for sure which method is best with some 
> explanation of why.
> 
> Guille
>

> affect endurance cycles.  But writing value that is different 
> to the erased state does consume endurance cycles even if the 
> cell is already in the state that is being written into.  

Interesting. I'll make sure I do this.

> I would like to add -- be careful about using flash as 
> replacement for EEPROM.  It will work well for initial tests 
> but it fails in the field because EEPROM and FLASH 
> technologies have very difference endurance limits.
> 
> In this sense, as someone else said, the EE_Demo IMHO is an 
> example of perfect demo -- works only for the purpose it was 
> designed for but is of little or no use in real life otherwise.

I'll have to disagree here. Surely it depends very much on what you are
using the Flash-EEprom *for*; that is, how often you write to it ?
If you have user settable parameters that may be changed only a few
times in the lifetime of the product, I can't see a problem with using
Flash instead of EEprom on the endurance issue. It's still an
application you'd formerly have used EEprom (or equivalents) for.
Even for some system-state EEprom applications, you can often hold off
updating the non-volatile storage till just before imminent power loss
(or some really-long time interval as a just-in-case backup). These are
just examples of ways to cut down the write-times, and should be applied
to EEprom also.

> PS:  If flash can be used as EEPROM, manufactures will not 
> bother to have both flash *and* EEPROM embedded in the same SoC.

Also, look carefully....often EEprom quoted write endurance is similar
to what is quoted for Flash. The main advantage for EEprom is byte-only
write access, not endurance cycles at all.

Cheers,
Bruce

One has to consider what the purpose of EE_Demo is.  I see it as
providing an EEPROM interface for FLASH.  It is implied therefore,
that if you use this interface, you get EEPROM for free on the LPC. 
This IMO is not right.

The two technologies are different in that unlike FLASH, EEPROM is
*designed* for erase-and-write one byte at a time.  As a result, the
endurance of the system as a whole can be easily estimated directly
from EEPROM endurance.

In the case of FLASH emulation of EEPROM, the endurance of the system
quite different to FLASH endurance.  Minimum erase size (sector size)
and minimum write size (128-bits) needs to be taken into account in
the model to determine system endurance.

The EE_Demo hides this important consideration, hence my objection.

I have seen designs that work perfectly during prototype and initial
launch, but fail miserably in the field well ahead of their 'design'
lifetimes because these factors were not taken into account.  

The other thing to bear in mind in the case of LPC is that LPC native
flash endurance cycle is less than the ECC'ed endurance cycles that is
specified.

Jaya

--- In lpc2000@yahoogroups.com, "Bruce Paterson" <bruce.paterson@b...>
wrote:

> > I would like to add -- be careful about using flash as 
> > replacement for EEPROM.  It will work well for initial tests 
> > but it fails in the field because EEPROM and FLASH 
> > technologies have very difference endurance limits.
> > 
> > In this sense, as someone else said, the EE_Demo IMHO is an 
> > example of perfect demo -- works only for the purpose it was 
> > designed for but is of little or no use in real life otherwise.
> 
> I'll have to disagree here. Surely it depends very much on what you are
> using the Flash-EEprom *for*; that is, how often you write to it ?

What is the purpose of an EEPROM? To hold a small amount of 
reprogrammable data, that can be organized anything from bit-wise to 
big structures. Usually it gets reprogrammed frequently. So, 
reprogramming cycles are very important. Most dedicated EEPROMs have 
more than 1 Mio reprogramming cycles, the flash on the LPC2000 
devices just 100k. 

Assuming it is data that needs to be written every day when powering 
down a machine at the end of the workday. That makes approx. 300 
days a year and this should happen for 20 years, gives 6000 cycles, 
emulating the EEPROM by using Flash should be just fine.

The purpose of the EE_Demo is to help our customers to write small 
set of data into the Flash and saving the expense of an EEPROM. It 
does not imply anything but the facts it is stating, a customer 
might be able to use the Flash and get by without an EEPROM. You are 
right, Flash and EEPROM are different, nevertheless, a Flash can 
provide enough functionality to replace the function of an EEPROM. 
So, for those many customers that do not want to spend the extra 
money for an EEPROM, this application note can save some money, if 
you need a "real" EEPROM, please feel free to attach it to the SPI 
or I2C interface. 

Robert


--- In lpc2000@yahoogroups.com, "jayasooriah" <jayasooriah@y...> 
wrote:
>
> One has to consider what the purpose of EE_Demo is.  I see it as
> providing an EEPROM interface for FLASH.  It is implied therefore,
> that if you use this interface, you get EEPROM for free on the 
LPC. 
> This IMO is not right.
> 
> The two technologies are different in that unlike FLASH, EEPROM is
> *designed* for erase-and-write one byte at a time.  As a result, 
the
> endurance of the system as a whole can be easily estimated directly
> from EEPROM endurance.
> 
> In the case of FLASH emulation of EEPROM, the endurance of the 
system
> quite different to FLASH endurance.  Minimum erase size (sector 
size)
> and minimum write size (128-bits) needs to be taken into account in
> the model to determine system endurance.
> 
> The EE_Demo hides this important consideration, hence my objection.
> 
> I have seen designs that work perfectly during prototype and 
initial
> launch, but fail miserably in the field well ahead of 
their 'design'
> lifetimes because these factors were not taken into account.  
> 
> The other thing to bear in mind in the case of LPC is that LPC 
native
> flash endurance cycle is less than the ECC'ed endurance cycles 
that is
> specified.
> 
> Jaya
> 
> --- In lpc2000@yahoogroups.com, "Bruce Paterson" 
<bruce.paterson@b...>
> wrote:
> 
> > > I would like to add -- be careful about using flash as 
> > > replacement for EEPROM.  It will work well for initial tests 
> > > but it fails in the field because EEPROM and FLASH 
> > > technologies have very difference endurance limits.
> > > 
> > > In this sense, as someone else said, the EE_Demo IMHO is an 
> > > example of perfect demo -- works only for the purpose it was 
> > > designed for but is of little or no use in real life otherwise.
> > 
> > I'll have to disagree here. Surely it depends very much on what 
you are
> > using the Flash-EEprom *for*; that is, how often you write to 
it ?
>

Dear Robert,

You missed my point.

You suggest that the EE_Demo is for users who know how to use EEPROM
to store small amounts of data, but do not know how to do this using
LPC FLASH memory.  If they did, they would not need your interface.

It is precisely such an audience that needs to be forewarned that
FLASH and EEPROM have very difference endurance cycles.  I would
recommend you point this out clearly in the documentation if you have
not done so.

The interface you provide hides the underlying implementation, making
EEPROM and FLASH look the same, and for those who do not bother doing
this on their own.  This is why I say while it may be a good academic
exercise for students, it is of dubious value for real world use.

Using flash to store small (or large amounts) amounts of read-write
data is not a new concept.

To put it bluntly, you may think you are saving money by doiong away
with EEPROM and using your EEPROM over FLASH interface, until your
product is in the field and you discover how different the endurance
cycles differnt.

The reason for your "demo" is to show how to work around ECC bug in
LPC flash implementation, because it ECC is not as transparent is it
was supposed to be.   Am I right?

Jaya

--- In lpc2000@yahoogroups.com, "philips_apps" <philips_apps@y...> wrote:

>
> What is the purpose of an EEPROM? To hold a small amount of 
> reprogrammable data, that can be organized anything from bit-wise to 
> big structures. Usually it gets reprogrammed frequently. So, 
> reprogramming cycles are very important. Most dedicated EEPROMs have 
> more than 1 Mio reprogramming cycles, the flash on the LPC2000 
> devices just 100k. 
> 
> Assuming it is data that needs to be written every day when powering 
> down a machine at the end of the workday. That makes approx. 300 
> days a year and this should happen for 20 years, gives 6000 cycles, 
> emulating the EEPROM by using Flash should be just fine.
> 
> The purpose of the EE_Demo is to help our customers to write small 
> set of data into the Flash and saving the expense of an EEPROM. It 
> does not imply anything but the facts it is stating, a customer 
> might be able to use the Flash and get by without an EEPROM. You are 
> right, Flash and EEPROM are different, nevertheless, a Flash can 
> provide enough functionality to replace the function of an EEPROM. 
> So, for those many customers that do not want to spend the extra 
> money for an EEPROM, this application note can save some money, if 
> you need a "real" EEPROM, please feel free to attach it to the SPI 
> or I2C interface. 
> 
> Robert