LPC Flash writing time

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Dore on Fri Dec 13 03:17:35 MST 2013
Hi,

I am using LPC1114FHI33/302 controller with the LPC Xpresso IDE.
I had written my erase flash routine is here as follows:

unsigned long int ulnCommand[5] = {0};

ulnCommand[0] = 52;
ulnCommand[1] = 1;
ulnCommand[2] = 1;
ulnCommand[3] = (48000000) / 1000; /* Clock frequency in KHz */

ulnOCommand = CallIAP(ulnCommand);

My operating frequency is 48 MHz. The clock frequency given for the internal flash is 48MHz with this I am able to pass through the execution in 100 msec time as mentioned in the datasheet. Is it possible to exceed that? For ex.,

unsigned long int ulnCommand[5] = {0};

ulnCommand[0] = 52;
ulnCommand[1] = 1;
ulnCommand[2] = 1;
ulnCommand[3] = (48000000); /* Clock frequency in KHz */

ulnOCommand = CallIAP(ulnCommand);

With this I am able to execute the erase sequence in 8 msec time. Is this a reliable way?

lpcware · ‎06-15-2016

Content originally posted in LPCWare by TheFallGuy on Mon Dec 16 06:26:54 MST 2013

Quote:
And I bet you'll lose this bet. Several flash tests are showing that this flash is better than specs are showing...

NXP are going to publish figures that they can guarantee across every chip they manufacture i.e. worst-case. On a wafer, the chips on the edges are typically worst-case. Would you want to be your production run on ALWAYS getting chips that are not worst case? Perhaps if your production run is hundreds, you *may* get away with it. If your production run is thousands, I know what I would choose.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by R2D2 on Mon Dec 16 06:23:07 MST 2013

Quote: Dore
Is there any other way where I can possibly reduce the erase time?

No. Erasing with 'correct' clock settings costs you 100ms. If you want to be faster, use a fast external EEPROM (FRAM).

lpcware · ‎06-15-2016

Content originally posted in LPCWare by TheFallGuy on Mon Dec 16 06:22:14 MST 2013
If NXP tell you what the time is, I can't see how you can do it any quicker.

Perhaps you need to re-think your algorithm

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Dore on Mon Dec 16 06:07:45 MST 2013
Is there any other way where I can possibly reduce the erase time?
I can spend max of around 10 msec for the internal flash erase as per my application. Is it possible to achieve this with LPC1114???

lpcware · ‎06-15-2016

Content originally posted in LPCWare by R2D2 on Sun Dec 15 16:41:48 MST 2013

Quote: TheFallGuy
... but I bet most of them will meet the spec, and no more.

And I bet you'll lose this bet. Several flash tests are showing that this flash is better than specs are showing...

lpcware · ‎06-15-2016

Content originally posted in LPCWare by TheFallGuy on Sun Dec 15 14:54:14 MST 2013
I would guess that you are being lucky with your chip. If you want it to work reliably, in production, over thousands of parts, you need to obey the constraints of the chip. They have been characterised to work reliably in production. Some will be better, but I bet most of them will meet the spec, and no more.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Dore on Sun Dec 15 11:15:33 MST 2013
Yes its working till now.
I am also doing the Flash blank check after erasing and that also gets successful.!
Infact I am wondering how we can fake the datasheet!
And how the erasing gets completed for the frequency given more than the system clock, theoretically it is impossible, but practically it worked.!

Again not sure about the reliability which I may have to test exclusively.

For my application I may need it hardly few times for calibration storage which may happen once in 6 months. But writing should be reliable.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by R2D2 on Fri Dec 13 21:32:49 MST 2013
With reducing erasing time you'll get problems to erase your flash. With increasing program / erase cycles there's more time required to erase the flash. Of course you can avoid problems if you increase erasing time again after receiving blank check errors.
With your shortened erase time you'll probably reduce endurance to 1/3 (from 1400E3 to 400E3 p/e cycles).
This are no official results, so I would suggest to do a few own tests with your approach...

lpcware · ‎06-15-2016

Content originally posted in LPCWare by R2D2 on Fri Dec 13 12:25:46 MST 2013

Quote: Dore
...I am able to execute the instruction faster than usual.

And is it still working?

Did you reset flash bits before erasing them?

Are you blank checking after erasing?

How often did you do all this?

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Dore on Fri Dec 13 12:15:41 MST 2013
Yes,

I was able to erase the flash with the approach two in which I am trying to use 48000000 directly without any divided by 1000.
I am not exactly sure why this value comes into picture. And by just simply increasing the value I am able to execute the instruction faster than usual.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by R2D2 on Fri Dec 13 05:10:25 MST 2013

Quote: Dore
Is this a reliable way?

Datasheet shows a min. erase time (ter) of 95ms. So I don't think that's a reliable approach.

But perhaps you want to make your own wear out test and compare the results with this results:

Quote:
LPC11C14-Sector 7: Blank Error after 1437980 cycles

See. http://www.lpcware.com/content/forum/real-iap-wear-out-data