MCF52259 and flash writing / erasing

[LordMark]

Hi everyone. I'm working on a project of mine and using a board based upon MCF52259. I need to write some variables into the flash memory and I have two questions for you:

1) I read the application note AN3521 about flash programming on MCF5223X which is similar to MCF5225X. It says that accesses to flash memory should be done from RAM and provides a very good example code for doing that. Well, I tried to write and erase words and pages of the flash directly from the flash itself and it works fine at all. Is MCF5225X different from MCF5223X?

2) I successfully succeded in writing datas into the flash. Now I need to write some double type variables into flash. The program command is only for 32-bit word data. Do you have any suggestions or ideas? 

Thanks in advance,

best regards and happy new year

Marco.

[LordMark]

Infact from now on I'll always access flash from RAM  

[geoffW]

Hi

Interesting thread, but I am finding it very tough to get an understanding of how the flash works on the MCF52259.

The manual is very poor on describing how the flash memory is arranged, for example how many blocks are there in the 52259, so far one poster in here reckons 2, whilst another one reckoned 4  ?

It seems clear that if you stick to Freescale's recommendation you can not execute code from a flash "chunk" whilst trying to erase or program from that same "chunk".

But what is a "chunk" defined as ?  Is it a logical block, or a physical block, or is it a sector ?

A clear memory map diagram that shows how the logical and physical block are arranged (including offsets and  sizes) and how they are subdivided into sectors would be really helpful I think. Any volunteers to clarify this please ?

 Regards Geoff

[mjbcswitzerland]

Hi

You have indeed hit the nail on the head.

There are a few simple rules that need to be followed, but the rules are simply not absolutely clear and sometimes contradicting.

1) CFM FLASH has "physical blocks" and "logical blocks" (whereby Logical blocks are constructed from physical blocks - by interleaving them). Probably this is of more interest to chip designers and physisists that programmers.
2) "logical blocks" are divided into "logical pages"
3) "Logical pages" are usually 2k in size on the V2 devices (exception being the M522X which has 4k "logical page" size). {This is sometimes also called a sector}

The user manuals are clear on the point. Quote: "It is not possible to read from any flash logical block while the same logical block is being erased". Note that from 3) this is not the 2k or 4k "logical page" but the larger "logical block". The actual size of a logical block and how many there may be in a particular device is however not clear and the subject of some speculation - results of peoples tests suggest that it be mayby 128k in some chips but possibly larger (or smaller) in others since it is sometimes/often physically possible to run code from one area of FLASH and program other areas - since the manuals clearly state that it is not possible in the same logical block (which would exclude also logical pages since these are a sub-block) it follows that it is probably normal that different logical blocks will work (whatever the size may turn out to be) [Based on the fact that these are not specifically forbidden].

Unfortunately other sources with official character either state that it should never be possible, so should never be used anyway; or state that "The true limitation here is the logical page (2 kBytes). It is not possible to read instructions from the CFM logical page (2kB) while the same logical page is being programmed/erased/verified" which contradicts the user's manuals and also even overwrites the more restrictive "logical block" theory, which otherwise probably makes the most sense. {note that 2k is also chip specific and so not general, as shown by the M5225x. However the terminology used is exact in that it does specifically state "logical pages", backed up with a realistic typical "logical page" size - it is certainly not a typo}.

It would be nice to know what logical block sizes are in each device but the fact is that there is also no uncontradicted statement that any use of then (even if known) is recommended to be exploited:
Compare Quotes:
from FAQ-27893 "there is no problem to program/erase/verify a CFM logical page when instructions are fetched from another CFM logical pages" {referenced clearly to "logical pages"}
from this thread "Technically, according to the designers, you should not be able to erase one block of flash while running from another." {referenced to an undefined "block" but probably referring to "logical blocks" (with open question-mark) }

I would conclude that the only real way to be absolutely sure, based on existing literature, is to avoid programming any FLASH while the code is running in 'any' areas of FLASH on the same chip. If new literature becomes available which unequivocally revokes other information in existing literature as being either misleading, incorrect or no longer applicable to specified parts then I would also start actively exploiting these capabilities where of advantage.

