Lpc2000

I just want to make sure that I'm reading this right before committing to
using a serial flash. It seems that the lpc21xx on-chip can't really be used
for eeprom emulation in real-time scenarios, since its sector erase takes
hundreds of milliseconds and is a blocking function. I guess that's why some
of philips' competitors have a separate data flash for such usage. The price
point of the lpc21xx doesn't look so good for us, when you have to tack on
an extra $1+ for an external SPI flash device.

--
Bryce Schober


[Non-text portions of this message have been removed]

--- In lpc2000@yahoogroups.com, "Bryce Schober" <bryce.schober@...> wrote:
>
> I just want to make sure that I'm reading this right before
committing to
> using a serial flash. It seems that the lpc21xx on-chip can't really
be used
> for eeprom emulation in real-time scenarios, since its sector erase
takes
> hundreds of milliseconds and is a blocking function. I guess that's
why some
> of philips' competitors have a separate data flash for such usage.
The price
> point of the lpc21xx doesn't look so good for us, when you have to
tack on
> an extra $1+ for an external SPI flash device.
> 
> --
> Bryce Schober

Also flash update must be done in 16-byte chunks.  Anything less will
result in content corruption because of the way EDC is implemented on
the LPC family.

would it be possible for some alternative iap firmware to implement
non-blocking access?

On 5/10/06, jayasooriah <jayasooriah@...> wrote:
>
> --- In lpc2000@yahoogroups.com, "Bryce Schober" <bryce.schober@...> wrote:
> >
> > I just want to make sure that I'm reading this right before
> committing to
> > using a serial flash. It seems that the lpc21xx on-chip can't really
> be used
> > for eeprom emulation in real-time scenarios, since its sector erase
> takes
> > hundreds of milliseconds and is a blocking function. I guess that's
> why some
> > of philips' competitors have a separate data flash for such usage.
> The price
> > point of the lpc21xx doesn't look so good for us, when you have to
> tack on
> > an extra $1+ for an external SPI flash device.
> >
> > --
> > Bryce Schober
>
> Also flash update must be done in 16-byte chunks.  Anything less will
> result in content corruption because of the way EDC is implemented on
> the LPC family.
>
>
>
>
>
>  SPONSORED LINKS
>   Microcontrollers<http://groups.yahoo.com/gads?t=ms&k=Microcontrollers&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&c=3&s=69&.sig=c-HXthtbZy4TZbI3ib0PMg>
> Microprocessor<http://groups.yahoo.com/gads?t=ms&k=Microprocessor&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&c=3&s=69&.sig=ijt0SspWtjogcHCuFD0lUQ>  Intel
> microprocessors<http://groups.yahoo.com/gads?t=ms&k=Intel+microprocessors&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&c=3&s=69&.sig=WOZdpklkgHbXR5quAgrl5w>
>  ------------------------------
> YAHOO! GROUPS LINKS
>
>
>    -  Visit your group "lpc2000 <http://groups.yahoo.com/group/lpc2000>"
>    on the web.
>
>    -  To unsubscribe from this group, send an email to:
>     lpc2000-unsubscribe@yahoogroups.com<lpc2000-unsubscribe@yahoogroups.com?subject=Unsubscribe>
>
>    -  Your use of Yahoo! Groups is subject to the Yahoo! Terms of
>    Service <http://docs.yahoo.com/info/terms/>.
>
>
>  ------------------------------
>



--
Bryce Schober


[Non-text portions of this message have been removed]

As per my understanding you can continue to service interrupts during
the IAP erase. The ISR needs to live in SRAM and must not access flash.

Tom

--- In lpc2000@yahoogroups.com, "Bryce Schober" <bryce.schober@...> wrote:
>
> I just want to make sure that I'm reading this right before
committing to
> using a serial flash. It seems that the lpc21xx on-chip can't really
be used
> for eeprom emulation in real-time scenarios, since its sector erase
takes
> hundreds of milliseconds and is a blocking function. I guess that's
why some
> of philips' competitors have a separate data flash for such usage.
The price
> point of the lpc21xx doesn't look so good for us, when you have to
tack on

> an extra $1+ for an external SPI flash device.
> 
> --
> Bryce Schober
> 
> 
> [Non-text portions of this message have been removed]
>

