Trouble figureing out WATCHDOG

natpie

I'm working on a battery/solar powered weather station. I'm trying to get it to take the measurements, transmit them then sleep for the 2.3 seconds.

so I've added watchdog to my device string. I've added mov !option #%11111111 to my code. My understanding is this will turn on watch dog with the longest prescaler, about 2.3 seconds. So in my code I have a line that turns on a pin and then turns it off just before a sleep command is issued.

When I boot the sx my debug pin goes hi. runes my code that takes about 1 second, then goes low. It never goes high again, and I'm not sure what I've missed.

This is my first project using SX/B so I'm including my code in case I've made a really stupid mistake that is holding me up.

mojorizing

In your IO pins section try this:

 -------------------------------------------------------------------------
' IO Pins
' -------------------------------------------------------------------------
Comout  pin RB.0 input
Transmiter pin RB.1 input
Annanom  pin RA.0 input
WeVane  pin RA.1 input
RainCheck pin RA.2 input
RainReset pin RA.3 output
Bncchk  pin RC.0 output

then delete this:

INPUT Comout
INPUT Transmiter
INPUT Annanom
INPUT WeVane
INPUT RainCheck
OUTPUT RainReset
OUTPUT Bncchk

·I ran your program with a lot of the code commented out, and that is what it took to make it run consistently, among other things, but I think it's the main reason.· Also, to use SEROUT you'll need to use a 4 mhz crystal for accurate timing, thus changing the DEVICE OSC4MHZ to OSCXT2.

Hope this helps,
Kevin

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Bad spellers of the world untie!

Bean

Natpie,
· When the watchdog resets the SX, all I/O pins are INPUTS. So you either need to tell SX/B their direction, or allow the code to run that sets their direction.

P.S. You also don't need the code at the bottom that handles code pages. That is handled automatically by SX/B now.

Bean.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
·The next time you need a hero don't look up in the sky...Look in the mirror.




Post Edited (Bean (Hitt Consulting)) : 1/19/2009 7:17:10 PM GMT

mojorizing

I was going to add that in case a process in your code is suspectible of running beyond the WDT period, and your unable to reset it in a timely fashion ( your embedded in the SXB somewhere), you can·clr option.3 assigning the prescaler to RTCC, and be sure to disable RTCC roll-over.· Then just re-assign option.3 to the WDT just before SLEEP.· You using the WDT to wake up from·the end of a·sleep period, and not in the usual role to stop a condition where the processor is in a run-away condition. That might not pertain here, but it's an option..

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Bad spellers of the world untie!

natpie

Thanks for the help every one. It looks like the all pins to input on watchdog timeout is what was killing me here. I've modified my code to set my pin directions immediately at boot, then determine if it is a warm or cold boot. Things seem to be working as expected now.

I am however noticing a 15.5ms period presumably at boot where I'm still not reading the correct values on the outputs. I assume this is normal for a Watchdog restart? Is there something to be done about this. It's not a problem in my code as I run count for 1 second guaranteeing at least 1 second before my serout code is run. Even if this blip is detected as a start bit I'll be well past it before my real serial is transmitted. Had I planed on sending some asynchronous serial right at boot I could see this potently interfering. As I said not a problem for my current project but I'm curious for future reference.

mojorizing

That 16ms waking-up period is normal, and no way around it.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Bad spellers of the world untie!

natpie

I figured as much but figured I might as well ask. No point in proceeding down a course of ignorance if someone has found a nifty solution.

And thanks again to everyone for the prompt help. No support form have I ever been to has been as helpful, and prompt as the parallax forms.

dkemppai

natpie said...
Thanks for the help every one. It looks like the all pins to input on watchdog timeout is what was killing me here. I've modified my code to set my pin directions immediately at boot, then determine if it is a warm or cold boot. Things seem to be working as expected now.

I am however noticing a 15.5ms period presumably at boot where I'm still not reading the correct values on the outputs. I assume this is normal for a Watchdog restart? Is there something to be done about this. It's not a problem in my code as I run count for 1 second guaranteeing at least 1 second before my serout code is run. Even if this blip is detected as a start bit I'll be well past it before my real serial is transmitted. Had I planed on sending some asynchronous serial right at boot I could see this potently interfering. As I said not a problem for my current project but I'm curious for future reference.

As·for output values, I've seen this before.·I've been trying for years to get anyone to listen up!

If you carefully read the SX Reset document... (http://www.parallax.com/Portals/0/Downloads/appnt/sx/An18Reset.pdf)
You will notice that when waking up from a sleep condition, the pins are set as inputs. As such, the register values for the pins are lost.

To maintain output states through a sleep/watchdog cycle, you basically will have to do the following:
1. You will need to buffer your outputs to some memory locations, before you put the processor to sleep.
2. Then when you wake up, you will have to restore the outputs from the memory locations you saved them to
after·you wake up.
Note: The outputs will be undefined for the ~16mS wakeup period of the SX chip.

Very low sleep mode currents can be attained this way (<10uA), but the output states not being remembered can be troublesome.

Try write a simple program·that toggles an output pin, sets the watchdog timer, and then puts the SX to sleep...·· ...see what happens when you run it.

-Dan


▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

"A saint-like quantity of patience is a help, if this is unavailable, a salty vocabulary works nearly as well." - A. S. Weaver

mojorizing

I hear you, Dan
·

This related post highlights your point.
http://forums.parallax.com/showthread.php?p=568432

I haven't delved deeper into this because I've never used the sleep function. Microsoft has a saying which might be appropriate here... "it's not a bug, it's a feature!"

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Bad spellers of the world untie!

pjv

Hi All;

A bit about waking up from sleep.

There are things you can do about getting a faster wakeup than the standard 18 mSec (at least with the SX 48).

Set the WDTReset directive to WDRT006 and that will give you an 250 uSec wakeup.

And furthermore, here is a little undocumented trick; if you enable the watchdog timer (to any setting I believe, but I'm not positive of that....I use the slowest setting) then that 250 uSec shrinks to approximately 60 uSec.

And that's a LONG way from 18 mSec!

Cheers,

Peter (pjv)

natpie

Okay I've had some time to clean things up, and the PIN direction change at watchdog reset no longer seems to be causing my flip flip to reset during reboot. After playing with SX/B I caught on to the idea of setting the bit before changing it to output as is done with the HIGH and LOW commands. SX/B was also burning me as I didn't realize the INPUT and OUTPUT commands rely on $FA $FB $FC, etc. to change the bit. My initialization code was erasing all ram and fowling up pin direction registers.

Now does the watchdog reset have any other tricky things waiting to mess me up or are the all pins to input and 15.5MS reboot time the only unusual events I will need to watch out for?