MCF52233 Flash Programming

[ahoysala]

I'm using MCF52233 (without RTOS) for a project. Would like to know if I can get hold of example firmware sub-routines to read/read-sector/write/write-sector/erase/erase-sector the chip's internal flash. We are trying to use this to store some configuration data and would greatly help if we could use the internal flash instead of using an external EEPROM or the likes. Also would like to know the times requires for the sector-erase/sector-write etcetera (during which I presume the ISRs need to be disabled), as we have other task running in the back ground and we need to know the time required for the flash programming to analyse if any of the background task could starve of CPU.

[RichTestardi]

I always keep two copies of flash data that can be changing, since updates of any non-trivial data are necessarily not atomic (and you can lose power between an erase and write, or between two writes).

You want to use the "old" data until the "new" data is completely written, and that "completion" must be an atomic (i.e., 4 byte) operation.

The algorithm I use is described here: http://forums.freescale.com/freescale/board/message?board.id=CFCOMM&message.id=4348&query.id=25059#M...

-- Rich

PS also, I didn't mean to scare you with the "DMA from flash" warning -- that is very infrequent, though you do have to consider it...  I rarely initiate DMA from flash -- it has to be an outbound operation (like to USB or Ethernet) that originates with read-only data...  You might want to make sure those are not happening if you decide to let the system run (i.e., interrupts, too) during the flash operation.  Like I said, I'm not sure what the outcome will be there.

[ahoysala]

I've all the three UARTs plus the i2c communication running in the background, I fear the flash erase operation with ISRs running in full swing might result in few critical packet losses. Adding to that the DMA thing. I'm now thinking to make all these work in the first place, once I make sure the aforementioned work (I mean the application), I will then work on the programming the flash with all theses ISRs ON, will have to do a little bit of research though.

Thanks for the ready code.

[RichTestardi]

Keep in mind that even though you can run with ISRs enabled during the flash operation, if the CPU attempts to read flash during a flash operation, it will stall until the flash operation is completed...  If you want to be guaranteed to get useful work done during the flash operation, you need to be running from RAM (and not accessing flash during the flash operation).

[ahoysala]

Ok. Got it, that sound's more like a research job and warning.

Thanks again.

[vier_kuifjes]

Hello Rick,

I have never used flash programming before but I always intended to do it to save some project parameters. I have read this thread and the threads referred to. It seems easy enough to implement flash programming.

One - probably dumb - question though... for the M52221DEMO board you define a parameter FSYS to 48000000, which is clearly the crystal frequence of that board. My question is, is FSYS purely the board crystal frequency, or are there other paramaters involved here also, like PLL?

If it's just the crystal frequency, that would mean FSYS should be 25000000 for the 52233DEMO and 52235EVB boards, and 48000000 for the 52259DEMO...

[RichTestardi]

Hi Marc,

In my latest code (see sources/flash.c in the zip file at the link above), I try and distinguish between cpu_frequency, bus_frequency (which is cpu_frequency/2 for coldfire), and oscillator_frequency, rather than using the ambiguous FSYS I used in (much) earlier code.  (I unfortunately still have an ambiguous fsys in the clone path, but I assume you are not talking about that.)

In the earlier code, FSYS was the system clock (fsys) from figure 5-1 of the MCF52223 ColdFire Integrated Microcontroller Reference Manual, Rev. 3 that is used by the CPU and before the divide-by-2 for the peripheral bus -- but I don't suggest you use the earlier code as a reference.

You can see my settings for the M52221DEMO, M52233DEMO, and M52259DEMOKIT boards in that same zip file in startup.c -- just search for "cpu_frequency".

-- Rich

[vier_kuifjes]