Bryce Schober wrote:
> I just want to make sure that I'm reading this right before committing to
> using a serial flash. It seems that the lpc21xx on-chip can't really be used
> for eeprom emulation in real-time scenarios, since its sector erase takes
> hundreds of milliseconds and is a blocking function. I guess that's why some
> of philips' competitors have a separate data flash for such usage. The price
> point of the lpc21xx doesn't look so good for us, when you have to tack on
> an extra $1+ for an external SPI flash device.

I have used program flash on other micros for data eeprom before but I 
really don't like doing it as I increase the risk that the program could 
become corrupted due to a software bug. In which case I wished that I 
had just spent the buck.

When it comes to the LPC21xx I just would not even consider doing this 
at all and I would rather spend the buck on a safe n sure serial eeprom. 
However, that being said, I do backup blocks of data from RAM but this 
is usually done only infrequently.

When considering the internal flash for eeprom use, the limits of 16 
bytes at a time for programming and need for large sector erase, vpp 
generator start-up time etc should be sounding alarm bells. The voice in 
your head should be going "NO WAY".

Anyway, that's just my2cents,
*Peter*

--- In lpc2000@yahoogroups.com, "lpc2100" <lpc2100@...> wrote:
>
> As per my understanding you can continue to service interrupts during
> the IAP erase. The ISR needs to live in SRAM and must not access flash.
> 
> Tom

You theoretically can provided you can stop watchdog from firing.

--- In lpc2000@yahoogroups.com, Peter Jakacki <peterjak@...> wrote:

> When considering the internal flash for eeprom use, the limits of 16 
> bytes at a time for programming and need for large sector erase, vpp 
> generator start-up time etc should be sounding alarm bells. The voice
> in your head should be going "NO WAY".
> 
> Anyway, that's just my2cents,
> *Peter*

Hmm... where were you when I was trying to explain to this forum why
the EEPROM example from Philips was well ... not a good idea :)

To be fair to Philips, they generally describe the on-board flash 
as "program memory", and it's clear that this is very much its 
intended purpose.

It is kind of tempting though to use it as general purpose EEPROM, 
but as Peter points out it's a long way from this.

In our case it was a straightforward tradeoff: the cost of 
developing and testing usable and robust EEPROM emulation software 
far exceeded the cost of the external EEPROM (apart from concerns 
about lifetime, as we write quite often). In the general case, I 
think your volumes would have to be very high (100k+ ?) before it 
would make much sense.

In some specific cases (e.g. writing a very occasional block of data 
that rarely or never gets erased) it can make sense, though: it's 
really a matter of looking at particular requirements and the time 
and effort required to implement them.

Brendan

--- In lpc2000@yahoogroups.com, Peter Jakacki <peterjak@...> wrote:
>
> Bryce Schober wrote:
> I have used program flash on other micros for data eeprom before 
but I 
> really don't like doing it as I increase the risk that the program 
could 
> become corrupted due to a software bug. In which case I wished 
that I 
> had just spent the buck.
> 
> When it comes to the LPC21xx I just would not even consider doing 
this 
> at all and I would rather spend the buck on a safe n sure serial 
eeprom. 
> However, that being said, I do backup blocks of data from RAM but 
this 
> is usually done only infrequently.
> 
> When considering the internal flash for eeprom use, the limits of 
16 
> bytes at a time for programming and need for large sector erase, 
vpp 
> generator start-up time etc should be sounding alarm bells. The 
voice in 
> your head should be going "NO WAY".
>

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

> To be fair to Philips, they generally describe the on-board flash 
> as "program memory", and it's clear that this is very much its 
> intended purpose.

The two version EE demo that Philips published must be rubbish then.

On 5/10/06, jayasooriah <jayasooriah@...> wrote:
>
>  You theoretically can provided you can stop watchdog from firing.

Wouldn't the IAP functions have to be doing that anyway?

-- 
Bryce Schober

--- In lpc2000@yahoogroups.com, "jayasooriah" <jayasooriah@...> wrote:
>
> --- In lpc2000@yahoogroups.com, "brendanmurphy37"
> <brendanmurphy37@> wrote:
> 
> > To be fair to Philips, they generally describe the on-board flash 
> > as "program memory", and it's clear that this is very much its 
> > intended purpose.
> 
> The two version EE demo that Philips published must be rubbish then.
>

Well,

as there are different requirements for non-volatile data memory these
examples can be very usefull or if it does not work for your needs
(btw. what are your needs?) then just use an external EE. 

We need to update a few parameters based on environmental conditions
"every now and then" which could be once a day or once a month. The
Flash is big enough to host these additional 32 bytes of NV-data and I
consider it valuable input knowing HOW to do this based on the Flash
implementation. 

