I'm losing my mind with the timer and I can't find out what I'm doing
wrong. I have an 8051 (Atmel 89C2051 really), Xtal = 11.059200 MHz and
a DS1232 (watchdog chip). What I need to do is to pulse (active low)
the strobe line on the DS1232 to keep the 8051 from getting reset. My
understanding of the timer is 1/(XTAL/12) = 1.085 us per tic. If I run
timer 0 in mode 1 (16 bit) it will interrupt every 71.113ms (max). If
I wait for 2 interrupts (I need between 62.5ms and 250ms before a
reset can occur) I can pulse the strobe (1-0-1) and I should be happy.
Does the above sound correct or do I have a hole in my logic? If the
above sounds correct I can post my code to see if I'm doing something
wrong there.

Thanks

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

Neil Cherry wrote:
What exactly is "wrong"? Are you getting the timer interrupts, and
outputting a strobe to the DS1232? If so, what is the time between
strobes, and the "on" (low) time? You talk about waiting for 2
interrupts. If you are strobing the DS1232 every 142ms you are outside
the minimum required timing for the chip, which is 62.5ms (for TD
grounded, which apparently is your situation based on your figures of
62.5ms and 250ms).

On 9 Sep 2006 10:32:13 -0700, Mike Silva wrote:
Oh, that would be a good thing for me to describe. I can't watch the
time interval (no scope). I have a volt meter which gives frequency
but I doubt it's doing me much good (say 42KHz). The basic problem is
that the chip is reseting. I see the start up message approximately
every second. It looks like I'm getting no interrupt. If I run the
8051 w/o the DS1232 I can manually reset it and the rest of the
program runs OK. I guess I could fall back on 'print' statements to
see if the interrupt is being run (I also have RS232 which is working
w/o interrupts at this time.

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

Neil Cherry wrote:
If you have a two extra I/O lines, connect some LEDs to them (you might
need to buffer them). Toggle one in the interrupt routine, and toggle
the other every time you do a high-to-low transition out to the DS1232.
By toggling you'll get square waves that you can actually see at these
frequencies. You'll be able to tell if your interrupt is being
serviced, and what your strobe rate to the DS1232 is. Again, if you're
waiting 142ms between strobes you're out of spec for the part -- you
need to guarantee a strobe every 62.5ms.

And be sure and save up for a scope or logic analyser of some sort.

Neil Cherry wrote:
do you have enabled the timer0 interrupt ?
do you have enabled the general interrupt enable ?
do you have enabled the timer ( is the timer running ? ) ?

two leds and a 74hc00 can be used to build a simple logic tester

Neil Cherry <njc@cookie.uucp> wrote:
Setting aside your problems with wrapping your head around how to
steer a timer: petting the watchdog is no job for a timer. You want
to inform the watchdog that your main program still runs, not that
some timer survived a total crash of program.

--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

On 9 Sep 2006 19:49:53 GMT, in comp.arch.embedded Hans-Bernhard
Broeker <broeker@physik.rwth-aachen.de> wrote:

Ah, I remember hearing of a 805x crashing, but the timer kept working,
so it did not reset, which tickled the WD. Is this what you meant?

ISTR Jack Gannsle having some good stuff on his site


martin

martin griffith <mart_in_medina@yahoo.esxxx> wrote:
Not quite. You have the last two items the wrong way round. The
problematic case is this: the main app crashes (e.g. got stuck in an
endless loop waiting for some event that can't happen), but the timer
interrupts kept working, which keeps tickling the 'dog, so the CPU
never gets reset.

A setup like that wastes any money, time and board space spent on the
WD for no effect.

--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

Neil Cherry wrote:
If you have a Frequency Multimeter, then simply toggle a pin in the
interrupt, and remove the 1232 reset line, while you are testing.
That tells you both that the INT is alive, and you can easily
calculate what the INT rate is ( half cycle = int time ).

Of course, you do realise that using a timer interrupt to ping a
watchdog, will miss a whole raft of possible system failures ?

-jg

On Sun, 10 Sep 2006 09:26:35 +1200, Jim Granville wrote:
This is what I have but the battery is getting low and I'm not sure it
working properly. I'll get a new battery tomorrow and remove that
doubt.

Actually yes but I first need to resolve the timer issue before I can
attack that code. :-) I had step back to basics to find the problem.

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

On 9 Sep 2006 21:02:26 GMT, Hans-Bernhard Broeker wrote:
To everyone (this is not direct at Hans-Bernhard):

Something is wrong in my program and I need to resolve that. I fell
back to a simple RS232 program with hello and echo. The DS1232 was put
on timer 0 to simplify things. What I discovered is that I have a
problem with my timer. To make matters odder, I had this working with
just one pass of the timer 0 interrupt. When I tried it again it
failed (???). At that point I decided to simplify.

What I'd like to do with the final program is to keep the timer with
the WD but set a message in the main program. If the main program
fails the message won't be set, then the WD won't be tickled. This
will gaurantee the I get a tickle between 62.5 ms and 250 ms if the
program is working. But for now I needed to simplify. This is not the
final program.


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

Neil Cherry wrote:
This is really a job for a 'scope or a logic analyzer. Even one of
those inexpensive USB based logic analyzers is likely to be more
illuminating that periodic resets.

I've not used them so I don't know how good they are but something like
the ant8 at ~U$200 will pay for itself pretty quickly even if it's only
halfways decent. Others here have probably used a few different ones
and may be able to recommend something inexpensive. If it's a
commercial project you'll eat up that much on your time pretty quickly.

Of course if you insist on a linux version you might have to do more
searching. Windows usually has a cost advantage here.

Robert

Neil Cherry <njc@cookie.uucp> wrote:

Good plan --- but how do you expect anybody to be able to help you
with what's wrong in that program, if you don't show the program?

Even done this way, it's still a waste of a timer. It would be a good
deal simpler to just tickle the WD directly, in the place of the main
code where you now plan to "set a message".

Your WD can be tickled as fast as you like, i.e. even a brutally
simple

while(1) {
WD_PIN = 1; WD_PIN = 0;
}

would work.


--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

On 10 Sep 2006 09:35:12 GMT, Hans-Bernhard Broeker wrote:
OK, now I feel stupid. I thought the minimum time meant you can't send
a tickle before that time so I've been working on the assumption I
need to send a tickle between 62.5ms and 250ms (now you see why I
needed a timer). I can now just stick the tickle in the main loop (no
timer) and let it do it's work. I actualy have that version working
but since I didn't understand why it worked I couldn't consider it
valid (a fix without understanding is just voodoo, not acceptable).
BTW, the actual chip is the MAX1232. I just read the Dallas app note
144 which explains things a lot better (exactly what you pointed out
above).

I'll be back with more information about the timer problem as that is
what the original post is about and I'm still not sure where the
problem is.

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

Neil Cherry wrote:
OK, that explains why you were talking about every 2nd interrupt. Yes,
the trick is to tickle the WD as fast or faster than (in your
situation) once every 62.5ms. The other trick is to make sure that
_all_ your validation checks are met before giving a new tickle. All
your checks can simply mean "I'm at this point in the main loop" or it
can mean more. A typical strategy is to set a batch of flags after the
WD has been tickled, and have a different flag cleared at every point
in the program you want to monitor. Only when all the flags are
cleared does the WD get tickled again, and the process starts over.
This way you can check that all your tasks are running, your IO is
working, etc. Just assure yourself that each flag will always get
cleared in a timely manner when your program is running correctly, and
that you check the flags often enough to guarantee that the WD is
tickled in time after the last flag gets cleared.

"Neil Cherry" <njc@cookie.uucp> wrote in message
news:slrneg81ca.cic.njc@cookie.uucp...
I know the MAX/DS1232 well; it's my watchdog/reset controller of choice in
most of my designs over the last few years.

As others have said, using a timer to kick the watchdog both ways is the
wrong way of going about things.

My strategy is fairly classic. I pretty much always have a heartbeat
interrupt running, i.e. a timer interrupt every (say) 5ms. I use this to
update any software timers I need. My top level code is based on a
round-robin, i.e. an infinite loop.

So I set the watchdog I/O pin one way within the timer interrupt [1], and
set it the other way at the top of my round-robin loop. This ensures that
the watchdog is aware that a) the top-level code is running and b)
interrupts are running. This strategy also has the nice side effect that I
can watch the I/O line with a scope, and get an idea of system loading from
the mark/space ratio of the signal [2].

[1] Beware of doing *any* I/O from within interrupts - there be dragons. In
this case I get away with it by ensuring that all I/O operations for the
particular port I'm using are atomic.

[2] None of my software tasks pend (not a good thing to do in a cooperative
multitsker ). Therefore there are no other places where I need to kick the
watchdog. If you have lengthy tasks that could outlast the watchdog
interval, you'll either need to duplicate the top-level kick, or better
still, do as I do and turn them into state machines, and give control back
to the round-robin sooner.

Steve
http://www.fivetrees.com

Neil Cherry wrote:
Some watchdog timers work in that fashion but not most. They do offer
some extra security by protecting against something that resets the
watchdog in a short endless loop.

Robert

On 10 Sep 2006 07:27:52 -0700, Mike Silva wrote:
This program is pretty simple take in some bytes from the serial and
display them (LEDs). The tickle lives in the main loop. Things will
get interesting in the next go around when the board will need to
receive data, process it (I/O) and respond back. Then the timer will
be more important. This will be one of my basic comm-link modules for
the HCS (a Home Control System - http://hcs.sourceforge.net/ - I need
to update the web page).


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

Steve at fivetrees wrote:
used. They don not read,modify,write. and are atomic.
Of course masking would not be atomic.