Den fredag den 6. maj 2016 kl. 18.23.32 UTC+2 skrev Randy Yates:> Dimiter_Popoff <dp@tgi-sci.com> writes: > > > On 06.5.2016 г. 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.why would you need an interrupt to feed the watchdog? -Lasse
Programming FLASH on the Freescale Coldfire
Started by ●May 4, 2016
Reply by ●May 6, 20162016-05-06
Reply by ●May 6, 20162016-05-06
On Fri, 06 May 2016 12:23:27 -0400, Randy Yates wrote:> Dimiter_Popoff <dp@tgi-sci.com> writes: > >> On 06.5.2016 г. 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. 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 http://www.wescottdesign.com
Reply by ●May 6, 20162016-05-06
lasselangwadtchristensen@gmail.com writes:> Den fredag den 6. maj 2016 kl. 18.23.32 UTC+2 skrev Randy Yates: >> Dimiter_Popoff <dp@tgi-sci.com> writes: >> >> > On 06.5.2016 г. 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. > > why would you need an interrupt to feed the watchdog?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 http://www.digitalsignallabs.com
Reply by ●May 6, 20162016-05-06
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 г. 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. > > 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.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 http://www.digitalsignallabs.com
Reply by ●May 6, 20162016-05-06
Tim Wescott wrote:> 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. >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 by ●May 6, 20162016-05-06
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 г. 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.) -- Randy Yates, DSP/Embedded Firmware Developer Digital Signal Labs http://www.digitalsignallabs.com
Reply by ●May 6, 20162016-05-06
On Fri, 06 May 2016 18:05:59 +0000, Rob Gaddi wrote:> Tim Wescott wrote: > >> 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. >> >> > 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.On those few occasions where I've used a watchdog, that's how I've kicked it. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com
Reply by ●May 6, 20162016-05-06
On Fri, 06 May 2016 14:00:10 -0400, 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 г. 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. >> >> 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. > > 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.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 http://www.wescottdesign.com
Reply by ●May 6, 20162016-05-06
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 г. 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. >> >> 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. > > 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. >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 by ●May 6, 20162016-05-06
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 г. 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