Thanks Rick! I used your code (hope you don't mind :smileyhappy: and it worked perfectly from the first time!

[RichTestardi]

I'm glad it worked for you!  Of course I don't mind -- that's why I post it. :smileyhappy:

[RichTestardi · Accepted solution]

If you don't mind digging thru code for other MCUs, I have routines to erase/write flash on the 52233 (and a bunch of other MCUs) in the file sources/flash.c in this archive:

  http://www.cpustick.com/downloads/skeleton.zip

Just search for the #if MCF52233 cases.

The routines you want are:

void
flash_erase_pages(uint32 *addr, uint32 npages);

void
flash_write_words(uint32 *addr, uint32 *data, uint32 nwords);

-- Rich

[RichTestardi]

PS the routines you want are the first three in the file...  I use an assert() macro liberally that you can either remove or define with something like:

#define assert(x)  if (! (x)) { asm { halt }; }

I find the sector erase time to be about 20ms and disable interrupts with my splx(7) routine (also in the archive) -- see:

http://forums.freescale.com/freescale/board/message?board.id=CWCFCOMM&message.id=2737#M2737

Message Edited by Rich T on 2009-04-16 11:43 AM

[ahoysala]

That looks pretty good. But is there a way to mass copy a whole section of RAM area to flash and vice versa?

I mean can this be made without using things like flash_write_words()?

Like I actually want to copy a whole array into it.

[RichTestardi]

Sure, you can use flash_write_words() to copy any amount of data, from a single word (hence the name) to a flash page or more, as long as the destination pages are erased and the total amount of data to copy is a multiple of the word size.

So, for example, to erase a page and then copy to it (in its entirety) from RAM, you'd do:

  

uint32 *page;
byte ram_buffer[2048];

// the page of flash to modify
page = (uint32 *)0x10000;

// erase a single 2k byte (on the 52233) page of flash
flash_erase_pages(page, 1);

// rewrite the page
flash_write_words(page, (uint32 *)ram_buffer,
                  sizeof(ram_buffer)/sizeof(uint32));

Note that on ColdFire V2, you always erase an entire (2k byte) page at a time, and always program a multiple of words (32 bits, 4 bytes) at a time.

-- Rich

[RichTestardi]

(And, if you want to copy from flash to RAM, you can just use memcpy()...)

[ahoysala]

Thanks. So I understand when a sector erase happens I need to disable other ISR for this duration (~15ms), but during sector write, does the same thing happen? or the write happens word by word (and I presume the word by word write takes short naps and enables ISR for a brief periods intermittently)?

[RichTestardi]

I have not timed writes.

My code disables interrupts for the duration of all writes (i.e., outside the loop), but I don't believe that is necessary -- you could just as easily disable and re-enable them after writing each word, with a small amount of code restructuring (disabling interrupts inside the loop), though I believe that may slow things down a bit as you have to move the final busy wait inside the loop, as well, so you lose any concurrency that you might have on flash operations with the original code.

It is *possible* you can get by without disabling interrupts at all, but I did not feel comfortable with that.

-- Rich

[RichTestardi]

Re: I've programmed flash earlier on MCF51QE128 core...

The 51QE128 states in the reference manual 4.5.3.1:

If the flash memory is read during execution of an algorithm (FCCF = 0), the read operation returns invalid data and the FACCERR flag is not set.

The 52233 has no such clause, and in fact says in 17.4.2.3.3:

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 is one of many differences in the flash controller between CF V1 and CF V2 -- CF V2 is much easier to work with.

You can see in that same file I also support the 51QE128 and in that case, have to copy the flash_command() routine to RAM to run it.

With all that said, I'm not sure how CF V2 behaves for *DMA* accesses to flash (as opposed to "core" accesses) during that window, so you still might need to quiesce parts of the system before performing the writes anyway...

-- Rich

[ahoysala]

If the ISR can run while flash programming that's going to be of terrific use. But I may have to keep 2 copies of data in flash in case one of them gets corrupted (just in case).

This should help.

Thanks.

[ahoysala]

One more, I've programmed flash earlier on MCF51QE128 core. I had to copy the flash erase and wrte functions to RAM to program flash, has the same thing got to be done in this case as well?