If you ask me whether the implementation is optimized for EEPROM,
absolutely not!  But asking myself if I want to spend the extra 50
cent for each board to have an optimized version, even less so!

The risk of overwriting program code caused by a software error as
mentioned by another member is very real though. This could be the
single most important reason why not to "abuse" the the program memory
for data storage.

Calling the detailed information how to store data in the program
memory "rubbish" seems more than just a little out of place. 

Bob

--- In lpc2000@yahoogroups.com, "Bryce Schober" <bryce.schober@...> wrote:
>
> On 5/10/06, jayasooriah <jayasooriah@...> wrote:
> >
> >  You theoretically can provided you can stop watchdog from firing.
> 
> Wouldn't the IAP functions have to be doing that anyway?
> 
> -- 
> Bryce Schober

They do not.  Note the IAP function is not a system or kernel call
that typically makes minimal assumptions about the caller's environments.

It is just a procedure call, and there are lots of side effects you
tend to get trapped by if you do not actually look at how this is done
in the booot loader.

Jaya

--- In lpc2000@yahoogroups.com, "lpc2100_fan" <lpc2100_fan@...> wrote:
>
> --- In lpc2000@yahoogroups.com, "jayasooriah" <jayasooriah@> wrote:
> >
> > --- In lpc2000@yahoogroups.com, "brendanmurphy37"
> > <brendanmurphy37@> wrote:
> > 
> > > To be fair to Philips, they generally describe the on-board flash 
> > > as "program memory", and it's clear that this is very much its 
> > > intended purpose.
> > 
> > The two version EE demo that Philips published must be rubbish then.
> >
...
> 
> Calling the detailed information how to store data in the program
> memory "rubbish" seems more than just a little out of place. 
> 
> Bob

You missed my point as to what I was referring to as "rubbish".

It is very clear from the EE demo example, and the statements made by
Philips that it is selling its on-chip flash as a viable alternative
to EEPROM.

*If* the claim that Philips describes on-chip flash as "program
memory" and not as a viable alternative to EEPROM is true, *then* the
release of not one but two version of EE demo must be rubbish.

Jaya

Do you work for the government?  I'm just curious because anyone that has so much free time on their hands that they can keep arguing over menucia must work for the public sector.  I have used the internal Flash memory for parameter storage (EEPROM use).  It works fine.  If it doesn't work for you, then use an EEPROM.  Is there more to be said than that?  Do you just have so much free time on your hands that you want to spend all of your time complaining about what is or isn't in a Philips document or how they phrase it?  Geez,  give me a break. Don't you have anything better to do with your time?

Chris.

  ----- Original Message ----- 
  From: jayasooriah 
  To: lpc2000@yahoogroups.com 
  Sent: Thursday, May 11, 2006 5:46 PM
  Subject: [lpc2000] Re: IAP Blocking for 400ms?


  --- In lpc2000@yahoogroups.com, "lpc2100_fan" <lpc2100_fan@...> wrote:
  >
  > --- In lpc2000@yahoogroups.com, "jayasooriah" <jayasooriah@> wrote:
  > >
  > > --- In lpc2000@yahoogroups.com, "brendanmurphy37"
  > > <brendanmurphy37@> wrote:
  > > 
  > > > To be fair to Philips, they generally describe the on-board flash 
  > > > as "program memory", and it's clear that this is very much its 
  > > > intended purpose.
  > > 
  > > The two version EE demo that Philips published must be rubbish then.
  > >
  ...
  > 
  > Calling the detailed information how to store data in the program
  > memory "rubbish" seems more than just a little out of place. 
  > 
  > Bob

  You missed my point as to what I was referring to as "rubbish".

  It is very clear from the EE demo example, and the statements made by
  Philips that it is selling its on-chip flash as a viable alternative
  to EEPROM.

  *If* the claim that Philips describes on-chip flash as "program
  memory" and not as a viable alternative to EEPROM is true, *then* the
  release of not one but two version of EE demo must be rubbish.

  Jaya





  SPONSORED LINKS Microcontrollers  Microprocessor  Intel microprocessors  


------------------------------------------------------------------------------
  YAHOO! GROUPS LINKS 

    a..  Visit your group "lpc2000" on the web.
      
    b..  To unsubscribe from this group, send an email to:
     lpc2000-unsubscribe@yahoogroups.com
      
    c..  Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. 


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



[Non-text portions of this message have been removed]

