ColdFire/68K Microcontrollers and ProcessorsのトピックRe: MCF52259 and flash writing / erasing

MCF52259 and flash writing / erasing

LordMark — Thu, 31 Dec 2009 03:05:08 GMT

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.

Re: MCF52259 and flash writing / erasing

mjbcswitzerland — Thu, 31 Dec 2009 05:22:38 GMT

If the FLASH memory is made up of multiple banks it is possible to run code from one bank while programming the othe. Therefore you have to ensure that the code and programming section don't occupy the same bank (logical block) - if this is the case the code must be run from RAM otherwise is will fail. The larger chips tend to have two logical blocks while the smaller ones only one - therefore smaller chips have no alternative to running FLASH programming code from RAM. Generally it may be easier to always run from RAM so that such details don't become a problem.

When programming double type variables they just need to be programmed as multiple 32 bit words. The 32 bit words also support cumulative write so it is also possible to write individual bytes at a time - the other bits in the long words should however be written with '1'.

Regards

Mark

www.uTasker.com

Re: MCF52259 and flash writing / erasing

scifi — Thu, 31 Dec 2009 15:34:16 GMT

Lord Mark wrote:

...
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?

The manual says:

After a command has been successfully launched, the CFM signals the core platform to hold off read accesses to any active flash physical block until all active and buffered commands have completed (CCIF=1). A flash write operation from the internal flash bus holds off the Core platform until it is completed.

I believe this means that it's not necessary to execute flash writing code out of RAM, it can be done from flash. That's how I do it with MCF52233 and MCF52259 - no problem so far.

Re: MCF52259 and flash writing / erasing

LordMark — Thu, 31 Dec 2009 19:12:51 GMT

Well, the memory of the MCF52259 is made up of 4 blocks so you all are right about that. I was using the latest page of the flash memory for my variables, that's why I succeded in accessing it without executing code from RAM.

mjbcswitzerland wrote:

When programming double type variables they just need to be programmed as multiple 32 bit words. The 32 bit words also support cumulative write so it is also possible to write individual bytes at a time - the other bits in the long words should however be written with '1'.

What do you mean with "Cumulative write"? Shouldn't the flash be erased before writing?

Regards,

Marco.

Re: MCF52259 and flash writing / erasing

mjbcswitzerland — Thu, 31 Dec 2009 21:18:28 GMT

An example of cumulative writes are setting a long word from 0xffffffff to 0x5555ffff and then to 0x55555555

Starting from 0xffffffff (non-programmed) the first write sets some bits to '0'. These can not be set back to '1' without deleting the complete sector. However it is possible to program the same long word address to set other bits to '0' as in the case of the 0x55555555 (it has only programmed additional bits to '0').

The Coldfire FLASH, as various others, has no problems doing this. Some FLASH types can cause data corruption when this is tried either due to electrical stresses or check sums in the FLASH line which are no longer correct after a second write (eg. NXP devices).

"After a command has been successfully launched, the CFM signals the core platform to hold off read accesses to any active flash physical block ..."

I don't know exactly what to make of this since when I first went to the Coldfire seminars the instructor said that it was absolutely necessary to run code from RAM when programming the same logical block and therefore I have always run it from RAM (generally it is also necessary to block interrupts since they could cause code to attempt to run from an area being programmed). In a project with the M52235 there were crashes during FLASH programming due to an NMI interrupt (which is not blocked by the interrupt masking) due to the fact that the NMI handler (in FLASH) would try to access the 'not-available' FLASH, which immediately causes an exception (crash of the board). By ensuring that FLASH programming was not performed in parallel to the NMI (eg. during motor control sequences)this problem was successfully avoided. This experience showed that there is some relevance to not allowing FLASH to be accessed while programming - whether there are differences between exception accesses and standard code sequence accesses is another question.

Does anyone have more information or conclusive explanations?

Regards

Mark

Re: MCF52259 and flash writing / erasing

kef — Fri, 01 Jan 2010 18:41:10 GMT

Mark,

programming more bits to '0' should be clarified a bit, at least for newbies.

Programming erased long word (0xFFFFFFFF) to 0x5555FFFF programs some bits from erased state '1' to programmed state '0'. That's obvious, I guess.

But it is not completely true that programming 0x5555FFFF to 0x55555555 only programs additional bits to '0'. In fact it programs some bits from '1' to '0' and also overprogramms some previously programmed bits from '0' to '0'. Overprogramming is very very bad, (I believe) not allowed by Freescale and may lead to premature flash wearout.

When one wants to reprogram 0x5555FFFF to 0x55555555, he should write to the flash array 0xFFFF5555. Then resulting word in flash will be 0x55555555 and no bit will be overprogrammed.

Logics should be like this:

1) if ( (want_word & current_flash_word) != want_word ) {

flash must be erased. It is not possible to program want_word without erasing current_flash_word

}

2) // make want_word not overprogramming '0' bits to '0'. Force already programmed bits to '1'.

want_word = ~current_flash_word | want_word;

current_flash_word = 0x5555FFFF

~current_flash_word = 0xAAAA0000

want_word | ~current_flash_word = 0x55555555 | 0xAAAA0000 = 0xFFFF5555

3) latch want_word to flash and program it

Re: MCF52259 and flash writing / erasing

LordMark — Fri, 01 Jan 2010 19:40:17 GMT

Anyway I don't need to reprogram a word already partially programmed. I just needed to write double type variables (64 bit) into flash. So it should be done 32 bit at a time, shouldn't it?

Regards,

Marco.

Re: MCF52259 and flash writing / erasing

