Programming FLASH on the Freescale Coldfire

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.

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.

Tauno,

Thanks for the confirmation.

Other surprises? Like what?

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

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

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

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

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.

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

the

it

in

er

er

ike

you

why would you need an interrupt to feed the watchdog?

-Lasse

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.

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.

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.

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.

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

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

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.

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.

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