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.

[TomE]

---

geoffW wrote:

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.

Thanks

 Geoff

---

I did that at my last job.

You simply don't send the TFTP ACK back to the remote until you have burned the just-received sector.

The longest delay is when your device decides (after getting the first TFTP packet) to erase all of the code FLASH. That takes the longest time. If you do the erase "out of band" (separate command) you don't have this problem and Mark's advice on this is good.

This stuff is complex. There's a lot of things to get wrong, again and again. Your time is expensive. Late delivery to customers is even more expensive. Mark's suggestion of "buying the lot" is very sensible.

Of course if you're a hobbyist this doesn't apply.

Check the RTEMS and uCLinux distributions for possible example code. No, I haven't looked there for this sort of thing.

Copying code to RAM is a simple matter of a memcpy and a function pointer assigned to where you copied it to. This is very basic C coding. The tricky bit is finding out how long the function that you're copying is (how many bytes to copy) if you want it to be automatic and handle size increases when you edit. of course you could inspect the map and "objdump -s" outputs and hard code the length, but that'll bite you. You might be able to use the address of "the next function" unless the linker moves it on you, or the compiler inlines stuff. The better way is to have the "copy to RAM" functions in their own file, linked to their own segment with "start" and "end" labels in the linker command file. This is very basic linker setup you need to know about when setting up embedded systems.

[mjbcswitzerland]

Hi Geoff

There is no problem with Ethernet and programming (each byte programming takes maybe 100us so is hardly noticable - most peripherals are double buffered, and more, so can handle short times with blocked interrupts).

If you want to greatly reduce development time you can get all code/support that you need - with the FLASH drivers from RAM, parameter and file system; Ethernet loaders [FTP, HTTP post, - and optional encrption - TFTP]; serial loader; TCP/IP, USB-CDC [also with firmware loading], dynamic web server, utFAT for SD card, plus M5225x simulator, plus lots more: http://www.utasker.com/kirin3.html

Regards

Mark

www.uTasker.com
- OS, TCP/IP stack, USB, device drivers and simulator for M521X, M521XX, M5221X, M5222X, M5223X, M5225X. One package does them all - "Embedding it better..."

Message Edited by mjbcswitzerland on 2010-01-11 01:21 PM

[LordMark]

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. 

[scifi]

---

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.

[mjbcswitzerland]

Hi

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

[LordMark]

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. 

 

[mjbcswitzerland]

Hi

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

[kef]

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

[bkatt]

---

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.

[kef]

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.

[kef]

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

[PaoloRenzo]

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:

[Obetz]

Hello Paolo,

you wrote:

---

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:

---

I disagree. "scifi" already wrote that the manual states "flash write operation from the internal flash bus holds off the Core platform until it is completed". So what is the problem?

IMHO this phrasing explicitly allows to run the flash programming code from flash - as long as you can tolerate that the CPU is halted for the time the command takes (a RAM routine can't do much more than wait).

Oliver

Message Edited by Obetz on 2010-01-11 07:08 PM

Message Edited by Obetz on 2010-01-11 07:09 PM

[PaoloRenzo]

Hi Oliver

Sorry for my late answer but I was asking what is the official Freescale position on this:

You can't execute from the same logical block that you are programming/erasing.  But all the tests we've done and looking at the flash design there is no reason you can't program and execute from the same logical block.  The parts are not tested for this though, so the life of the part can be affected.

Regarding incremental programming:

If you mean the following

1. erase longword 0xFFFFFFFF
2. write first bit 0x7FFFFFFF
3. write next bit 0x3FFFFFFF
4. ....

All without erasing in between, yes you can do this, but it degrades the lifetime of the part and we do not recommend it.

Hope this finally answers all the questions once and for all

[Obetz]

Hello Paolo,

---

You can't execute from the same logical block that you are programming/erasing.  But all the tests we've done and looking at the flash design there is no reason you can't program and execute from the same logical block.  The parts are not tested for this though, so the life of the part can be affected.

---

sadly you didn't go into the replays of "scifi" and me saying that the manual explicitly states that it should work.

The reason why running the flash programming code from the same flash block is that the flash is not accessible to the MCU during the programming, so the program would crash if the core wants to read the next word from flash.

But some CF manuals (e.g. 52259) state "holds off the Core platform until it is completed". Why should someone state this if it is not intended to running the flash programming code from flash?

And I can't see why it should have any effect on "life of the part" - could you please explain?

The flash state machine should not be affected by the core. So if the core doesn't crash, what else should happen?

Oliver

[mjbcswitzerland]

Hi All

I was interested to see that the FLASH memory in the Flexis (Coldfire V1) has some seemingly different characteristics and also different control methods:

1) The user's manual states that it "doesn't" support cumulative writes to an address in a Flash block (with a caution in red) so this is clear

2) It is however still possible to control the writing of just 16 bits of the interleaved 32 bits of a long word address using a control bit (LVDF in SPMSC1). This allows two writes; 0xff55ffaa followed by 0x55ffaaff to achieved 0x5555aaaa. This is nice because it still gives partial cumulative write capabilities in a way that is managed and obviously legal.

Regards

Mark

[mjbcswitzerland]

Hi Paolo

---

You can't execute from the same logical block that you are programming/erasing.  But all the tests we've done and looking at the flash design there is no reason you can't program and execute from the same logical block.  The parts are not tested for this though, so the life of the part can be affected.

---

Please could you review this to be sure that it is understood?

A logical block is a group of logical pages (estimated as 256k in size in M52259 (with 4k logical pages), as reference). This means that according to practical tests there is no reason that code running anywhere in this area cannot be run while programming any part of the same logical block. Eg. code could be running a programming routine at the address 0x2000 and writing the long word address 0x2080.

Could the first line be deleted ("You can't execute from the same logical block that you are programming") because the second line then overrides it?

Thanks.

regards

Mark

[kef]

Paolo,

thanks for your valueable response.

And what about this sequence:

1. erase longword 0xFFFFFFFF
2. write first bit 0x7FFFFFFF
3. write next bit latching 0xBFFFFFFF to the flash, expecting resulting longword value 0x3FFFFFFF
4. ....

It should wrk also, but will it degrade flash as well? If it degrades flash as well, then please give us a clue way. This different sequence should not additionally charge floating gates of bits programmed in step 2. 

Thank You

[scifi]

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.