As shown above it is easy to mix up the various definitions used, with nasty consequences. Any new statement would also need to be very exact in its wording too, to ensure that it doesn't make things even worst..... A designer with a lawyer's, or possibly accountant's background may be best qualified... :smileywink:

Regards

Mark

PS. I do hope that I didn't make any typos above. One does really have to be very careful with the wording...

[TomE]

---

mjbcswitzerland wrote:

Hi

You have indeed hit the nail on the head.

There are a few simple rules that need to be followed, but the rules are simply not absolutely clear and sometimes contradicting.

---

Freescale may be using different "Macrocell implementations" in different chips in the same family, and very likely different between families (51, 52 etc).

These things change as the production processes (the "shrink level") changes. That may explain some of the documentation problems.

[scifi]

Regarding incremental programming of flash, here is the answer of Freescale Support:

Yes, ColdFire CFM module supports  incremental programming.
You can do ERASE -> PROGRAM value -> PROGRAM 0x00000000 with ColdFire CFM.
In fact that's all flash's basic principle.
Unfortunately, we do not have info that  incremental programming affects flash durability and data retention.
ColdFire Flash durability and data retention data could be found at related chip datasheet.
MCF52259 as an example,
Maximum number of guaranteed program/erase cycles before failure is 10000 cycles (A program/erase cycle is defined as switching the bits from 1 → 0 → 1)
Data retention at average operating temperature of 85°C is 10 years.

Basically, incremental programming works, but how it affects flash durability and data retention is unknown.

[TomE]

---

scifi wrote:

Regarding incremental programming of flash, here is the answer of Freescale Support:

Yes, ColdFire CFM module supports  incremental programming.
You can do ERASE -> PROGRAM value -> PROGRAM 0x00000000 with ColdFire CFM.
In fact that's all flash's basic principle ...

Basically, incremental programming works, but how it affects flash durability and data retention is unknown.

---

But not possibly the way you may expect without further clarification.

Quoting from another forum pointed to in this thread:

Mark Butcher wrote:

The following shows that such discussions are not restricted to the Freescale parts: http://www.luminarymicro.com/component/option,com_joomlaboard/Itemid,92/func,view/id,7594/catid,5/

That forum contains the following that Mark might have being referring to:

Re:LM3S9BXX FLASH use in comparison to LM3S6965

Hi Mark,
From the LM3S9B96 data sheet:

Important: To ensure proper operation, two writes to the same word must be separated by an
ERASE. The following two sequences are allowed:
■ ERASE -> PROGRAM value -> PROGRAM 0x0000.0000
■ ERASE -> PROGRAM value -> ERASE
The following sequence is NOT allowed:
■ ERASE -> PROGRAM value -> PROGRAM value

Have you been following this process?
Sue

In the above description, FOR THOSE PARTS (and not necessarily the Freescale ones), one reading of the above is that you only get to program a value ONCE. You can't go "0xFF, 0xFE, 0xFC, 0xF0, 0xF0, but can only go "0xFF, 0xnn, 0x00".

The above description fom "TI Sue" almost EXACTLY MATCHES the one forwarded from "scifi" on the Coldfire chip (are they the same person?).

Another possible explanation is that "ERASE -> PROGRAM value -> PROGRAM value" is wrong and an oversimplification, and is really saying that the second "value" can't be one that has bits set in it that aren't set in the first "value", but that the support person really doesn't want to try to explain binary arithmetic fundamentals to the supportee.

I went to read the exact wording of the LM3S9B96 Data Sheet to see if it had been misquoted, but they want registration-before-downloading and I can't be bothered. Could someone with this data sheet (on the other forum) please check the exact wording.

Luminary does have an App Note on FLASH programming. Has Freescale got any? They seem to have plenty on the HC11, S12, 68HC and Coldfire V1, but nothing from this millennium.

Concerning one of Mark's question on the other forum:

Can you say anything about benefits of the technology? I suppose that the FLASH becomes more reliable over time since maybe a single bad bit is correctable(?)

Maybe it makes it more reliable. But it also lets them use smaller transistors that are less reliable, but cheaper. How about multiple voltage levels per cell and correcting up to FIVE bits at a time? This is block-mode NAND FLASH and not what we use in the small embedded stuff...

