A new chat series starts up in December, a few hours earlier to let more folks attend. Details soon. Hope to see you all there.

I just wondered if some bosses won't let folks chat during work hours at all.

of course, such things are a top priority. These chats are a form of supplemental education that should not interefere.

Basically, I got the boss's help to debug.

I had not informed the boss that I was joining this chat, and he being super busy, dropped by asking my help to debug a bug. The bug is kind-of priority, which I was going to debug after the chat, but with him being available, I could not let that opportunity pass.

it's ok Raju. I was wondering if chats are seen in the workplace as being inappropriate uses of time. Are they?

Sorry, boss came to my desk, will try and join Dec. chat.

I'll be scueduling December's chat two hours earlier, so that more folks will be able to join us. I'll have a blog post announcing times and topics, tomorrow, I hope

ok, thank you Rich,

Well, it's getting to the end of our hour. Thanks to all who joined in on the chat.

I will check it thanks

http://www.microcontrollercentral.com/author.asp?section_id=1759&doc_id=246334

it is possible to have a redundant watchdog. I think didier mentioned such in his blog.

can we have a watch dog for the watchdog is it common ?

of course, the watchdog itself could also fail, either in a way that leaves the system unprotected or in a way that shuts the system down when there was no other problem

ceramic packaging was also found to be a problem It had some natural radioactivity that could cause SEUs

I think it is a combination of improved process technology, ESD protections at input pins, and the elimination of external data paths. that solved that problem. Still get it in high radiation environments (it's called a single event upset or SEU) but not in commercial applications

How we prevent this glitch now not to happen that make the Wdogs not needed any more ?

in the early days of MCUs a glitch could cause the processor to misread data and thus branch to a non-existant instruction, causing program counter runaway. The watchdog reset the system if that occurred.

in which cases in the past was very crucial to use watchdogs ?

well, if the FPGA updated the memory buffer before the MCU processed it, then that unprocessed data would be lost.

"or prevent the FPGA from updating the memory." Without knowing much FPGA(now I am learning) I can guess that is very crucial

@nemos I used to use them. But my reasons for doing so are no longer valid. I suspect they are still needed in safety-cricital systems

I would think it would force the MCU to act immediately.

I mean do you suggest to use watchdogs or not ?

I think the key word is coordination. what this suggests to me is that the watchdog alerted the system when the transfer had not occurred in time. It might then be used to force the MCU to increase the priority of the processing, or prevent the FPGA from updating the memory.

if the system is made to do crucial job yes , but generally no , if you have an error I think it is better to restart it , what is your opinion about it ?

Thsi is a copy/past from BB's post which I am trying to understand.

"A recent example was in a system with an MCU and an FPGA that shared control of an external buffer memory. The FPGA could load the memory with data and the MCU would process the data. It was important to insure that the memory was loaded and processed within a specific interval. The external watchdog simplified the coordination between the FPGA and the MCU."

@nemos, yes and no? sounds coy. Where yes and when no?

I think it alerts his system when a data transfer has not occurred on time. His post mentions it helping coordinate things. So, I guess it is there to prevent overwriting of data before it has been read. Just a guess tho.

yes and no ;)

BB said he uses watchdog to ensure data is read from FPGA in a timely manner. I was wondering how?

do you use watchdogs. nemos?

Hej Rich

Raju, what was your question for BB?

hello to all

welcome christos

am listening.

Christos ;)

who else is here?

thanks for being here, duane

I'm sorry, but my time's up and I have to go. Good chatting.

again, depends on the watchdog. Some simply give you an externally-generated alert that something has gone wrong. Others do a system reset under the belief that a reboot will restore the system. Still others trigger a controlled system shutdown for safety.

In a robot, for example, I wouldn't want to just stop or reboot in the event of a watchdog timeout. I'd want to get everything back as close as possible to the same state as quickly as possible.

Since I don't use them, I really haven't studied their applications much. Do any state variables get saved or is it generally just a reset (or shut down as you mentione earlier)?

of course, if there is a clocking problem these watchdogs might not ever trigger

depends on the watchdog, duane. The ones I used were oneshots, which couldn't be changed. Internal and some external watchdogs are counters, so they could be.

Rich - Can you dynamically change the watch dog delay?

I have disabled watchdogs when I expected a long wait time, but the problem is, what do you do if the failure occurs while the watchdog is disabled?

I hope Bitbucket joins, I posted a question for him, about FPGA working with MCU.

Thanks raju. Sunshine just now, but lots of wind

When you use a watchdog, do you always have it on? Or do you sometimes disable it in some parts of your code and enable it in others?

proper timeout would depend on what you are timing. For my systems a few fractions of a second were enough to let me know the system had hung.

Rich, hope the weather improves.

Hi Raju. That makes a lot of sense. 

I'm just not sure what a proper watchdog timeout delay would be.

good point raju. And welcome

Other types of failures can also occur, and the watchdog might be useful in shutting down a system that has failed. It doesn't have to do a reboot

DB, there could be something the sftwre developer did not think about, hence for a remote system, watchdog timer could help escape from an unknown condition.

I guess it would still make sense with very complicated code as a saftey valve. And sometimes communicatrions buses, like I2C hang.

perhaps, but I don't think that's quite it either. You can get stuck in a forever loop if a communications link fails, for instance, unless you have a timeout loop counter in there.

I guess the question, then, is do people use watch dog timers when they should be doingg a bit more debugging?

today;s MCUs seem much more tolerant of glitches

I don't think so. Nowadays I think the issue is something getting stuck in a forever wait loop.

I meant glitches causing a runaway, is that still much of an issue?

Is it still that much of an issue?

hmm my posts are getting lost first time round.

I used to put them in to keep MCU from running off into program counter runaway, which would happen a lot in the early days. A glitch would do it.

I generally don't use watchdog timers but I'm quite interested in how necessary people think they really are.

yes, gale force winds predicted. Lots of rain. Fortunately the Olympic mountains protect us from southerly weather

hmm, needed to resend that last one. Hope this is a temporary thing

Sounds like wild weather up your way

well, any time you can spare is most welcome

hi duane. glad you could make it

I only have a short time today. I have to leave at about 20 after.

Hi all

Chat goes live in five minutes! Come one, come all.

Our chat goes live in half an hour. I hope to be here. We have gale wind warnings and my area is populated with 50' trees and overhead phone and power wires. I may get cut off.

BitBucket, how did the watchdog ensure loading of the memory by the FPGA? I would like to know, since our design also has an FPGA and MCU.

I find that an external watchdog can have some advantages in systems where you may have multiple controllers operating. A recent example was in a system with an MCU and an FPGA that shared control of an external buffer memory. The FPGA could load the memory with data and the MCU would process the data. It was important to insure that the memory was loaded and processed within a specific interval. The external watchdog simplified the coordination between the FPGA and the MCU.

Anyone else have examples using a watchdog with multiple processors? Do you ahve a trick for using an internal watchdog effectively?

The watchdog timer is a time-honored mechanism for ensuring that an MCU-based design does not lock up as the result of a software glitch. But is a watchdog more problem than solution? Should it be internal or external to the MCU? How do you prevent it from falsely triggering or, perhaps worse, not triggering when it should? Come talk about your ideas and experiences with watchdogs.