Same here.  I partition the lpc internal flash into different groups 
based on its sector numbers. I then store different non-volatile 
variables (product serial numer, etc) and run time program into the 
flash at different sectors. When my program starts, it jumps to the 
starting address of the run time program and executes out from 
flash. The run time program is upgradeable via IAP when there is 
request from external host. I used the MAM feature and the program 
runs fast enough out from flash. So far, I am quite happy with the 
internal Flash of LPC and its IAP. 

regards,
Tim
http://www.embeddedhub.com/



--- In lpc2000@yahoogroups.com, <sig5534@...> wrote:
>
> Do you work for the government?  I'm just curious because anyone 
that has so much free time on their hands that they can keep arguing 
over menucia must work for the public sector.  I have used the 
internal Flash memory for parameter storage (EEPROM use).  It works 
fine.  If it doesn't work for you, then use an EEPROM.  Is there 
more to be said than that?  Do you just have so much free time on 
your hands that you want to spend all of your time complaining about 
what is or isn't in a Philips document or how they phrase it?  
Geez,  give me a break. Don't you have anything better to do with 
your time?
> 
> Chris.
> 
> 
> 
> 
>   ----- Original Message ----- 
>   From: jayasooriah 
>   To: lpc2000@yahoogroups.com 
>   Sent: Thursday, May 11, 2006 5:46 PM
>   Subject: [lpc2000] Re: IAP Blocking for 400ms?
> 
> 
>   --- In lpc2000@yahoogroups.com, "lpc2100_fan" <lpc2100_fan@> 
wrote:
>   >
>   > --- In lpc2000@yahoogroups.com, "jayasooriah" <jayasooriah@> 
wrote:
>   > >
>   > > --- In lpc2000@yahoogroups.com, "brendanmurphy37"
>   > > <brendanmurphy37@> wrote:
>   > > 
>   > > > To be fair to Philips, they generally describe the on-
board flash 
>   > > > as "program memory", and it's clear that this is very much 
its 
>   > > > intended purpose.
>   > > 
>   > > The two version EE demo that Philips published must be 
rubbish then.
>   > >
>   ...
>   > 
>   > Calling the detailed information how to store data in the 
program
>   > memory "rubbish" seems more than just a little out of place. 
>   > 
>   > Bob
> 
>   You missed my point as to what I was referring to as "rubbish".
> 
>   It is very clear from the EE demo example, and the statements 
made by
>   Philips that it is selling its on-chip flash as a viable 
alternative
>   to EEPROM.
> 
>   *If* the claim that Philips describes on-chip flash as "program
>   memory" and not as a viable alternative to EEPROM is true, 
*then* the
>   release of not one but two version of EE demo must be rubbish.
> 
>   Jaya
> 
> 
> 
> 
> 
>   SPONSORED LINKS Microcontrollers  Microprocessor  Intel 
microprocessors  
> 
> 
> -------------------------------------------------------------------
-----------
>   YAHOO! GROUPS LINKS 
> 
>     a..  Visit your group "lpc2000" on the web.
>       
>     b..  To unsubscribe from this group, send an email to:
>      lpc2000-unsubscribe@yahoogroups.com
>       
>     c..  Your use of Yahoo! Groups is subject to the Yahoo! Terms 
of Service. 
> 
> 
> -------------------------------------------------------------------
-----------

> 
> 
> 
> [Non-text portions of this message have been removed]
>

--- In lpc2000@yahoogroups.com, "brendanmurphy37" 
<brendanmurphy37@...> wrote:
>
> 
> To be fair to Philips, they generally describe the on-board flash 
> as "program memory", and it's clear that this is very much its 
> intended purpose.
> 

To clarify: the quote used above comes from the LPC213x User Manual, 
under the Features list (section 1.2). It's also in plenty of other 
Philips documentation and promotional material.

It never occured to me that the statement above was in any way 
controversial, or would need its source cited.

As Philips, I and others have pointed out, the program memory can 
also be used for non-volatile data storage by an application. As 
we've also all pointed out, you need to look carefully at your exact 
requirements when used for this purpose as the flash is far from 
optimised for this usage; it is not suitable as a straight 
replacement for a generic EEPROM. The 400ms erase time is just one 
example of this.

I did not believe, nor do I now believe, that this is in any way 
controversial. 

Anyone trying to manufacture controversy over this issue is wasting 
their own and, more importantly, other people's time.

I have nothing further to state on the topic, and recommend to 
others to take the same approach.  

Brendan.