I've been trying to implement the watchdog timer on my Sharp79524 and it appears that the mutt is sleeping on the job! I believe I have it set up to trigger after about 3s of inactivity but it doesn't seem to reset the system at all. My setup method is as follows: 1) Write 0x00000090 to the watchdog CTL to set up for 2^25 counts of HCLK as the timeout period. This also stops an interrupt on first timeout occurring and should set up for an immediate reset. Watchdog not enabled at this point 2) Write 0x1984 to the watchdog RST register to seed the counter. (Goodness knows why they chose that value) 3) OR 0x00000001 onto the CTL register to enable the watchdog. 4) OR 0x00000008 onto the CTL regsiter to lock the enable. Then I periodically write Ox1984 to the RST register to keep everything alive. Then if I encounter a while(1); that I've planted somewhere then the system hangs but no reset ever happens. Is there something I've missed? The watchdog section of the user guide was only a few pages so it would appear to be "simple" but perhaps there are other things that affect it's operation? I've tried running under the debugger and also stand-alone from flash in case that made any difference but it doesn't seem to. Any ideas?
Watchdog that should be taken out and shot
Started by ●September 13, 2006
Reply by ●September 13, 20062006-09-13
Tom Lucas wrote:> 2) Write 0x1984 to the watchdog RST register to seed the counter. > (Goodness knows why they chose that value)It's probably the lead developer's dog's birthday written in base 9 and shown as a hex number. Almost certainly there is an ex post facto explanation as to why it is the technically sound choice.> Then I periodically write Ox1984 to the RST register to keep everything > alive.Silly question, but "periodically" = inside an ISR?
Reply by ●September 13, 20062006-09-13
"larwe" <zwsdotcom@gmail.com> wrote in message news:1158162298.377449.158910@m73g2000cwd.googlegroups.com...> > Tom Lucas wrote: > >> 2) Write 0x1984 to the watchdog RST register to seed the counter. >> (Goodness knows why they chose that value) > > It's probably the lead developer's dog's birthday written in base 9 > and > shown as a hex number. Almost certainly there is an ex post facto > explanation as to why it is the technically sound choice.Either that or it was the last time that the UART documentation was updated :-)>> Then I periodically write Ox1984 to the RST register to keep >> everything >> alive. > > Silly question, but "periodically" = inside an ISR?No no. I had initially headed off on that route before the little voice in the back of my head smacked the bigger voice on the back of its head for being so stupid. The GUI I use is a polled system and I call the watchdog refresher whenever I update the GUI, which is pretty much all the time.
Reply by ●September 13, 20062006-09-13
larwe wrote:> Tom Lucas wrote: > > >>2) Write 0x1984 to the watchdog RST register to seed the counter. >>(Goodness knows why they chose that value) > > > It's probably the lead developer's dog's birthday written in base 9 and > shown as a hex number. Almost certainly there is an ex post facto > explanation as to why it is the technically sound choice. > > >>Then I periodically write Ox1984 to the RST register to keep everything >>alive. > > > Silly question, but "periodically" = inside an ISR? >Oh honestly Lewin, where else would you kick the dog? Do you know of any really good discussions of the care and feeding* of watchdogs? Where I've seen it done well it involved _all_ of the critical tasks setting a bit in a variable, then an ISR that would check for all the bits set, then reset the variable and kick the dog if they were. The nice thing about this is that you couldn't have one bit of software that would function correctly and kick the dog while the rest of the system went to hell in a handbasket. * In one of your many books, perhaps? -- Tim Wescott Wescott Design Services http://www.wescottdesign.com Posting from Google? See http://cfaj.freeshell.org/google/ "Applied Control Theory for Embedded Systems" came out in April. See details at http://www.wescottdesign.com/actfes/actfes.html
Reply by ●September 13, 20062006-09-13
On Wed, 13 Sep 2006 08:57:04 -0700, Tim Wescott wrote:> larwe wrote: > >> Tom Lucas wrote: >> >> >>>2) Write 0x1984 to the watchdog RST register to seed the counter. >>>(Goodness knows why they chose that value) >> >> >> It's probably the lead developer's dog's birthday written in base 9 and >> shown as a hex number. Almost certainly there is an ex post facto >> explanation as to why it is the technically sound choice. >> >> >>>Then I periodically write Ox1984 to the RST register to keep everything >>>alive. >> >> >> Silly question, but "periodically" = inside an ISR? >> > Oh honestly Lewin, where else would you kick the dog?I just went through this in a discussion on a problem I was having with a watchdog. http://groups.google.com/group/comp.arch.embedded/browse_thread/ thread/35948d0883e635ad/84a165731af5c03d?lnk=st&q=&rnum=1&hl =en#84a165731af5c03d You'll need to put the link back together. Short answer is that the prgram may go to hell but the interrupt may continue working fin for every. -- Linux Home Automation Neil Cherry ncherry@linuxha.com http://www.linuxha.com/ Main site http://linuxha.blogspot.com/ My HA Blog http://home.comcast.net/~ncherry/ Backup site
Reply by ●September 13, 20062006-09-13
"Tim Wescott" <tim@seemywebsite.com> wrote in message news:jsSdnfa-rLSht5XYnZ2dnUVZ_rudnZ2d@web-ster.com...> larwe wrote: > >> Tom Lucas wrote: >> >> >>>2) Write 0x1984 to the watchdog RST register to seed the counter. >>>(Goodness knows why they chose that value) >> >> >> It's probably the lead developer's dog's birthday written in base 9 >> and >> shown as a hex number. Almost certainly there is an ex post facto >> explanation as to why it is the technically sound choice. >> >> >>>Then I periodically write Ox1984 to the RST register to keep >>>everything >>>alive. >> >> >> Silly question, but "periodically" = inside an ISR? >> > Oh honestly Lewin, where else would you kick the dog?Perhaps the interrupt idea isn't so crazy after all. Perhaps if I had a counter running in a timer ISR which caused a branch to zero at a certain level could be a dirty hack to get around the problem? Seems a shame when a chap at Sharp has spent at least a morning designing a nice watch dog.> Do you know of any really good discussions of the care and feeding* of > watchdogs? Where I've seen it done well it involved _all_ of the > critical tasks setting a bit in a variable, then an ISR that would > check for all the bits set, then reset the variable and kick the dog > if they were. The nice thing about this is that you couldn't have one > bit of software that would function correctly and kick the dog while > the rest of the system went to hell in a handbasket.Neat trick. Another one noted for future use :-)
Reply by ●September 13, 20062006-09-13
"Neil Cherry" <njc@cookie.uucp> wrote in message news:slrneggbgi.l69.njc@cookie.uucp...> On Wed, 13 Sep 2006 08:57:04 -0700, Tim Wescott wrote: >> larwe wrote: >> >>> Tom Lucas wrote: >>> >>> >>>>2) Write 0x1984 to the watchdog RST register to seed the counter. >>>>(Goodness knows why they chose that value) >>> >>> >>> It's probably the lead developer's dog's birthday written in base 9 >>> and >>> shown as a hex number. Almost certainly there is an ex post facto >>> explanation as to why it is the technically sound choice. >>> >>> >>>>Then I periodically write Ox1984 to the RST register to keep >>>>everything >>>>alive. >>> >>> >>> Silly question, but "periodically" = inside an ISR? >>> >> Oh honestly Lewin, where else would you kick the dog? > > > I just went through this in a discussion on a problem I was having > with a watchdog. > > http://groups.google.com/group/comp.arch.embedded/browse_thread/ > thread/35948d0883e635ad/84a165731af5c03d?lnk=st&q=&rnum=1&hl > =en#84a165731af5c03d > > You'll need to put the link back together. > > Short answer is that the prgram may go to hell but the interrupt > may continue working fin for every. >I think my kicking mechanism works, I just need it to notice when I stop kicking!
Reply by ●September 13, 20062006-09-13
Neil Cherry wrote:> On Wed, 13 Sep 2006 08:57:04 -0700, Tim Wescott wrote: > >>larwe wrote: >> >> >>>Tom Lucas wrote: >>> >>> >>> >>>>2) Write 0x1984 to the watchdog RST register to seed the counter. >>>>(Goodness knows why they chose that value) >>> >>> >>>It's probably the lead developer's dog's birthday written in base 9 and >>>shown as a hex number. Almost certainly there is an ex post facto >>>explanation as to why it is the technically sound choice. >>> >>> >>> >>>>Then I periodically write Ox1984 to the RST register to keep everything >>>>alive. >>> >>> >>>Silly question, but "periodically" = inside an ISR? >>> >> >>Oh honestly Lewin, where else would you kick the dog? > > > > I just went through this in a discussion on a problem I was having > with a watchdog. > > http://groups.google.com/group/comp.arch.embedded/browse_thread/ > thread/35948d0883e635ad/84a165731af5c03d?lnk=st&q=&rnum=1&hl > =en#84a165731af5c03d > > You'll need to put the link back together. > > Short answer is that the prgram may go to hell but the interrupt > may continue working fin for every. >Well, if you read the rest of the post it'll be clear that I had my tongue in my cheek. Serious use of a watchdog timer must be approach _very_ carefully, unless the processor is only doing one thing. Even if you don't have interrupts turned on or an RTOS, you can still build your software so that some aspects fail while others work. You need to make sure that if a reset needs to happen it does, and don't just assume that because something somewhere kicks the watchdog periodically that everything will be fine. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com Posting from Google? See http://cfaj.freeshell.org/google/ "Applied Control Theory for Embedded Systems" came out in April. See details at http://www.wescottdesign.com/actfes/actfes.html
Reply by ●September 13, 20062006-09-13
Tim Wescott wrote:> Do you know of any really good discussions of the care and feeding* of > watchdogs? Where I've seen it done well it involved _all_ of theI haven't written anything formally on the topic, but it has been discussed here many times. One of the techniques I've used is to have an entry counter in each thread. At regular intervals (in an ISR), these counters are checked. If they fall within guard bands [which may have to be pretty wide], the WDT is kicked; otherwise, bite. Ganssle has some excellent material on the topic, of course.
Reply by ●September 13, 20062006-09-13
"Tom Lucas" <news@REMOVE_auto_THIS_flame_TO_REPLY.clara.co.uk> wrote in message news:1158161579.6562.0@proxy00.news.clara.net...> I've been trying to implement the watchdog timer on my Sharp79524 and it > appears that the mutt is sleeping on the job!I'm using a 75410, which has a watchdog that looks the same. I don't use it because it is only any use in faulty software and if I had faulty software why would I expect the watchdog code to be any better. However, I can test it out.> I believe I have it set up to trigger after about 3s of inactivity but > it doesn't seem to reset the system at all. > > My setup method is as follows: > 1) Write 0x00000090 to the watchdog CTL to set up for 2^25 counts of > HCLK as the timeout period. This also stops an interrupt on first > timeout occurring and should set up for an immediate reset. Watchdog not > enabled at this pointFor me 2^25 counts is 0.65 seconds.> 2) Write 0x1984 to the watchdog RST register to seed the counter. > (Goodness knows why they chose that value) > > 3) OR 0x00000001 onto the CTL register to enable the watchdog. > > 4) OR 0x00000008 onto the CTL regsiter to lock the enable.Yep, reset after a fraction of a second. Using a larger period gave the expected results.> Then I periodically write Ox1984 to the RST register to keep everything > alive. > > Then if I encounter a while(1); that I've planted somewhere then the > system hangs but no reset ever happens. > > Is there something I've missed? The watchdog section of the user guide > was only a few pages so it would appear to be "simple" but perhaps there > are other things that affect it's operation? > > I've tried running under the debugger and also stand-alone from flash in > case that made any difference but it doesn't seem to. > > Any ideas?I poked 0x90, 0x91 and 0x98 rather than oring but other... Peter
