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 <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 07.5.2016 &#1075;. 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/

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

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

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 &#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.
>>
>> 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

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

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.)
-- 
Randy Yates, DSP/Embedded Firmware Developer
Digital Signal Labs
http://www.digitalsignallabs.com

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.