Question on flash memory and absolute addresses.

[lpcware]

Content originally posted in LPCWare by Izzy Weird on Wed Aug 24 19:51:20 MST 2011
I realize production code might not want to use LPC flash for non-volatile storage, given the 10,000 cycle wear out spec.

But for simple demo code I would like to use an NXP LPC1112 DALI slave example that was originally built on the Keil tools.  It would appear that Code Red has a different way to situate things at absolute addresses as it gives me a warning that it does not recognize "at" in the below code:

const BYTE POWER_ON_LEVEL    __attribute__((at(0x00003000))) = 254;
const BYTE SYS_FAILURE_LEVEL __attribute__((at(0x00003001))) = 254;
const BYTE MIN_LEVEL         __attribute__((at(0x00003002))) = PHY_MIN_LEVEL;
const BYTE MAX_LEVEL         __attribute__((at(0x00003003))) = 254;
const BYTE FADE_RATE         __attribute__((at(0x00003004))) = 7;
const BYTE FADE_TIME         __attribute__((at(0x00003005))) = 0;
const BYTE FADE_TIME         __attribute__((at(0x00003005))) = 4;
const BYTE RANDOM_ADDRESS_H  __attribute__((at(0x00003006))) = 0xFF;
const BYTE RANDOM_ADDRESS_M  __attribute__((at(0x00003007))) = 0xFF;
const BYTE RANDOM_ADDRESS_L  __attribute__((at(0x00003008))) = 0xFF;
const BYTE SHORT_ADDRESS     __attribute__((at(0x00003009))) = 0xFF;
const BYTE SHORT_ADDRESS     __attribute__((at(0x00003009))) = 0x11;
const BYTE GROUP_0_7         __attribute__((at(0x0000300A))) = 0;
const BYTE GROUP_8_15        __attribute__((at(0x0000300B))) = 0;
const BYTE SCENE[16]         __attribute__((at(0x0000300C))) = {255,255,255,255,255,255,255,255,
                                                                255,255,255,255,255,255,255,255};*/

There is a source file that appears to have all the IAP functionality and flash routines for an LPC1112.[B]

Is there a fairly simple way to make this work on LPCXpresso?  [/B](LPC1114)

[lpcware]

Content originally posted in LPCWare by Izzy Weird on Fri Aug 26 14:38:14 MST 2011

---

Quote: micrio
I would like to know the results of wearout testing on 10K parts.

Yes, my code does use round-robin leveling. I did not know the characteristics of what a wearout would look like. Would the error be "hard" or would it come and go?

Pete.

---

Well, Pete, this is (after all) destructive testing.  I sacrificed a prototype board to perform this test in the past.  To test more samples I guess one might use a test socket for the MCU.  My previous test was with an Atmel SAM7 ARM  part.  In this case the wear out did not appear permanent at first.  As I mentioned, I was able to do an average of 10k writes to the (now wornout) flash blocks before more bit errors in the 256 byte blocks.  The Atmel spec was 100k writes, but with the sample I tested I got an average of about 1 million writes before the first bit error.

If you are in business, and this is important for you to know, LPCXpresso boards are very inexpensive. I suppose you could wear a few of them out to find out. :D

I would be curious to hear the results of such a test.

[lpcware]

Content originally posted in LPCWare by micrio on Fri Aug 26 04:23:47 MST 2011

---

Quote: Izzy Weird
Thanks, Pete, for the linked thread. :cool: For a simple demo I was going to try to avoid avoiding wearout.

Two methods I have used in the past are round-robin leveling which I believe is similar to the method in your thread, and error detection with a switch to the next block. The first errors encountered upon wearout are likely to be one (or more) bit errors, and depending upon the technology the errors will favor going to either ones or zeros. A long word used at the beginning to validate the block is usually very reliable. The probability of being able to [B]invalidate[/B] a block at the threshold of wearout is extremely high. When the first bit error is detected, invalidate the current block and go to the next block.

