Watchdog enabled during ROM_UpdateUART

Hello Igor

Yes, you can disable the Watchdog be clearing the clock enable bit of the Watchdog in the SYSCTL.RCGCWD register.

Regards
Amit

Just a side note, nothing to do with your issue. I wouldn't consider a 1s watchdog small but rather quite large. Currently my inner watchdog runs at a few mS.

Robert

Robert - could not agree more - much damage may occur w/in hundreds of milli-seconds of mayhem!
Would you agree that poster needs to identify and eliminate (at least greatly speed) the (overly long) time duration of his loop (or loops) which (we assume) has/have created the need for, "Rip Van Winkle" (long) watchdog time-out?

Depends on what he is doing. One second may be appropriate for a communications processor.

However for control I would expect a lot tighter. I think what sometimes happens is people use a slow watchdog so they can watch everything.

What I doing currently is a three level arrangement so I can catch different processes failing. The shortest is the hardware directly and it's got a 200uS to reset setting. This is reset periodically by a fast process. Not only does this process have to run in a timely fashion to reset the watchdog but it maintains it's own counting flag that must be reset by another process or it will not reset the watchdog. That flag is reset by another slower process run off of the main clock, it checks similar counting flags for all the slower critical tasks in the system. So tasks trip the watchdog based on how frequently they are required to run. It also means you are actually checking multiple processes with the watchdog.

If, by necessity, there is a single long process loop to check then it is also possible to check progress within the loop rather than just the iteration frequency.

Robert

Excellent - you've enabled multiple MCU processes to (each) become "watchdog" monitored - even if (and especially if) they run at different rates.  

We note your inspired use of (other) "counting flags" (not part of the MCU's watchdog) which serve to vastly expand the watchdog's capabilities - and provide (far) greater program security.    Very well done - "treasure trove" of insight folks (i.e. "bookmark") - merci...

Yes I agree, but there are some exceptions,
for example, if I do large writing with TIVA C USB as host to disk on key , this can take at least 100ms (tested it with systick before and after) if not worse, depending on disk on key writing speed, and I am using third parity (fatfs), so 1 second on worst case reset to watch dog should avoid mcu to reset during disk on key writings

Anyway thanks to Amit Ashara,
you solution helped me a lot :)

Hello Igor,

The forum member's input are very valuable as well since I alone may not have a large sense of the application(s) that use the device. But glad that my solution did help you.

Regards
Amit

May I suggest that during that during that long, 1 second period and (only then) you switch to 1 second watchdog period? (as & if possible - we do not know your full program scheme nor requirements)

As poster Robert has well noted - if (other) vital processes are "interspersed" w/in that USB access - they should (continue) to be monitored - and at minimum "flag" any detected issues.

Agreed, better yet move the writing to a separate thread (probably not watchdogged). It's better not to change watchdog periods, you are apt to find out after something unfortunate that it was left long when it should have been short.

I do that for writing to some NVRAM, it has a maximum write time of several seconds so it cannot be done in any of the process threads. If it was it would trip the watchdog and quite properly so since the processes would be failing the required timing. Instead by running in a separate thread I allow the writing to take as long as it needs and multiple threads can share the storage resource if needed.

Robert

Thank you kindly,

I add one other element to these counting flags. They use an EDC to encode 4 bits of data into 7 bits. This means only 16 values out of a possible 128 are valid. This reduces the chance of a wild overwrite accidentally resetting the watchdog.

I've been using this technique for 20+ years now (yikes)

Robert