Reply by "sub...@aeolusdevelopment.com"●June 29, 20092009-06-29
Girish Pundlik Wrote >The upper limit of the LPC I2C interface is 400kHz,
that gives approximately 40K >bytes/second. A block of 256 bytes will actually
entail 280 bytes of transfer plus >delays between each block, that takes about 7.5
milliseconds. Add to it the 5 >milliseconds for each page write to complete. This
47.5 milliseconds is enough for >current mode of operation, it might prove too slow as
the system is developed further, >or I have to redefine the data structures to larger
sizes.
>
>SPI interface is much faster, but they are more expensive and take same time to write so >its not much of an improvement.
So use, FRAM. 20MHz write SPI interface and no write delay. No write
limitations (certainly as compared to flash or EE).
>Besides, I do not have all the SPI pins spare (used
for alternate functions), and >already have another device on the I2C bus. So if at
all I have to use any serial >memory, it would be I2C type.
That's what chip selects are for :)
Robert
--------------------------------
mail2web LIVE Free email based on Microsoft Exchange technology - http://link.mail2web.com/LIVE
I agree. I am making a product now that is also writing to the program flash as
a data store.
I can choose a dead time to write the data.
I am storing up 64b blocks, and writing to flash once a day.
However, on the next hw iteration I am going to add i2c eeprom for data. For
precisely what he said, its easier to dev the software and avoid interrupts and
possible fubar'ing the flash.
32kb i2c eeprom is < $1US.
--- In l..., Mike Harrison wrote: >
> On Mon, 29 Jun 2009 08:28:50 -0000, you wrote:
>
> >Hi Martin,
> >
> >It would make sense to use small size memory for cost concerns. So even using
a 32Kb memory, that has a page size of 32 bytes (Microchip 24AA32A) will need 8
iterations to write complete 256 byte data.
> >
> >The upper limit of the LPC I2C interface is 400kHz, that gives approximately
40K bytes/second. A block of 256 bytes will actually entail 280 bytes of
transfer plus delays between each block, that takes about 7.5 milliseconds. Add
to it the 5 milliseconds for each page write to complete. This 47.5 milliseconds
is enough for current mode of operation, it might prove too slow as the system
is developed further, or I have to redefine the data structures to larger
sizes.
> >
> >SPI interface is much faster, but they are more expensive and take same time
to write so its not much of an improvement. Besides, I do not have all the SPI
pins spare (used for alternate functions), and already have another device on
the I2C bus. So if at all I have to use any serial memory, it would be I2C
type.
> >
> >Using LPC internal flash is not a great leap either, but allows 1 millisecond
write for 256 byte block. Though I will have to erase the sector occasionally
which would take 400 milliseconds, this acceptable since one can always put up a
busy status for a short while, to prepare the system for continuous operation
for next 128 cycles, using the technique Mike suggested in the earlier post.
>
> I think you are really making life difficult for yourself by not using
external serial flash.
> Remember that when IAP commands are happenning, you cannot access program
flash, so you either need
> to put all your interrupt code in RAM or disable interrupts while writing. No
foreground code can be
> executing while you're waiting for IAP operations to complete.
> Non-availability of SPI pins is a total non-issue as SPI is trivial to
implement on any available IO
> pins (many of which can often be shared with other functions) in software.
Unlike I2C, SPI can run
> fast enough to not need to add much, if anything, in the way of delays to the
pin toggle operations.
> Remember also that with external serial flash, you can throw the data out to
SPI, and then carry on
> doing stuff while the flash chip is completing the write by itself.
> Serial flash is so cheap these days that you can generally afford to use
enough of it to not need to
> worry about endurance issues. Unless you are doing huge volumes, the cost of
the chip will easily be
> offset by your time dealing with the restrictions of using IAP .
>
Reply by Mike Harrison●June 29, 20092009-06-29
On Mon, 29 Jun 2009 08:28:50 -0000, you wrote:
>Hi Martin,
>
>It would make sense to use small size memory for cost concerns. So even using a
32Kb memory, that has a page size of 32 bytes (Microchip 24AA32A) will need 8
iterations to write complete 256 byte data.
>
>The upper limit of the LPC I2C interface is 400kHz, that gives approximately
40K bytes/second. A block of 256 bytes will actually entail 280 bytes of
transfer plus delays between each block, that takes about 7.5 milliseconds. Add
to it the 5 milliseconds for each page write to complete. This 47.5 milliseconds
is enough for current mode of operation, it might prove too slow as the system
is developed further, or I have to redefine the data structures to larger
sizes.
>
>SPI interface is much faster, but they are more expensive and take same time to
write so its not much of an improvement. Besides, I do not have all the SPI pins
spare (used for alternate functions), and already have another device on the I2C
bus. So if at all I have to use any serial memory, it would be I2C type.
>
>Using LPC internal flash is not a great leap either, but allows 1 millisecond
write for 256 byte block. Though I will have to erase the sector occasionally
which would take 400 milliseconds, this acceptable since one can always put up a
busy status for a short while, to prepare the system for continuous operation
for next 128 cycles, using the technique Mike suggested in the earlier post.
I think you are really making life difficult for yourself by not using external
serial flash.
Remember that when IAP commands are happenning, you cannot access program flash,
so you either need
to put all your interrupt code in RAM or disable interrupts while writing. No
foreground code can be
executing while you're waiting for IAP operations to complete.
Non-availability of SPI pins is a total non-issue as SPI is trivial to implement
on any available IO
pins (many of which can often be shared with other functions) in software.
Unlike I2C, SPI can run
fast enough to not need to add much, if anything, in the way of delays to the
pin toggle operations.
Remember also that with external serial flash, you can throw the data out to
SPI, and then carry on
doing stuff while the flash chip is completing the write by itself.
Serial flash is so cheap these days that you can generally afford to use enough
of it to not need to
worry about endurance issues. Unless you are doing huge volumes, the cost of the
chip will easily be
offset by your time dealing with the restrictions of using IAP .
Reply by Girish Pundlik●June 29, 20092009-06-29
Hi Martin,
It would make sense to use small size memory for cost concerns. So even using a
32Kb memory, that has a page size of 32 bytes (Microchip 24AA32A) will need 8
iterations to write complete 256 byte data.
The upper limit of the LPC I2C interface is 400kHz, that gives approximately 40K
bytes/second. A block of 256 bytes will actually entail 280 bytes of transfer
plus delays between each block, that takes about 7.5 milliseconds. Add to it the
5 milliseconds for each page write to complete. This 47.5 milliseconds is enough
for current mode of operation, it might prove too slow as the system is
developed further, or I have to redefine the data structures to larger sizes.
SPI interface is much faster, but they are more expensive and take same time to
write so its not much of an improvement. Besides, I do not have all the SPI pins
spare (used for alternate functions), and already have another device on the I2C
bus. So if at all I have to use any serial memory, it would be I2C type.
Using LPC internal flash is not a great leap either, but allows 1 millisecond
write for 256 byte block. Though I will have to erase the sector occasionally
which would take 400 milliseconds, this acceptable since one can always put up a
busy status for a short while, to prepare the system for continuous operation
for next 128 cycles, using the technique Mike suggested in the earlier post.
Thanks,
Girish
--- In l..., "mjames_doveridge" wrote: >
> --- In l..., "Girish Pundlik" wrote:
> >
> > Hello,
>
>
> >I need to update last event logs to non-volatile memory at least 300 times a
day.
>
> > Actually, the data to be logged is not more than 256 bytes,
>
> > I have considered using external serial memory, but that is too slow for my
application,
>
> ??
>
> 256*300/24/60/60 = 0.9 bytes/sec.
>
> Why is serial flash too slow? Obviously, the smallest, cheapest part is way
fast enough overall, so what is the problem?
>
> Rgds,
> Martin
>
Reply by Girish Pundlik●June 29, 20092009-06-29
Hi Mike,
Thanks for your comments.
>> I get 128 blocks * 10000 writes/block = 1280000
writes. Still a far cry from 20 million. At 300 writes/day, this gives you
4267 days, or 11.7 years. You must be using NEW math. :-)
My calculations were incorrect, I immediately corrected the post, dunno how you
got the older one. I based my calculations on writing 8K times (to allow for
tolerances) to a sector rather than 10K before switching to the next. So I get
8000 x 128 = 1024000 i.e. about 1 million cycles, 3413 days that is about 9
years.
I really like your idea:
"How about writing your 256 bytes multiple times within a sector before erasing
it? Or, write your 256 bytes to all locations in the 32K block you plan to use,
and then when full, start from the beginning erasing as you go. This way, you
likely wouldn't need to count writes at all."
A single 32K sector means 128 blocks of 256 bytes each, so the full 32K sector
will be erased every 128 writes, that could be repeated as many as 8000~10000
times! This gives the same results, 9~11 years of data storage.
I hope the LPC flash controller does not need any state information, and can
write a block even at next power on after the sector has been "prepared". If
not, preparing each sector again will reduce the available number of write
cycles significantly. It already used 300/128 = 2.4 erase cycles per day, add 2
more erase cycles per day to it after each power-up, it results in 2272 days of
reliable operation, around 6 years. Even that should be enough though.
Thanks a lot,
Girish
Reply by mjames_doveridge●June 29, 20092009-06-29
--- In l..., "Girish Pundlik" wrote: >
> Hello,
>I need to update last event logs to non-volatile
memory at least 300 times a day.
> Actually, the data to be logged is not more than 256
bytes,
> I have considered using external serial memory, but
that is too slow for my application,
??
256*300/24/60/60 = 0.9 bytes/sec.
Why is serial flash too slow? Obviously, the smallest, cheapest part is way
fast enough overall, so what is the problem?
Rgds,
Martin
Reply by Michael Anton●June 29, 20092009-06-29
Hello Girish,
See my comments inline.
Mike > -----Original Message-----
> From: l...
> [mailto:l...]On Behalf
> Of Girish Pundlik
> Sent: Monday, June 29, 2009 12:06 AM
> To: l...
> Subject: [lpc2000] Working around LPC flash updates and endurance
> Hello,
>
> I am using a LPC2132 controller for a project. I need to
> update last event logs to non-volatile memory at least 300
> times a day. To reduce cost, I am planning to use half of the
> the onchip program flash memory.
>
> However, I am concerned about longevity of this module, as
> 10K erase cycles gives us only 333 days of reliable memory.
Umm, I think you meant to say 33.3 days at 300 writes/day.
>
> Actually, the data to be logged is not more than 256 bytes,
> so I was thinking if I could rotate the blocks around.
> Basically, I would record the number of writes in the block
> itself, and switch to next block after a safe limit, say 8000
> writes has been reached. I will have to scan for the last
> active block at every bootup, but that is okay. This will
> enable me to use each 256 byte block 8000 times, multiplied
> by 128 such blocks (in 32K flash) giving me a tenure of
> 2048000, about 20 million write cycles that will make this
> module last for as long as 18 years!
I get 128 blocks * 10000 writes/block = 1280000 writes. Still
a far cry from 20 million. At 300 writes/day, this gives you
4267 days, or 11.7 years. You must be using NEW math. :-)
I really think that serial EEPROM or flash would be better.
If you think it is slow, you haven't looked at the speed spec.
for the LPC series. I can't find it just now, but I'm sure
that I read that a sector erase can take up to 400ms to
complete.
>
> I read this note from nxp:
>
> http://www.embeddedrelated.com/groups/lpc2000/show/2681.php
>
> It says the only requirement is to update at least 16 (or
> multiples of 16) bytes at a time. However, since we need to
> "prepare" and "erase" the sector each time, I suspect
> critical areas of the sector will be used every time I write
> 256 bytes. So, even if I am writing only 256 bytes, at
> different locations within the same sector, I will
> essentially be using the same, complete sector for all these writes.
>
> Thus, the sector itself may not be reliably used for more
> than documented number of 10K cycles.
>
> Is there any way one can restrict read/write operations to
> small blocks within a sector without affecting the critical
> sector areas?
>
> The article says:
>
> "This means every 4K-aligned area can only be written to a maximum of
> 16 times before it must be erased."
Note that the Copy RAM to flash IAP command will only let
you write in multiples of 256 bytes. This is why NXP claims
you can only write 16 times to a 4K sector (256 * 16 = 4K).
> And further, it says:
>
> "You don't need to erase and re-write the whole sector but you
> must update a minimum of 128-bits at a time"
How about writing your 256 bytes multiple times within a
sector before erasing it? Or, write your 256 bytes
to all locations in the 32K block you plan to use, and
then when full, start from the beginning erasing as you go.
This way, you likely wouldn't need to count writes at all.
Since you are using a LPC2132, the last half of memory is a
single sector, so I would think you would want to write to all
of it, before erasing it.
>
> So, can I, or can I not use the memory in small 256 blocks
> without erasing and rewriting the whole sector? Has anybody
> experimented with using flash memory in such a way?
I certainly cannot see why you couldn't write in 256 byte blocks
to a sector. The IAP routines allow that, so it should be ok.
>
> Thanks
>
> Girish
>
Reply by Girish Pundlik●June 29, 20092009-06-29
Hello,
I am using a LPC2132 controller for a project. I need to update last event logs
to non-volatile memory at least 300 times a day. To reduce cost, I am planning
to use half of the the onchip program flash memory.
However, I am concerned about longevity of this module. The LPC documents
mention 10K (page 6 of UM10120) and 100K (page 13 of LPC2131_32_34_36_38) at
different places. Even 100K erase cycles gives us only 333 days of reliable
memory. Using the number 10K gives even worse, only 33 days of reliable
memory.
Actually, the data to be logged is not more than 256 bytes, so I was thinking if
I could rotate the blocks around. Basically, I would record the number of writes
in the block itself, and switch to next block after a safe limit, say 8000
writes has been reached. I will have to scan for the last active block at every
bootup, but that is okay. This will enable me to use each 256 byte block 8000
times, multiplied by 128 such blocks (in upper 32K flash) giving me a tenure of
1024000, about 1 million write cycles that will make this module last for as
long as 9 years! And if it is indeed 100K cycles, switching blocks after 95000
writes makes this module last for 12160000, 12 million! And that gives about 111
years!!!
It says the only requirement is to update at least 16 (or multiples of 16) bytes
at a time. However, since we need to "prepare" and "erase" the sector each time,
I suspect critical areas of the sector will be used every time I write 256
bytes. So, even if I am writing only 256 bytes, at different locations within
the same sector, I will essentially be using the same, complete sector for all
these writes.
Thus, the sector itself may not be reliably used for more than documented number
of 10K (or 100K) cycles.
Is there any way one can restrict read/write operations to small blocks within a
sector without affecting the critical sector areas?
The article says:
"This means every 4K-aligned area can only be written to a maximum of 16 times
before it must be erased."
And further, it says:
"You don't need to erase and re-write the whole sector but you must update
a minimum of 128-bits at a time"
So, I am not sure is I can use the memory in small 256 blocks without erasing
and rewriting the whole sector. Has anybody experimented with using flash memory
in such a way?
I have considered using external serial memory, but that is too slow for my
application, while a battery backed nvRAM is too expensive.
As far as IAP is concerned, is there any known low level access mechanism to use
(erase and program) the memory on row basis rather than sector basis?
I am sure resolving this issue will help a lot of people with similar
requirements.
Thanks,
Girish
Reply by Girish Pundlik●June 29, 20092009-06-29
Addendum:
I have considered using external serial EEPROM that will give 1M write cycles,
but is too slow for the purpose, while a battery backed nvRAM would be too
expensive.
Considering the LPC IAP routines, do I need to go into lower level flash access,
to get around sector erasing?
Thanks,
Girish
Reply by Girish Pundlik●June 29, 20092009-06-29
Hello,
I am using a LPC2132 controller for a project. I need to update last event logs
to non-volatile memory at least 300 times a day. To reduce cost, I am planning
to use half of the the onchip program flash memory.
However, I am concerned about longevity of this module, as 10K erase cycles
gives us only 333 days of reliable memory.
Actually, the data to be logged is not more than 256 bytes, so I was thinking if
I could rotate the blocks around. Basically, I would record the number of writes
in the block itself, and switch to next block after a safe limit, say 8000
writes has been reached. I will have to scan for the last active block at every
bootup, but that is okay. This will enable me to use each 256 byte block 8000
times, multiplied by 128 such blocks (in 32K flash) giving me a tenure of
2048000, about 20 million write cycles that will make this module last for as
long as 18 years!
It says the only requirement is to update at least 16 (or multiples of 16) bytes
at a time. However, since we need to "prepare" and "erase" the sector each time,
I suspect critical areas of the sector will be used every time I write 256
bytes. So, even if I am writing only 256 bytes, at different locations within
the same sector, I will essentially be using the same, complete sector for all
these writes.
Thus, the sector itself may not be reliably used for more than documented number
of 10K cycles.
Is there any way one can restrict read/write operations to small blocks within a
sector without affecting the critical sector areas?
The article says:
"This means every 4K-aligned area can only be written to a maximum of
16 times before it must be erased."
And further, it says:
"You don't need to erase and re-write the whole sector but you
must update a minimum of 128-bits at a time"
So, can I, or can I not use the memory in small 256 blocks without erasing and
rewriting the whole sector? Has anybody experimented with using flash memory in
such a way?