I have done experiments actually wearing out flash to test the functions. The results were interesting (I did not test a large number of samples). An ARM part specifying 100k writes actually lasted through 800k to 1200k writes before a single bit error. Even using the worn out memory a second time typically got over 10k writes (average) before a bit error. YMMV

---

I would like to know the results of wearout testing on 10K parts.

Yes, my code does use round-robin leveling. I did not know the characteristics of what a wearout would look like. Would the error be "hard" or would it come and go?

Pete.

[lpcware]

Content originally posted in LPCWare by Izzy Weird on Thu Aug 25 09:50:22 MST 2011

---

Quote: whitecoe
Try doing a google for:

[FONT=Courier New][SIZE=2]" __attribute__((at" site:knowledgebase.nxp.com[/SIZE][/FONT]

This gives several hits, the latest of which was only yesterday ;)

You might also want to take a look at the sticky thread listed first on the forum...

                                      *** Searching the LPCXpresso Forum and Code Red's FAQ site ***

HTH :)

---

Thanks, the Google searches did not bear fruit, nor did some similar ones I tried yesterday.  But searching for[B] [I]__attribute__    at[/I][/B] on the Code Red site produced this excellent result:

http://support.code-red-tech.com/CodeRedWiki/PlacingData

I plan to use the Code Red search in the future, long before I try another Help search. :cool:

[lpcware]

Content originally posted in LPCWare by Izzy Weird on Thu Aug 25 09:36:46 MST 2011

---

Quote: micrio
With regard to flash wear-out; I posted some code that implemented a flash wear leveling mechanism. For me, it increased the wear-out limit from 10K to 1M cycles. That posting is here;
http://knowledgebase.nxp.com/showthread.php?t=2073

I did not get any response, so I don't know if people liked it, hated it, or ignored it. Anyway, you are welcome to use it.

Pete.

---

Thanks, Pete, for the linked thread. :cool:   For a simple demo I was going to try to avoid avoiding wearout.

Two methods I have used in the past are round-robin leveling which I believe is similar to the method in your thread, and error detection with a switch to the next block.  The first errors encountered upon wearout are likely to be one (or more) bit errors, and depending upon the technology the errors will favor going to either ones or zeros.  A long word used at the beginning to validate the block is usually very reliable.  The probability of being able to [B]invalidate[/B] a block at the threshold of wearout is extremely high.  When the first bit error is detected, invalidate the current block and go to the next block.

I have done experiments actually wearing out flash to test the functions.  The results were interesting (I did not test a large number of samples).  An ARM part specifying 100k writes actually lasted through 800k to 1200k writes before a single bit error.  Even using the worn out memory a second time typically got over 10k writes (average) before a bit error.  YMMV

[lpcware]

Content originally posted in LPCWare by Ex-Zero on Thu Aug 25 06:57:36 MST 2011

---

Quote: micrio
I did not get any response, so I don't know if people liked it, hated it, or ignored it.

---

Sorry, wasn't aware that you are expecting 'ignore' responses :eek:

So I ignored your work because I've bought this wonderful 24AA16T EEPROM (SOT23-5 package) :)

[lpcware]

Content originally posted in LPCWare by micrio on Thu Aug 25 06:01:12 MST 2011
With regard to flash wear-out; I posted some code that implemented a flash wear leveling mechanism. For me, it increased the wear-out limit from 10K to 1M cycles. That posting is here;
http://knowledgebase.nxp.com/showthread.php?t=2073

I did not get any response, so I don't know if people liked it, hated it, or ignored it. Anyway, you are welcome to use it.

Pete.

[lpcware]

Content originally posted in LPCWare by whitecoe on Thu Aug 25 01:52:05 MST 2011
Try doing a google for:

[FONT=Courier New][SIZE=2]" __attribute__((at" site:knowledgebase.nxp.com[/SIZE][/FONT]

This gives several hits, the latest of which was only yesterday ;)

You might also want to take a look at the sticky thread listed first on the forum...

  *** Searching the LPCXpresso Forum and Code Red's FAQ site ***

HTH :)