http://en.wikipedia.org/wiki/NAND_flash

http://en.wikipedia.org/wiki/Multi-level_cell

[mjbcswitzerland]

Hi

Although it seems a bit strange discussing other FLASH technologies here it is best to point out that the FLASH technology in the new Luminary Tempest parts includes ECC (Error-correcting Code) check of each long word. This allows the correction of one bit error in each long word, as an aid to FLASH reliability and data retention over time. Also the NXP FLASH does the same, but has the ECC over a line of 16 long words and the ability to correct more bits in this line. The disadvantage is that any changes in any bits after the first programming results in the ECC probably no longer matching and the error correction then kicks in and changes the word content read back (in an attempt to correct it since the ECC can really only be programmed once - not directly accessible by the user).

This means that a comparison with the FLASH in the Tempest parts is not valid - only a comparison with the pre-Tempest parts (without ECC) makes sense. Here they do advertise the ability to successively write additional bits to zero - this ability is a loss when ECC added...

Regards

Mark

[kef]

A bit outdated AN1837, describing few kinds of NVM memories. Applies to M68HC12, M68HC08, M68HC3xx, and MPC.

AN1837 Non-Volatile Memory Technology Overview

AN for quite fresh S12 flash, which is similar (at least at programming level) to Coldfire flash. You may look at pages 2-4 for Split-Gate Flash Memory Structure.

AN2400 HCS12 NVM Guidelines

[TomE]

---

kef wrote:

A bit outdated AN1837, describing few kinds of NVM memories. Applies to M68HC12, M68HC08, M68HC3xx, and MPC.

AN1837 Non-Volatile Memory Technology Overview

AN for quite fresh S12 flash, which is similar (at least at programming level) to Coldfire flash. You may look at pages 2-4 for Split-Gate Flash Memory Structure.

AN2400 HCS12 NVM Guidelines

---

Disappointing that we're reading old app notes for different chips rather than up to date app notes for the chips we're using.

This thread has morphed to the subject of whether it is permissable to "incrementally program the same bytes/words in the Coldfire chips".

AN2400 doesn't contain the word "incremental".

On Page 10 it does contain the following, on its own, in BOLD and ITALIC (so it must be important :-):

NOTE: A Flash or EEPROM word must be erased before it is programmed.

That would seem to contradict the advice of "Freescale Support" relayed by "scifi" in this thread on " 2010-01-08 09:49 AM ".

Or we can't use S12 documents to program the Coldfire chips. There's nothing in the MCF5213RM.pdf manual that says what sort of FLASH it is, or what technology. it doesn't say it is "split gate". The Data Sheet (MCF5213EC.pdf) does say it is "SGFM", so probably "split gate".

This thread is two weeks old and we still don't have a definitive answer.

[scifi]

---

TomE wrote:

Disappointing that we're reading old app notes for different chips rather than up to date app notes for the chips we're using.

---

I remember seeing somewhere that Freescale licenses SST's SuperFlash technology for the Coldfire MCU's. It might be worth taking a look if SST has any useful information on their web site. So far I haven't found much, though.

[LordMark]

Here's the answer form Freescale Support about this issue. I asked about accessing the flash directly from the flash itself.

"Customer can run code from Flash to do Flash erase/program applications,
such as using Flash as an eeprom device and so on.
The restriction condition is that: application code area and data
storage area is not in the same Flash sector. customer can not run "Mass
Erase" & "Blank Check" commands.
Although it seems to work, while we can not recommend engineers to do
like this way.
The application note recommend to copy code from Flash to RAM, and run
from RAM."

So it seems to me that it is 100% safe to write flash from RAM. 

[TomE]

---

Lord Mark wrote:

Here's the answer form Freescale Support about this issue. I asked about accessing the flash directly from the flash itself.

"...Although it seems to work, while we can not recommend engineers to do like this way.
The application note recommend to copy code from Flash to RAM, and run rom RAM."

So it seems to me that it is 100% safe to write flash from RAM. 

---

The manufacturer is saying "can not recommend" and you're translating that as "100% safe". Remind me to never buy any products you've written code for.

If you're doing this a a hobby, then it is safe as a hobby, but "real world products" had better follow the rules laid down by the component manufacturer.

 

