EmbeddedRelated.com
Forums

Programming FLASH on the Freescale Coldfire

Started by Randy Yates May 4, 2016
On 07.5.2016 г. 05:23, Les Cargill wrote:
> Randy Yates wrote: >> Tim Wescott <seemywebsite@myfooter.really> writes: >> >>> On Fri, 06 May 2016 12:23:27 -0400, Randy Yates wrote: >>> >>>> Dimiter_Popoff <dp@tgi-sci.com> writes: >>>> >>>>> On 06.5.2016 &#1075;. 05:58, Randy Yates wrote: >>>>>> Tim Wescott <seemywebsite@myfooter.really> writes: >>>>>> >>>>>>> On Thu, 05 May 2016 10:34:48 +0300, Tauno Voipio wrote: >>>>>>> >>>>>>>> On 5.5.16 06:51, Randy Yates wrote: >>>>>>>>> Tauno Voipio <tauno.voipio@notused.fi.invalid> writes: >>>>>>>>> >>>>>>>>>> On 4.5.16 17:59, Randy Yates wrote: >>>>>>>>>>> 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? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 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. >>>>>>>>> >>>>>>>>> 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). >>>> >>>> Perhaps 6/half dozen, but to service it you'd then need to ensure the >>>> interrupt handler is also in memory. >>> >>> No, you just need to kick the dog from inside your flash programming >>> routine. >> >> 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.) >> > > I'd disable the dog whilst burning FLASH. IMO. You generally don't need > to capriciously lose the FLASH. > > -- > Les Cargill
This may well be the harder option in his case. On the CF I know (mcf52211) and on other Motorola/Freescale parts the dog enable bit is a write once after reset. I don't get it why people see dogs as a problem, I have them on and kick them typically in the scheduler - have not had a device reset by the dog for decades, it just takes stable code. Dimiter ------------------------------------------------------ Dimiter Popoff, TGI http://www.tgi-sci.com ------------------------------------------------------ http://www.flickr.com/photos/didi_tgi/
Dimiter_Popoff <dp@tgi-sci.com> writes:
> [...] > This may well be the harder option in his case. On the CF I know > (mcf52211) and on other Motorola/Freescale parts the dog enable bit is > a write once after reset.
I see no such limitation described in the MCF52235 reference manual. (see section 13.5.4). Did I miss it?
> I don't get it why people see dogs as a problem, I have them on and kick > them typically in the scheduler - have not had a device reset by the dog > for decades, it just takes stable code.
It's philosophical, mainly. But this thread is some evidence of practical reasons, too. I had a boss 1/t that insisted they be used. -- Randy Yates, DSP/Embedded Firmware Developer Digital Signal Labs http://www.digitalsignallabs.com
On 08.5.2016 &#1075;. 03:28, Randy Yates wrote:
> Dimiter_Popoff <dp@tgi-sci.com> writes: >> [...] >> This may well be the harder option in his case. On the CF I know >> (mcf52211) and on other Motorola/Freescale parts the dog enable bit is >> a write once after reset. > > I see no such limitation described in the MCF52235 reference manual. > (see section 13.5.4). Did I miss it?
I had a brief glance and it looks like you did not miss it, this one can be disabled. It is a larger SOC, perhaps this is why they made it like this. This makes things easier for you, just disable it and go on with the programming. Not that servicing it say each programmed byte would be a big deal of course, but you have the choice. Just looked at the MPC5200, its watchdog can also be disabled (I have a DPS task feeding it killing which would mean reset on most of our systems).
> >> I don't get it why people see dogs as a problem, I have them on and kick >> them typically in the scheduler - have not had a device reset by the dog >> for decades, it just takes stable code. > > It's philosophical, mainly. But this thread is some evidence of > practical reasons, too. I had a boss 1/t that insisted they be used. >
I typically do the programming with them off, eventually at the end once I have things ready I turn them on to no further effect. Just looked at my flash write of the mcf52211 I did a few years ago, my comment is not "kick the dog" as people seem to say, I have said "feed the dog"... :D. Dimiter ------------------------------------------------------ Dimiter Popoff, TGI http://www.tgi-sci.com ------------------------------------------------------ http://www.flickr.com/photos/didi_tgi/
Dimiter_Popoff wrote:
<snip>
> > I don't get it why people see dogs as a problem,
One false positive and they've destroyed any value they add.
> I have them on and kick > them typically in the scheduler - have not had a device reset by the dog > for decades, it just takes stable code. >
I won't disagree - I haven't seen a watchdog fire in decades.
> Dimiter > > ------------------------------------------------------ > Dimiter Popoff, TGI http://www.tgi-sci.com > ------------------------------------------------------ > http://www.flickr.com/photos/didi_tgi/ >
-- Les Cargill