bkatt — Fri, 01 Jan 2010 22:55:15 GMT

kef wrote:
...
But it is not completely true that programming 0x5555FFFF to 0x55555555 only programs additional bits to '0'. In fact it programs some bits from '1' to '0' and also overprogramms some previously programmed bits from '0' to '0'. Overprogramming is very very bad, (I believe) not allowed by Freescale and may lead to premature flash wearout.

When one wants to reprogram 0x5555FFFF to 0x55555555, he should write to the flash array 0xFFFF5555. Then resulting word in flash will be 0x55555555 and no bit will be overprogrammed.
...

We have firmware on the 5282 that occasionally performs the overprogramming in the naiive manner that Mark described. During development I tried it and is seemed to work without problems, so I left it in. It has probably been executed no more than 20 times on any given 5282 chip,

But we don't want to wear the chips out early, so I guess I should prevent the overprogramming using the technique you outlined, test it and include it in the next firmware update.

A quick net search turned up no other references about overprogramming flash. Can you tell us where you learned about this overprogramming problem?

Thanx, Bryan.

Re: MCF52259 and flash writing / erasing

kef — Sat, 02 Jan 2010 18:44:31 GMT

Marco,

of course you should write 64bit double 32 bits at a time, two times. But you should make sure you write them to long word aligned address, else you may need 3 program operations. Your compiler can align your flash variables by default or should provide some compiler #pragma or something to let you align your variables.

Bryan, Mark,

Unfortunately I don’t know good document that could explain it all clearly. The only good related Freescale/Motorola document I know is old HC11 reference manual. There’s over 10 pages chapter 4.6, EEPROM application information, which falls quite deep into EEPROM internals, discussing also write-more-zeros method (writing 0x55 to 0x5F to get 0x55) and selective-write method (writing 0xF5 to 0x5F to get 0x55). I don’t know how far flash EEPROM technology went from HC11 times, but I guess it should be still similar to old EEPROM technology. HC11 reference manual is here: http://www.freescale.com/files/microcontrollers/doc/ref_manual/M68HC11RM.pdf

But it seems I also was wrong suggesting selective-write method is better than write-more-zeros. Both methods have problems. Sorry for that. Write-more-zeros exposes flash cells to programming voltage for two or more nominal program times (high voltage exposure times). As you may know, flash clock divider determines program and erase times. There’s a caution note in MCF52259RM, saying “Programming the flash with bus frequency < 150 KHz should be avoided. Setting CFMCLKD to a value such that FCLK < 150 KHz can destroy the flash memory due to overstress… ” . So if too long program time is a problem, then cumulative write more zeros also should be a problem and can destroy the flash, isn’t it?

Selective write more zeros method (what I suggested and what I shouldn’t suggest) seems being also bad. It seems I didn’t understand it long time ago, when I was using HC11. Unless there are extra p-n junctions or something smart in flash cells (unlikely due to extra costs), selective write method can cancel programming process prematurely. Please look into HC11RM. I also tried to explain that in my pictures. Please see them attached.

I use selective write method with HC11, HC12 and HCS12 EEPROM for years. No single problem was reported. But I'll better revise my EEPROM routines.

Re: MCF52259 and flash writing / erasing

kef — Sat, 02 Jan 2010 23:25:14 GMT

But looking at NOR flash cell structure at http://en.wikipedia.org/wiki/Flash_memory , and taking into account that programming is done using hot-electron emission; high current through turned on flash cell transistor is what makes floating gate charged; I don't see how selective-write-more-zeros method could cause an issue to flash cells. So maybe it is indeed better to use selective write more zeros than just write more zeros. Not enough data at hand to be sure. Most Freescale MCU reference manuals state that programming of not erased words is not allowed...

Re: MCF52259 and flash writing / erasing

PaoloRenzo — Tue, 05 Jan 2010 04:35:12 GMT

First off, just because it works on the MCF5225x part does not mean that it should. Technically, according to the designers, you should not be able to erase one block of flash while running from another. Although it seems to work, doesn't mean that we can recommend people do it. At least this was valid for the MCF5223x

You’re doing something that technically should not be allowed. You should be happy that something that isn't supposed to work actually does work on the MCF5225x parts! :smileyhappy:

Re: MCF52259 and flash writing / erasing

scifi — Tue, 05 Jan 2010 18:31:42 GMT

I'd like to join Mark in his call for information on this issue.

So far it's all hearsay, and microcontroller manuals don't seem to be of much help here.

Of course, there is the safe option of running flash writing code from RAM. But in many cases that would be a considerable complication. It would be nice if this could be avoided.

Re: MCF52259 and flash writing / erasing

LordMark — Tue, 05 Jan 2010 18:37:40 GMT

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.

Re: MCF52259 and flash writing / erasing

scifi — Tue, 05 Jan 2010 19:55:34 GMT

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

Re: MCF52259 and flash writing / erasing

TomE — Tue, 05 Jan 2010 20:45:22 GMT

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.

Re: MCF52259 and flash writing / erasing

LordMark — Tue, 05 Jan 2010 20:55:35 GMT

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

Re: MCF52259 and flash writing / erasing

TomE — Tue, 05 Jan 2010 21:18:07 GMT

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.

Re: MCF52259 and flash writing / erasing

TomE — Tue, 05 Jan 2010 21:20:13 GMT

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.

Re: MCF52259 and flash writing / erasing

scifi — Tue, 05 Jan 2010 23:17:48 GMT

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.

Re: MCF52259 and flash writing / erasing

mjbcswitzerland — Tue, 05 Jan 2010 23:34:50 GMT

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