[LordMark]

Freescale engineers cannot recommend to write flash directly from flash. So I wrote "it is 100% safe to write flash from RAM" as suggested in the application note... where am I wrong? 

Message Edited by Lord Mark on 2010-01-05 12:56 PM

[TomE]

---

Lord Mark wrote:
Freescale engineers cannot recommend to write flash directly from flash. So I wrote "it is 100% safe to write flash from RAM" as suggested in the application note... where am I wrong? 

---

You're correct. I misread your post as "safe to write FLASH from FLASH". Sorry.

[scifi]

I should have searched the site first. There is a FAQ entry from 2007 that confirms Lord Mark's findings:

Coldfire Flash Module CFM - when the code/data relocation is needed

As for repeated programming of the same longword, the only thing I could find is Application Note 3521:

AN3521

It concerns the CFM of the MCF521. Among other things, it says:

After erasing a longword, using page or mass erase, the value is 0xFFFFFFFF. The programmer can clear bits in the same longword, but cannot set bits, until an erase command is executed previously.

This suggests that it's OK to program the same longword repeatedly to clear bits. But there is no information on how repeated writes affect flash reliability. I guess I should submit a service request with the question...

Message Edited by scifi on 2010-01-05 12:01 PM

[TomE]

---

scifi wrote: http://www.freescale.com/files/32bit/doc/app_note/AN3521.pdf" rel="nofollow" target="_self

AN3521

It concerns the CFM of the MCF521. Among other things, it says:

After erasing a longword, using page or mass erase, the value is 0xFFFFFFFF. The programmer can clear bits in the same longword, but cannot set bits, until an erase command is executed previously.

This suggests that it's OK to program the same longword repeatedly to clear bits.

---

It seems to read that way. What the writer may have meant is that you can clear bits in successive longwords in a SECTOR (write to location zero, then 4 then 8 and so on, but can't write ones until the SECTOR has been erased.

The App Note refers to the Reference Manual for details. I've just read the whole of the FLASH chapter and there's no mention of multiple writes. It only states "Program: The operation programs a previously erased address in the flash memory using an embedded algorithm."

No mention there of programming a previously-programmed location. That reads as "you can only write to an erased word" and I'd read that to say you only get to do it once.

Please do submit a service request. I suspect you'll get a "not recommended" response like the previous poster got. If Freescale doesn't have production tests for a chip function, then they can't GUARANTEE the function on all of their chips.

Just because something "seems to work" on one batch of chips doesn't guarantee the next 10,000 units are going to work the same way.

There's a huge amount of FLASH, unlike EEPROM in old HC11's. Why would you WANT to overwrite multiple bits in a word? What's the reason?

Another point, if you did find a chip that let you do this, the code would not be portable to any other chips that didn't allow this. Code written to not depend on this "feature" is a lot more portable to other chips.

In response to a previous post, EEPROM and FLASH are different. What worked 15 years ago in manually programming an EEPROM in an HC11 doesn't help with what an embedded algorithm programming modern FLASH hardware is doing.

[scifi]

---

TomE wrote:

There's a huge amount of FLASH, unlike EEPROM in old HC11's. Why would you WANT to overwrite multiple bits in a word? What's the reason?

---

When I first started to look around for ideas to emulate EEPROM, I was working with the STR710 from ST. ST have an application note:

EEPROM Emulation with STR71x

It mentions 'incremental programming':

Incremental programmming: The Flash controller will accept to program a word that is already programmed if the new word is adding more “0” bits.

This was used in the proposed EEPROM emulation algorithm to update the sector status code incrementally: 0xFF, 0xFE, 0xFC, 0xF8 and so on. The status codes would mean something like 'erased', 'updating', 'up-to-date', 'expired'.

I implemented EEPROM emulation based on ideas from ST's application notes. Incremental programming was used in the implementation. It's useful for 2 reasons:

- My implementation adds new records to flash in 16-bit chunks. Transitioning to 32-bit chunks will waste more memory.

- 'Transaction complete' markers. Right now I use a single bit for those. Without incremental programming I'll have to use 32-bit words. That's a considerable waste of memory.

When porting software to Coldfire, I only made minor modifications. EEPROM emulation is essentially identical to that of STR710. I should probably correct that now.

[mjbcswitzerland]

Hi

Not wishing to start a war of opinions but I must admit that there are many occasions when incremental programming of 32 bit words is a nice advantage - the Freescale devices are quite pleasant to use in this respect:

1) when porting Flash drivers from 8 or 16 bit processors

