AnsweredAssumed Answered

MCF52259 Internal flash problems/errors

Question asked by FridgeFreezer on May 17, 2011
Latest reply on May 19, 2011 by FridgeFreezer

Me again! (don't worry, project is nearly finished then I'll go away for a bit :smileywink:)


I'm having some weird issues using the Freescale-supplied CFM erase/program routines as seen in their MCF52259 USB Bootloader application note supplied with the M52259EVB / DEMOMCU boards.


I'm using CW7.2.2 (just found the 7.2.1/7.2.2 patches today!), micro is MCF52259 on our own board, running direct from 48MHz crystal (no PLL) as per the EVB.


I've narrowed the issue down to errors in the flash after programming, which may be down to the CFMCLKD value, or maybe something else stupid that I've done...


We can erase, blank check, program & verify the device(s) via the BDM pod with no issues (in other words, the device is working OK & not damaged).


Using a tweaked version of the Freescale USB bootloader (we load from SPI Flash rather than USB, the but the CFM routines are untouched) we can erase the internal flash OK, but when we program it it doesn't always work - we get stray bits which are unprogrammed. Running a debug routine where we erase the flash & then prgram all zeros gives us a result that looks like the attached picture.


Something that has caused some confusion (I'm easily confused) is the CFMCLKD value, as also seen here:

The original Freescale routine, which states it's for a "clock" of 24MHz (Fsys = 48MHz == BUSCLK of 24MHz), uses PRDIV8 & a CLKDIV value of 0x0F, which by my calculations yeilds an FCLK of 187.5kHz (24000/8/(15+1)), so this is what I'm using.


If we just erase the fash & then do a series of single 32-bit word writes, filling the flash with 0x00000000, we get random bits which are not set to 0. If we read it back, we read back different values, for example:

ptr = 0x00004000 // Flash address to read, should read back 0x00a = *ptr;b = *ptr;c = *ptr;d = *ptr;


Will give a result something like:

a = 0x08

b = 0x48

c = 0x08

d = 0x08

And reading the address 0x00004000 with the BDM pod will read back 0x08. Sometimes one or more of the results read back will be correct (although the BDM pod usually agrees with the "wrong" one, maybe because it reads the data more slowly?)


All help gratefully received as ever!