Programming FLASH on the Freescale Coldfire

Folks,

We need to store some non-volatile parameters across power-ups and I'm trying to determine how to programmatically write to FLASH in the MCF52235 Coldfire V2 processor (256KB). From the reference manual it looks like reads from the ENTIRE FLASH are disabled when updating (erasing/programming) any part of the FLASH, even if you're just updating one of the 32 8 KB sectors. But I'm not absolutely certain this is true. Could someone please verify?

--
Randy Yates, DSP/Embedded Firmware Developer 
Digital Signal Labs 
 Click to see the full signature
Reply to
Randy Yates
Loading thread data ...

That is common with embedded flash units. You have to code the inner core of the programming loop so it can be run from RAM, and remember to disable interrupts and other surprises for the programming time.

--

-TV
Reply to
Tauno Voipio

Yup. Fun-fun. And if there's anything that'll go "Phzzzt!" for lack of attention while flash is being written, put it in a safe state.

--
Tim Wescott 
Wescott Design Services 
 Click to see the full signature
Reply to
Tim Wescott

Tauno,

Thanks for the confirmation.

Other surprises? Like what?

--
Randy Yates, DSP/Embedded Firmware Developer 
Digital Signal Labs 
 Click to see the full signature
Reply to
Randy Yates

Tim already responded - calm down external hardware that could not like the lack of attention during programming.

--

-TV
Reply to
Tauno Voipio

I've worked on systems that would twitch, or at least go "tick" when you saved parameters.

--
Tim Wescott 
Wescott Design Services 
 Click to see the full signature
Reply to
Tim Wescott

I guess keeping an eye on watchdog timers (i.e., disabling such) would be one type of attention required...

--
Randy Yates, DSP/Embedded Firmware Developer 
Digital Signal Labs 
 Click to see the full signature
Reply to
Randy Yates

Just servicing it during programming might be easier than disabling it I think (but I don't remember how I did it on the MCF52211, it's been a while).

Dimiter

Reply to
Dimiter_Popoff

Seems to be wiser, too, somehow.

One way or another, having the processor reset in the middle of an EEPROM write would be a Bad Thing.

--
Tim Wescott 
Control systems, embedded software and circuit design 
 Click to see the full signature
Reply to
Tim Wescott

Perhaps 6/half dozen, but to service it you'd then need to ensure the interrupt handler is also in memory.

--
Randy Yates, DSP/Embedded Firmware Developer 
Digital Signal Labs 
 Click to see the full signature
Reply to
Randy Yates

d

the

it

in

er

er

.

ike

you

why would you need an interrupt to feed the watchdog?

-Lasse

Reply to
lasselangwadtchristensen

No, you just need to kick the dog from inside your flash programming routine.

Generally -- since you're not doing anything else anyway -- you break the rules of good embedded programming and spin on the "flash busy" bit. You can just kick the dog from inside that loop.

IMHO it's bad practice to kick the dog from inside an ISR. I've had bugs that killed everything BUT the ISRs; in such a circumstance you'd have a zombie application that is still kicking the dog.

--
Tim Wescott 
Wescott Design Services 
 Click to see the full signature
Reply to
Tim Wescott

How else do you feed a watchdog? In a continuous loop?!?

I guess you could predict timing in the FLASH update routine and ensure you issue watchdog triggers at a required rate.

--
Randy Yates, DSP/Embedded Firmware Developer 
Digital Signal Labs 
 Click to see the full signature
Reply to
Randy Yates

IMHO watchdogs always were a bad idea period, except for perhaps something extreme like space-critical stuff. I first encountered them circa 1983 and have always disliked them. Just get the bugs out.

--
Randy Yates, DSP/Embedded Firmware Developer 
Digital Signal Labs 
 Click to see the full signature
Reply to
Randy Yates

One thing I've done when I've been feeling paranoid is have each "task" in the system get its own flag that it sets each time it runs. The watchdog kicker checks to see that all the flags are set, and only kicks if they are, in which case it rips through clearing all the flags.

Set up like that it's a bit easier to think of if the watchdog is on the periodic interrupt, though it ultimately doesn't matter much.

--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
 
Email address domain is currently out of order.  See above to fix.
Reply to
Rob Gaddi

PS: Yes, that is another option. I'm not sure how useful that would be, but thank you. (Actually I think Lasse had mentioned this just a few minutes before you, Tim.)

--
Randy Yates, DSP/Embedded Firmware Developer 
Digital Signal Labs 
 Click to see the full signature
Reply to
Randy Yates

On those few occasions where I've used a watchdog, that's how I've kicked it.

--
Tim Wescott 
Wescott Design Services 
 Click to see the full signature
Reply to
Tim Wescott

I agree, for the most part. But then, I've always worked on stuff where it's fairly low-cost to just leave it to the user to cycle power.

If you've got something that needs to work for years on a mountaintop -- maybe a watchdog is a good idea. But then you should be doing a lot more than just kicking the dog, because there's plenty of ways for systems to get screwed up and still think they're A-OK.

--
Tim Wescott 
Wescott Design Services 
 Click to see the full signature
Reply to
Tim Wescott

Pretty much. I've talked teams into turning them off for deployment unless under observation like a test site or with detailed instrumentation attached before.

--
Les Cargill
Reply to
Les Cargill

I'd disable the dog whilst burning FLASH. IMO. You generally don't need to capriciously lose the FLASH.

--
Les Cargill
Reply to
Les Cargill

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.