2) when counting events in non-volatile memory (one event can be counted by setting a further '0' in a block of memory rather than a complete word. 32x saving is very noticable in such cases.

3) EEPROM emulation and safe updates (this is also the method used in Intel application notes from the first FLASH devices that I used around 1993 - here their recommendation was to mark a block as in progress by setting its first byte to 0xfe, then mark that it was ready by setting it to 0xfc, and later marking it as temporarily deleted by setting it to 0xf8 - once a new block was ready it could be deleted but in the mean time could always be recovered in case of a system failure during the sequence -or something like that). Admitedly it could also be done using several reserved words...

On a side note - try porting any existing Flash driver (whether byte, short word or long word oriented) to an NXP chip. Porting is then not really the name for it - it is more like "starting again"...;-)

Regards

Mark

[mjbcswitzerland]

Hi All

The following shows that such discussions are not restricted to the Freescale parts: http://www.luminarymicro.com/component/option,com_joomlaboard/Itemid,92/func,view/id,7594/catid,5/

It is however interesting that there is a very clear statement about accumulative word programming (see quote towards end of the thread).

Below is also the programming algorithm used on the Freescale parts (accumulative programming is supported and used actively) in a form allowing buffer writes (more like memcpy() style) so the caller doesn't actually need to be (fully) aware of the alignments and which bytes are acually being programmed in the individual long words of FLASH.

// Program a byte buffer content to any FLASH area//extern int fnWriteBytesFlash(unsigned char *ucDestination, unsigned char *ucData, MAX_FILE_LENGTH Length){    unsigned long *ptrLong = (unsigned long *)((CAST_POINTER_ARITHMETIC)ucDestination & ~0x3); // long address starting on    unsigned long ulValue = 0xffffffff;            // deleted state    int iByteInLong = ucDestination - (unsigned char *)ptrLong; // long word align    while (Length--) {                             // while bytes in buffer        ulValue &= ~(0xff << ((3 - iByteInLong) * 8)); // clear space for new byte        ulValue |= (*ucData++ << ((3 - iByteInLong) * 8));// insert new byte        if (iByteInLong == 3) {                    // can we write a long ?            if (fnWriteLongWordFlash(ptrLong++, ulValue) != 0) {                return 1;                  // programming error            }            if (!Length) {                 // complete buffer programmed                return 0;                  // completed            }            ulValue = 0xffffffff;          // deleted state            iByteInLong = 0;               // long word aligned        }        else {            iByteInLong++;                 // advance byte in the long word        }    }    return (fnWriteLongWordFlash(ptrLong, ulValue)); // program final long word}

Of course the caller still needs to be aware that already programmed signle bytes can not be reprogrammed without first deleting the FLASH sector...

The actual programming does take place from SRAM (it is easy to do and experience has shown that interrupt routines trying to run from other logical sectors during programming can really (in some cases) cause exceptions to occur - so stays on the safe side on that one).

Regards

Mark

[geoffW]

Hi

Thanks Mark for taking the time to describe the Flash programming issues with with Coldfire MCF52259 etc.  Freescale should pay you a fee for helping out in resolving the confusion caused by their documentation

It looks like I need to play safe and investigate how to burn code from RAM. I was hoping to avoid that as it has its own limitations. It means Interrupts need to be off for considerable time periods during the erase and burn. So for example if I was trying to design a TFTP enabled bootloader, I would likely have problems in interleaving the cycles of get packets over Ethernet, then burn packets to Flash.

I still havent managed to find some example code from Freescale that shows how to copy a portion of executable code to RAM and execute the flash code from there.

Freescale's own bootloader example code, seems to burn code to flash whilst executing from flash.

Could anyone post a link to some example code that illustrates copying code to RAM and burning Flash from RAM ? 

Thanks

 Geoff