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!
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."
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?
Thanks
Girish
Working around LPC flash updates and endurance
Started by ●June 29, 2009
Reply by ●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
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 ●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!!!
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 (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
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!!!
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 (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 ●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
>
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 ●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
>
> 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 ●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
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 ●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
>
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 ●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 .
>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 ●June 29, 20092009-06-29
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 .
>
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 ●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
>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
