Thanks Brendan,
This is the right approach surely. I'm at that state now and have no
other alternative then to back a bit and go through this "the right
way". I just have myself to blame. Have used watchdogs for many years on
PIC, AVR and other processors and expected no problem there except for
the usual forgetting to feed it in certain places. Oh well it's my first
project on this processor family so this makes me learn useful stuff
just as you write (just a bit hard to appreciate that right now ;-) ).
Really need the watchdog to work in this application though so there is
no shortcut.
I just debug using GPIO pins and one of the serial ports at the moment
so there is no emulator connected now.
Thanks for your tips, suggestions and moral support. I report my
findings back.
/Ake
brendanmurphy37 wrote:
>
> Ake,
>
> I can almost feel your frustration: we've all been there!
>
> I'm very interested in the outcome of this, as our own task for
next
> week is to get the watchdog working on our own LPC2134-based system.
>
> I'm a bit surprised that no one has volunteered some working code.
> Surely someone out there is using this?
>
> Unfortunately, as we haven't got there yet, I've nothing specific
to
> suggest, other than a general strategy of getting something simple
> working first, and then building up to where you are. For example:
>
> 1. As simple as possible startup, initialisation (all peripherals
> disabled, all interrupts off etc.) and an application that
> initialises the watchdog and uses GPIO to signal what it's doing
(and
> maybe reads to indicate whether or not the watchdog should be fed).
> In other words, the simplest possible program with a working
> watchdog.
>
> 2. Same program, but with your normal initialisation and setup code,
> added incrementally. Still working?
>
> 3. Compare and contrast with your real application, particularly in
> how peripherals, interrupts etc. are managed.
>
> In other words, get something simple working first, and build up from
> there. It'll take time, but maybe less time then starting from a
> larger system that doesn't work.
>
> Hopefully, somewhere along the line, all will become obvious.
>
> By the way, are you running your code using an emulator connected?
> I've seen strange behaviour in the past with watchdogs enabled. Try
> running stand-alone, if you haven't done so already.
>
> As a final suggestion, based on what you say below, I'd look very
> carefully at every location interrupts are enabled/disabled (at the
> peripheral level, at the VIC and at the CPSR). Also at your startup
> and IRQ dispatch code. Maybe the processor is resetting and re-
> initialising stuff without you realising? maybe throwing an exception
> you haven't noticed?
>
> As a final comment: 'though no doubt it feels like it, it's not
time
> wasted: you'll know way more about the watchdog and processor at
the
> end of all this then when you started.
>
> Good luck!
>
> Brendan
> --- In lpc2000@lpc2..., "Ake Hedman, eurosource"
<akhe@b...>
> wrote:
> >
> > WD story update
> >
> > I changed the code to have the watchdog raising an IRQ instead of a
> > RESET. I initialize stuff and then go in in a while loop.
> >
> > 1.) With interrupts enabled but no interrupt channel active this
> will
> > not trigger the watchdog. Why?
> >
> > 2.) With one of the interrupt channels active ( UART0 writing some
> > characters ) the watchdog works. Without a dog feed the watchdog is
> > triggered and with a feed it runs fine. However what I initialize
> WDTC
> > with does to seem to matter. I always get about 4 ms period when I
> > toggle a pin in the WD interrupt (60MHz clock).
> >
> > Is this behaviour recognized by anyone? Please!
> >
> > BTW the chip is LPC2138
> >
> > /Ake
> >
> >
> > dr_danish_ali wrote:
> >
> > > Ok Ake, here's my dumb suggestion:
> > >
> > > Try enabling the watchdog, but just to interrupt not reset?
> > > You'll need an interrupt handler / VIC channel to do it -
can you
> > > spare one?
> > > That ISR need just raise a flag for now.
> > >
> > > Once the watchdog is fed and running happily, you might then
be
> able
> > > to enable resets on
> > > it.
> > >
> > > Hope this helps,
> > > Danish
> > >
> > > --- In lpc2000@lpc2..., "Ake Hedman, eurosource"
> <akhe@b...>
> > > wrote:
> > > >
> > > > I am still trying to solve my problems with the watchdog.
> > > >
> > > > I have now scaled away most stuff of my application and can
see
> that
> > > the
> > > > problem occurs when either of three interrupts occur
> (UART0/UART1/I2C0)
> > > > in the system. Without the watchdog everything works fine
but
> if I
> > > > enable the watchdog everything crashes. I have tried to
just
> enable and
> > > > trig one of the interrupts in turn but the situation is
the
> same.
> > > >
> > > > I'm totally out of clues at the moment so any (also
things that
> > > might be
> > > > considered dumb) are very welcome.
> > > >
> > > > Regards
> > > > /Ake
> > >
> > >
> > >
> > >
> > >
> > > SPONSORED LINKS
> > > Microprocessor
> > > <http://groups.yahoo.com/gads?
>
t=ms&k=Microprocessor&w1=Microprocessor&w2=Microcontrollers&w3=Pic+mic
> rocontrollers&w451+microprocessor&c=4&s&.sig=tsVC-
> J9hJ5qyXg0WPR0l6g>
> > > Microcontrollers
> > > <http://groups.yahoo.com/gads?
>
t=ms&k=Microcontrollers&w1=Microprocessor&w2=Microcontrollers&w3=Pic+m
>
icrocontrollers&w451+microprocessor&c=4&s&.sig=DvJVNqC_pqRTm8Xq0
> 1nxwg>
> > > Pic microcontrollers
> > > <http://groups.yahoo.com/gads?
>
t=ms&k=Pic+microcontrollers&w1=Microprocessor&w2=Microcontrollers&w3=P
>
ic+microcontrollers&w451+microprocessor&c=4&s&.sig=TpkoX4KofDJ7c
> 6LyBvUqVQ>
> > >
> > > 8051 microprocessor
> > > <http://groups.yahoo.com/gads?
>
t=ms&k51+microprocessor&w1=Microprocessor&w2=Microcontrollers&w3=Pi
>
c+microcontrollers&w451+microprocessor&c=4&s&.sig=1Ipf1Fjfbd_HVI
> lekkDP-A>
> > >
> > >
> > >
> > > ------------------------------
> ------
> > > >.
> > >
> > >
> > > ------------------------------
> ------
> > >
> >
> >
> > --
> > ---
> > Ake Hedman (YAP - Yet Another Programmer)
> > eurosource, Brattbergavägen 17, 820 50 LOS, Sweden
> > Phone: (46) 657 413430 Cellular: (46) 73 84 84 102
> > Company home: http://www.eurosource.se
> > Kryddor/Te/Kaffe: http://www.brattberg.com
> > Personal homepage: http://www.eurosource.se/akhe
> > Automated home: http://www.vscp.org
> >
> >
> >
> >
>
>
> >.
>
>
--
---
Ake Hedman (YAP - Yet Another Programmer)
eurosource, Brattbergavägen 17, 820 50 LOS, Sweden
Phone: (46) 657 413430 Cellular: (46) 73 84 84 102
Company home: http://www.eurosource.se
Kryddor/Te/Kaffe: http://www.brattberg.com
Personal homepage: http://www.eurosource.se/akhe
Automated home: http://www.vscp.org
Problem with watchdog
Started by ●December 6, 2005
Reply by ●December 8, 20052005-12-08
Reply by ●December 8, 20052005-12-08
Ake,
Thanks for your comments.
I'm not sure if you want to hear this or not, but we've just put in
support for the watchdog. It worked first time, with no problems.
Code is below: two functions, one called as part of startup sequence,
the other called from a watchdog task that's scheduled every second.
If we spin in a loop locking out all other tasks, the system is reset
as expected.
Our system has several sources of interrupt enabled (both UARTs, I2C
etc.): it works regardless of what's happeneing elsewhere.
By the way, we use GCC 3.3.1 with -O2 to compile.
Regards
Brendan
=========================================
CODE STARTS HERE:
#define REG(addr) (*(volatile unsigned int *)(addr))
#define WDOG_BASE (0xE0000000)
#define WDOG_WDMOD (0xE0000000)
#define WDOG_WDTC (0xE0000004)
#define WDOG_WDFEED (0xE0000008)
#define WDOG_WDTV (0xE000000C)
/* define basic watchdog timeout value as 100 ms */
#define WATCH_TIMER_100MS (250000) /* 10 MHz / 4 is i/p clock */
/*
* Configure and start watchdog
*/
static
void watchdog_init(void)
{
/* set the watchdog timer constant */
REG(WDOG_WDTC) = WATCH_TIMER_100MS * (50); /* 5 seconds for now */
/* set mode to reset on underflow */
REG(WDOG_WDMOD) = 0x3;
/* feed watchdog to start it off */
REG(WDOG_WDFEED) = 0xaa;
REG(WDOG_WDFEED) = 0x55;
return;
}
/*
* Feed the watchdog to prevent us from being reset
*/
void HwWatchdogFeed(void)
{
/* write the magic sequence to keep the dog happy */
REG(WDOG_WDFEED) = 0xaa;
REG(WDOG_WDFEED) = 0x55;
return;
}
END OF CODE
========================================
--- In lpc2000@lpc2..., "Ake Hedman, eurosource" <akhe@b...>
wrote:
>
> Thanks Brendan,
>
> This is the right approach surely. I'm at that state now and have
no
> other alternative then to back a bit and go through this "the right
> way". I just have myself to blame. Have used watchdogs for many
years on
> PIC, AVR and other processors and expected no problem there except
for
> the usual forgetting to feed it in certain places. Oh well it's my
first
> project on this processor family so this makes me learn useful
stuff
> just as you write (just a bit hard to appreciate that right now ;-
) ).
> Really need the watchdog to work in this application though so
there is
> no shortcut.
>
> I just debug using GPIO pins and one of the serial ports at the
moment
> so there is no emulator connected now.
>
> Thanks for your tips, suggestions and moral support. I report my
> findings back.
> /Ake > brendanmurphy37 wrote:
>
> >
> > Ake,
> >
> > I can almost feel your frustration: we've all been there!
> >
> > I'm very interested in the outcome of this, as our own task for
next
> > week is to get the watchdog working on our own LPC2134-based
system.
> >
> > I'm a bit surprised that no one has volunteered some working code.
> > Surely someone out there is using this?
> >
> > Unfortunately, as we haven't got there yet, I've nothing specific
to
> > suggest, other than a general strategy of getting something simple
> > working first, and then building up to where you are. For example:
> >
> > 1. As simple as possible startup, initialisation (all peripherals
> > disabled, all interrupts off etc.) and an application that
> > initialises the watchdog and uses GPIO to signal what it's doing
(and
> > maybe reads to indicate whether or not the watchdog should be
fed).
> > In other words, the simplest possible program with a working
> > watchdog.
> >
> > 2. Same program, but with your normal initialisation and setup
code,
> > added incrementally. Still working?
> >
> > 3. Compare and contrast with your real application, particularly
in
> > how peripherals, interrupts etc. are managed.
> >
> > In other words, get something simple working first, and build up
from
> > there. It'll take time, but maybe less time then starting from a
> > larger system that doesn't work.
> >
> > Hopefully, somewhere along the line, all will become obvious.
> >
> > By the way, are you running your code using an emulator connected?
> > I've seen strange behaviour in the past with watchdogs enabled.
Try
> > running stand-alone, if you haven't done so already.
> >
> > As a final suggestion, based on what you say below, I'd look very
> > carefully at every location interrupts are enabled/disabled (at
the
> > peripheral level, at the VIC and at the CPSR). Also at your
startup
> > and IRQ dispatch code. Maybe the processor is resetting and re-
> > initialising stuff without you realising? maybe throwing an
exception
> > you haven't noticed?
> >
> > As a final comment: 'though no doubt it feels like it, it's not
time
> > wasted: you'll know way more about the watchdog and processor at
the
> > end of all this then when you started.
> >
> > Good luck!
> >
> > Brendan
> >
> >
> > --- In lpc2000@lpc2..., "Ake Hedman, eurosource"
<akhe@b...>
> > wrote:
> > >
> > > WD story update
> > >
> > > I changed the code to have the watchdog raising an IRQ instead
of a
> > > RESET. I initialize stuff and then go in in a while loop.
> > >
> > > 1.) With interrupts enabled but no interrupt channel active this
> > will
> > > not trigger the watchdog. Why?
> > >
> > > 2.) With one of the interrupt channels active ( UART0 writing
some
> > > characters ) the watchdog works. Without a dog feed the
watchdog is
> > > triggered and with a feed it runs fine. However what I
initialize
> > WDTC
> > > with does to seem to matter. I always get about 4 ms period
when I
> > > toggle a pin in the WD interrupt (60MHz clock).
> > >
> > > Is this behaviour recognized by anyone? Please!
> > >
> > > BTW the chip is LPC2138
> > >
> > > /Ake
> > >
> > >
> > > dr_danish_ali wrote:
> > >
> > > > Ok Ake, here's my dumb suggestion:
> > > >
> > > > Try enabling the watchdog, but just to interrupt not reset?
> > > > You'll need an interrupt handler / VIC channel to do it - can
you
> > > > spare one?
> > > > That ISR need just raise a flag for now.
> > > >
> > > > Once the watchdog is fed and running happily, you might then
be
> > able
> > > > to enable resets on
> > > > it.
> > > >
> > > > Hope this helps,
> > > > Danish
> > > >
> > > > --- In lpc2000@lpc2..., "Ake Hedman, eurosource"
> > <akhe@b...>
> > > > wrote:
> > > > >
> > > > > I am still trying to solve my problems with the watchdog.
> > > > >
> > > > > I have now scaled away most stuff of my application and can
see
> > that
> > > > the
> > > > > problem occurs when either of three interrupts occur
> > (UART0/UART1/I2C0)
> > > > > in the system. Without the watchdog everything works fine
but
> > if I
> > > > > enable the watchdog everything crashes. I have tried to just
> > enable and
> > > > > trig one of the interrupts in turn but the situation is the
> > same.
> > > > >
> > > > > I'm totally out of clues at the moment so any (also things
that
> > > > might be
> > > > > considered dumb) are very welcome.
> > > > >
> > > > > Regards
> > > > > /Ake
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > SPONSORED LINKS
> > > > Microprocessor
> > > > <http://groups.yahoo.com/gads?
> >
t=ms&k=Microprocessor&w1=Microprocessor&w2=Microcontrollers&w3=Pic+mic
> > rocontrollers&w451+microprocessor&c=4&s&.sig=tsVC-
> > J9hJ5qyXg0WPR0l6g>
> > > > Microcontrollers
> > > > <http://groups.yahoo.com/gads?
> >
t=ms&k=Microcontrollers&w1=Microprocessor&w2=Microcontrollers&w3=Pic+m
> >
icrocontrollers&w451+microprocessor&c=4&s&.sig=DvJVNqC_pqRTm8Xq0
> > 1nxwg>
> > > > Pic microcontrollers
> > > > <http://groups.yahoo.com/gads?
> >
t=ms&k=Pic+microcontrollers&w1=Microprocessor&w2=Microcontrollers&w3=P
> >
ic+microcontrollers&w451+microprocessor&c=4&s&.sig=TpkoX4KofDJ7c
> > 6LyBvUqVQ>
> > > >
> > > > 8051 microprocessor
> > > > <http://groups.yahoo.com/gads?
> >
t=ms&k51+microprocessor&w1=Microprocessor&w2=Microcontrollers&w3=Pi
> >
c+microcontrollers&w451+microprocessor&c=4&s&.sig=1Ipf1Fjfbd_HVI
> > lekkDP-A>
> > > >
> > > >
> > > >
> > > > --------------------------
----
> > ------
> > > > >.
> > > >
> > > >
> > > > --------------------------
----
> > ------
> > > >
> > >
> > >
> > > --
> > > ---
> > > Ake Hedman (YAP - Yet Another Programmer)
> > > eurosource, Brattbergavägen 17, 820 50 LOS, Sweden
> > > Phone: (46) 657 413430 Cellular: (46) 73 84 84 102
> > > Company home: http://www.eurosource.se
> > > Kryddor/Te/Kaffe: http://www.brattberg.com
> > > Personal homepage: http://www.eurosource.se/akhe
> > > Automated home: http://www.vscp.org
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> >
> > ------------------------------
------
> > >.
> >
> >
> > ------------------------------
------
> > --
> ---
> Ake Hedman (YAP - Yet Another Programmer)
> eurosource, Brattbergavägen 17, 820 50 LOS, Sweden
> Phone: (46) 657 413430 Cellular: (46) 73 84 84 102
> Company home: http://www.eurosource.se
> Kryddor/Te/Kaffe: http://www.brattberg.com
> Personal homepage: http://www.eurosource.se/akhe
> Automated home: http://www.vscp.org
Reply by ●December 8, 20052005-12-08
Brenda*n,*
thanks. It's really good to here that. Even if 99.999% of the problems
comes from the code we write ourselves it is still nice to take away
that 0.0001% that comes from problems in hardware.
I'm in the process of doing a new test project at the moment to try to
trace this down under a more controlled environment.
Thanks for taking the time to sharing this info. Much appreciated!
Cheers
/Ake
brendanmurphy37 wrote:
>
> Ake,
>
> Thanks for your comments.
>
> I'm not sure if you want to hear this or not, but we've just put in
> support for the watchdog. It worked first time, with no problems.
> Code is below: two functions, one called as part of startup sequence,
> the other called from a watchdog task that's scheduled every second.
> If we spin in a loop locking out all other tasks, the system is reset
> as expected.
>
> Our system has several sources of interrupt enabled (both UARTs, I2C
> etc.): it works regardless of what's happeneing elsewhere.
>
> By the way, we use GCC 3.3.1 with -O2 to compile.
>
> Regards
> Brendan
>
> =========================================
> CODE STARTS HERE:
>
> #define REG(addr) (*(volatile unsigned int *)(addr))
>
> #define WDOG_BASE (0xE0000000)
> #define WDOG_WDMOD (0xE0000000)
> #define WDOG_WDTC (0xE0000004)
> #define WDOG_WDFEED (0xE0000008)
> #define WDOG_WDTV (0xE000000C)
>
> /* define basic watchdog timeout value as 100 ms */
>
> #define WATCH_TIMER_100MS (250000) /* 10 MHz / 4 is i/p clock */
>
> /*
> * Configure and start watchdog
> */
>
> static
> void watchdog_init(void)
>
> {
> /* set the watchdog timer constant */
>
> REG(WDOG_WDTC) = WATCH_TIMER_100MS * (50); /* 5 seconds for now */
>
> /* set mode to reset on underflow */
>
> REG(WDOG_WDMOD) = 0x3;
>
> /* feed watchdog to start it off */
>
> REG(WDOG_WDFEED) = 0xaa;
> REG(WDOG_WDFEED) = 0x55;
>
> return;
> }
>
> /*
> * Feed the watchdog to prevent us from being reset
> */
>
> void HwWatchdogFeed(void)
>
> {
> /* write the magic sequence to keep the dog happy */
>
> REG(WDOG_WDFEED) = 0xaa;
> REG(WDOG_WDFEED) = 0x55;
>
> return;
> }
>
> END OF CODE
> ========================================
>
> --- In lpc2000@lpc2..., "Ake Hedman, eurosource" <akhe@b...>
> wrote:
> >
> > Thanks Brendan,
> >
> > This is the right approach surely. I'm at that state now and have
> no
> > other alternative then to back a bit and go through this "the right
> > way". I just have myself to blame. Have used watchdogs for many
> years on
> > PIC, AVR and other processors and expected no problem there except
> for
> > the usual forgetting to feed it in certain places. Oh well it's my
> first
> > project on this processor family so this makes me learn useful
> stuff
> > just as you write (just a bit hard to appreciate that right now ;-
> ) ).
> > Really need the watchdog to work in this application though so
> there is
> > no shortcut.
> >
> > I just debug using GPIO pins and one of the serial ports at the
> moment
> > so there is no emulator connected now.
> >
> > Thanks for your tips, suggestions and moral support. I report my
> > findings back.
> > /Ake
> >
> >
> > brendanmurphy37 wrote:
> >
> > >
> > > Ake,
> > >
> > > I can almost feel your frustration: we've all been there!
> > >
> > > I'm very interested in the outcome of this, as our own task for
> next
> > > week is to get the watchdog working on our own LPC2134-based
> system.
> > >
> > > I'm a bit surprised that no one has volunteered some working code.
> > > Surely someone out there is using this?
> > >
> > > Unfortunately, as we haven't got there yet, I've nothing specific
> to
> > > suggest, other than a general strategy of getting something simple
> > > working first, and then building up to where you are. For example:
> > >
> > > 1. As simple as possible startup, initialisation (all peripherals
> > > disabled, all interrupts off etc.) and an application that
> > > initialises the watchdog and uses GPIO to signal what it's doing
> (and
> > > maybe reads to indicate whether or not the watchdog should be
> fed).
> > > In other words, the simplest possible program with a working
> > > watchdog.
> > >
> > > 2. Same program, but with your normal initialisation and setup
> code,
> > > added incrementally. Still working?
> > >
> > > 3. Compare and contrast with your real application, particularly
> in
> > > how peripherals, interrupts etc. are managed.
> > >
> > > In other words, get something simple working first, and build up
> from
> > > there. It'll take time, but maybe less time then starting from a
> > > larger system that doesn't work.
> > >
> > > Hopefully, somewhere along the line, all will become obvious.
> > >
> > > By the way, are you running your code using an emulator connected?
> > > I've seen strange behaviour in the past with watchdogs enabled.
> Try
> > > running stand-alone, if you haven't done so already.
> > >
> > > As a final suggestion, based on what you say below, I'd look very
> > > carefully at every location interrupts are enabled/disabled (at
> the
> > > peripheral level, at the VIC and at the CPSR). Also at your
> startup
> > > and IRQ dispatch code. Maybe the processor is resetting and re-
> > > initialising stuff without you realising? maybe throwing an
> exception
> > > you haven't noticed?
> > >
> > > As a final comment: 'though no doubt it feels like it, it's not
> time
> > > wasted: you'll know way more about the watchdog and processor at
> the
> > > end of all this then when you started.
> > >
> > > Good luck!
> > >
> > > Brendan
> > >
> > >
> > > --- In lpc2000@lpc2..., "Ake Hedman, eurosource"
> <akhe@b...>
> > > wrote:
> > > >
> > > > WD story update
> > > >
> > > > I changed the code to have the watchdog raising an IRQ instead
> of a
> > > > RESET. I initialize stuff and then go in in a while loop.
> > > >
> > > > 1.) With interrupts enabled but no interrupt channel active this
> > > will
> > > > not trigger the watchdog. Why?
> > > >
> > > > 2.) With one of the interrupt channels active ( UART0 writing
> some
> > > > characters ) the watchdog works. Without a dog feed the
> watchdog is
> > > > triggered and with a feed it runs fine. However what I
> initialize
> > > WDTC
> > > > with does to seem to matter. I always get about 4 ms period
> when I
> > > > toggle a pin in the WD interrupt (60MHz clock).
> > > >
> > > > Is this behaviour recognized by anyone? Please!
> > > >
> > > > BTW the chip is LPC2138
> > > >
> > > > /Ake
> > > >
> > > >
> > > > dr_danish_ali wrote:
> > > >
> > > > > Ok Ake, here's my dumb suggestion:
> > > > >
> > > > > Try enabling the watchdog, but just to interrupt not reset?
> > > > > You'll need an interrupt handler / VIC channel to do it - can
> you
> > > > > spare one?
> > > > > That ISR need just raise a flag for now.
> > > > >
> > > > > Once the watchdog is fed and running happily, you might then
> be
> > > able
> > > > > to enable resets on
> > > > > it.
> > > > >
> > > > > Hope this helps,
> > > > > Danish
> > > > >
> > > > > --- In lpc2000@lpc2..., "Ake Hedman, eurosource"
> > > <akhe@b...>
> > > > > wrote:
> > > > > >
> > > > > > I am still trying to solve my problems with the watchdog.
> > > > > >
> > > > > > I have now scaled away most stuff of my application and can
> see
> > > that
> > > > > the
> > > > > > problem occurs when either of three interrupts occur
> > > (UART0/UART1/I2C0)
> > > > > > in the system. Without the watchdog everything works fine
> but
> > > if I
> > > > > > enable the watchdog everything crashes. I have tried to just
> > > enable and
> > > > > > trig one of the interrupts in turn but the situation is the
> > > same.
> > > > > >
> > > > > > I'm totally out of clues at the moment so any (also things
> that
> > > > > might be
> > > > > > considered dumb) are very welcome.
> > > > > >
> > > > > > Regards
> > > > > > /Ake
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > SPONSORED LINKS
> > > > > Microprocessor
> > > > > <http://groups.yahoo.com/gads?
> > >
> t=ms&k=Microprocessor&w1=Microprocessor&w2=Microcontrollers&w3=Pic+mic
> > > rocontrollers&w451+microprocessor&c=4&s&.sig=tsVC-
> > > J9hJ5qyXg0WPR0l6g>
> > > > > Microcontrollers
> > > > > <http://groups.yahoo.com/gads?
> > >
> t=ms&k=Microcontrollers&w1=Microprocessor&w2=Microcontrollers&w3=Pic+m
> > >
> icrocontrollers&w451+microprocessor&c=4&s&.sig=DvJVNqC_pqRTm8Xq0
> > > 1nxwg>
> > > > > Pic microcontrollers
> > > > > <http://groups.yahoo.com/gads?
> > >
> t=ms&k=Pic+microcontrollers&w1=Microprocessor&w2=Microcontrollers&w3=P
> > >
> ic+microcontrollers&w451+microprocessor&c=4&s&.sig=TpkoX4KofDJ7c
> > > 6LyBvUqVQ>
> > > > >
> > > > > 8051 microprocessor
> > > > > <http://groups.yahoo.com/gads?
> > >
> t=ms&k51+microprocessor&w1=Microprocessor&w2=Microcontrollers&w3=Pi
> > >
> c+microcontrollers&w451+microprocessor&c=4&s&.sig=1Ipf1Fjfbd_HVI
> > > lekkDP-A>
> > > > >
> > > > >
> > > > >
> > > > > --------------------------
> ----
> > > ------
> > > > > >.
> > > > >
> > > > >
> > > > > --------------------------
> ----
> > > ------
> > > > >
> > > >
> > > >
> > > > --
> > > > ---
> > > > Ake Hedman (YAP - Yet Another Programmer)
> > > > eurosource, Brattbergavägen 17, 820 50 LOS, Sweden
> > > > Phone: (46) 657 413430 Cellular: (46) 73 84 84 102
> > > > Company home: http://www.eurosource.se
> > > > Kryddor/Te/Kaffe: http://www.brattberg.com
> > > > Personal homepage: http://www.eurosource.se/akhe
> > > > Automated home: http://www.vscp.org
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> > >
> > > ------------------------------
> ------
> > > >.
> > >
> > >
> > > ------------------------------
> ------
> > >
> >
> >
> > --
> > ---
> > Ake Hedman (YAP - Yet Another Programmer)
> > eurosource, Brattbergavägen 17, 820 50 LOS, Sweden
> > Phone: (46) 657 413430 Cellular: (46) 73 84 84 102
> > Company home: http://www.eurosource.se
> > Kryddor/Te/Kaffe: http://www.brattberg.com
> > Personal homepage: http://www.eurosource.se/akhe
> > Automated home: http://www.vscp.org
> >
> >
> >
> >
> >
> >. >
>
--
---
Ake Hedman (YAP - Yet Another Programmer)
eurosource, Brattbergavägen 17, 820 50 LOS, Sweden
Phone: (46) 657 413430 Cellular: (46) 73 84 84 102
Company home: http://www.eurosource.se
Kryddor/Te/Kaffe: http://www.brattberg.com
Personal homepage: http://www.eurosource.se/akhe
Automated home: http://www.vscp.org
thanks. It's really good to here that. Even if 99.999% of the problems
comes from the code we write ourselves it is still nice to take away
that 0.0001% that comes from problems in hardware.
I'm in the process of doing a new test project at the moment to try to
trace this down under a more controlled environment.
Thanks for taking the time to sharing this info. Much appreciated!
Cheers
/Ake
brendanmurphy37 wrote:
>
> Ake,
>
> Thanks for your comments.
>
> I'm not sure if you want to hear this or not, but we've just put in
> support for the watchdog. It worked first time, with no problems.
> Code is below: two functions, one called as part of startup sequence,
> the other called from a watchdog task that's scheduled every second.
> If we spin in a loop locking out all other tasks, the system is reset
> as expected.
>
> Our system has several sources of interrupt enabled (both UARTs, I2C
> etc.): it works regardless of what's happeneing elsewhere.
>
> By the way, we use GCC 3.3.1 with -O2 to compile.
>
> Regards
> Brendan
>
> =========================================
> CODE STARTS HERE:
>
> #define REG(addr) (*(volatile unsigned int *)(addr))
>
> #define WDOG_BASE (0xE0000000)
> #define WDOG_WDMOD (0xE0000000)
> #define WDOG_WDTC (0xE0000004)
> #define WDOG_WDFEED (0xE0000008)
> #define WDOG_WDTV (0xE000000C)
>
> /* define basic watchdog timeout value as 100 ms */
>
> #define WATCH_TIMER_100MS (250000) /* 10 MHz / 4 is i/p clock */
>
> /*
> * Configure and start watchdog
> */
>
> static
> void watchdog_init(void)
>
> {
> /* set the watchdog timer constant */
>
> REG(WDOG_WDTC) = WATCH_TIMER_100MS * (50); /* 5 seconds for now */
>
> /* set mode to reset on underflow */
>
> REG(WDOG_WDMOD) = 0x3;
>
> /* feed watchdog to start it off */
>
> REG(WDOG_WDFEED) = 0xaa;
> REG(WDOG_WDFEED) = 0x55;
>
> return;
> }
>
> /*
> * Feed the watchdog to prevent us from being reset
> */
>
> void HwWatchdogFeed(void)
>
> {
> /* write the magic sequence to keep the dog happy */
>
> REG(WDOG_WDFEED) = 0xaa;
> REG(WDOG_WDFEED) = 0x55;
>
> return;
> }
>
> END OF CODE
> ========================================
>
> --- In lpc2000@lpc2..., "Ake Hedman, eurosource" <akhe@b...>
> wrote:
> >
> > Thanks Brendan,
> >
> > This is the right approach surely. I'm at that state now and have
> no
> > other alternative then to back a bit and go through this "the right
> > way". I just have myself to blame. Have used watchdogs for many
> years on
> > PIC, AVR and other processors and expected no problem there except
> for
> > the usual forgetting to feed it in certain places. Oh well it's my
> first
> > project on this processor family so this makes me learn useful
> stuff
> > just as you write (just a bit hard to appreciate that right now ;-
> ) ).
> > Really need the watchdog to work in this application though so
> there is
> > no shortcut.
> >
> > I just debug using GPIO pins and one of the serial ports at the
> moment
> > so there is no emulator connected now.
> >
> > Thanks for your tips, suggestions and moral support. I report my
> > findings back.
> > /Ake
> >
> >
> > brendanmurphy37 wrote:
> >
> > >
> > > Ake,
> > >
> > > I can almost feel your frustration: we've all been there!
> > >
> > > I'm very interested in the outcome of this, as our own task for
> next
> > > week is to get the watchdog working on our own LPC2134-based
> system.
> > >
> > > I'm a bit surprised that no one has volunteered some working code.
> > > Surely someone out there is using this?
> > >
> > > Unfortunately, as we haven't got there yet, I've nothing specific
> to
> > > suggest, other than a general strategy of getting something simple
> > > working first, and then building up to where you are. For example:
> > >
> > > 1. As simple as possible startup, initialisation (all peripherals
> > > disabled, all interrupts off etc.) and an application that
> > > initialises the watchdog and uses GPIO to signal what it's doing
> (and
> > > maybe reads to indicate whether or not the watchdog should be
> fed).
> > > In other words, the simplest possible program with a working
> > > watchdog.
> > >
> > > 2. Same program, but with your normal initialisation and setup
> code,
> > > added incrementally. Still working?
> > >
> > > 3. Compare and contrast with your real application, particularly
> in
> > > how peripherals, interrupts etc. are managed.
> > >
> > > In other words, get something simple working first, and build up
> from
> > > there. It'll take time, but maybe less time then starting from a
> > > larger system that doesn't work.
> > >
> > > Hopefully, somewhere along the line, all will become obvious.
> > >
> > > By the way, are you running your code using an emulator connected?
> > > I've seen strange behaviour in the past with watchdogs enabled.
> Try
> > > running stand-alone, if you haven't done so already.
> > >
> > > As a final suggestion, based on what you say below, I'd look very
> > > carefully at every location interrupts are enabled/disabled (at
> the
> > > peripheral level, at the VIC and at the CPSR). Also at your
> startup
> > > and IRQ dispatch code. Maybe the processor is resetting and re-
> > > initialising stuff without you realising? maybe throwing an
> exception
> > > you haven't noticed?
> > >
> > > As a final comment: 'though no doubt it feels like it, it's not
> time
> > > wasted: you'll know way more about the watchdog and processor at
> the
> > > end of all this then when you started.
> > >
> > > Good luck!
> > >
> > > Brendan
> > >
> > >
> > > --- In lpc2000@lpc2..., "Ake Hedman, eurosource"
> <akhe@b...>
> > > wrote:
> > > >
> > > > WD story update
> > > >
> > > > I changed the code to have the watchdog raising an IRQ instead
> of a
> > > > RESET. I initialize stuff and then go in in a while loop.
> > > >
> > > > 1.) With interrupts enabled but no interrupt channel active this
> > > will
> > > > not trigger the watchdog. Why?
> > > >
> > > > 2.) With one of the interrupt channels active ( UART0 writing
> some
> > > > characters ) the watchdog works. Without a dog feed the
> watchdog is
> > > > triggered and with a feed it runs fine. However what I
> initialize
> > > WDTC
> > > > with does to seem to matter. I always get about 4 ms period
> when I
> > > > toggle a pin in the WD interrupt (60MHz clock).
> > > >
> > > > Is this behaviour recognized by anyone? Please!
> > > >
> > > > BTW the chip is LPC2138
> > > >
> > > > /Ake
> > > >
> > > >
> > > > dr_danish_ali wrote:
> > > >
> > > > > Ok Ake, here's my dumb suggestion:
> > > > >
> > > > > Try enabling the watchdog, but just to interrupt not reset?
> > > > > You'll need an interrupt handler / VIC channel to do it - can
> you
> > > > > spare one?
> > > > > That ISR need just raise a flag for now.
> > > > >
> > > > > Once the watchdog is fed and running happily, you might then
> be
> > > able
> > > > > to enable resets on
> > > > > it.
> > > > >
> > > > > Hope this helps,
> > > > > Danish
> > > > >
> > > > > --- In lpc2000@lpc2..., "Ake Hedman, eurosource"
> > > <akhe@b...>
> > > > > wrote:
> > > > > >
> > > > > > I am still trying to solve my problems with the watchdog.
> > > > > >
> > > > > > I have now scaled away most stuff of my application and can
> see
> > > that
> > > > > the
> > > > > > problem occurs when either of three interrupts occur
> > > (UART0/UART1/I2C0)
> > > > > > in the system. Without the watchdog everything works fine
> but
> > > if I
> > > > > > enable the watchdog everything crashes. I have tried to just
> > > enable and
> > > > > > trig one of the interrupts in turn but the situation is the
> > > same.
> > > > > >
> > > > > > I'm totally out of clues at the moment so any (also things
> that
> > > > > might be
> > > > > > considered dumb) are very welcome.
> > > > > >
> > > > > > Regards
> > > > > > /Ake
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > SPONSORED LINKS
> > > > > Microprocessor
> > > > > <http://groups.yahoo.com/gads?
> > >
> t=ms&k=Microprocessor&w1=Microprocessor&w2=Microcontrollers&w3=Pic+mic
> > > rocontrollers&w451+microprocessor&c=4&s&.sig=tsVC-
> > > J9hJ5qyXg0WPR0l6g>
> > > > > Microcontrollers
> > > > > <http://groups.yahoo.com/gads?
> > >
> t=ms&k=Microcontrollers&w1=Microprocessor&w2=Microcontrollers&w3=Pic+m
> > >
> icrocontrollers&w451+microprocessor&c=4&s&.sig=DvJVNqC_pqRTm8Xq0
> > > 1nxwg>
> > > > > Pic microcontrollers
> > > > > <http://groups.yahoo.com/gads?
> > >
> t=ms&k=Pic+microcontrollers&w1=Microprocessor&w2=Microcontrollers&w3=P
> > >
> ic+microcontrollers&w451+microprocessor&c=4&s&.sig=TpkoX4KofDJ7c
> > > 6LyBvUqVQ>
> > > > >
> > > > > 8051 microprocessor
> > > > > <http://groups.yahoo.com/gads?
> > >
> t=ms&k51+microprocessor&w1=Microprocessor&w2=Microcontrollers&w3=Pi
> > >
> c+microcontrollers&w451+microprocessor&c=4&s&.sig=1Ipf1Fjfbd_HVI
> > > lekkDP-A>
> > > > >
> > > > >
> > > > >
> > > > > --------------------------
> ----
> > > ------
> > > > > >.
> > > > >
> > > > >
> > > > > --------------------------
> ----
> > > ------
> > > > >
> > > >
> > > >
> > > > --
> > > > ---
> > > > Ake Hedman (YAP - Yet Another Programmer)
> > > > eurosource, Brattbergavägen 17, 820 50 LOS, Sweden
> > > > Phone: (46) 657 413430 Cellular: (46) 73 84 84 102
> > > > Company home: http://www.eurosource.se
> > > > Kryddor/Te/Kaffe: http://www.brattberg.com
> > > > Personal homepage: http://www.eurosource.se/akhe
> > > > Automated home: http://www.vscp.org
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> > >
> > > ------------------------------
> ------
> > > >.
> > >
> > >
> > > ------------------------------
> ------
> > >
> >
> >
> > --
> > ---
> > Ake Hedman (YAP - Yet Another Programmer)
> > eurosource, Brattbergavägen 17, 820 50 LOS, Sweden
> > Phone: (46) 657 413430 Cellular: (46) 73 84 84 102
> > Company home: http://www.eurosource.se
> > Kryddor/Te/Kaffe: http://www.brattberg.com
> > Personal homepage: http://www.eurosource.se/akhe
> > Automated home: http://www.vscp.org
> >
> >
> >
> >
> >
> >. >
>
--
---
Ake Hedman (YAP - Yet Another Programmer)
eurosource, Brattbergavägen 17, 820 50 LOS, Sweden
Phone: (46) 657 413430 Cellular: (46) 73 84 84 102
Company home: http://www.eurosource.se
Kryddor/Te/Kaffe: http://www.brattberg.com
Personal homepage: http://www.eurosource.se/akhe
Automated home: http://www.vscp.org
Reply by ●December 9, 20052005-12-09
At 10:58 AM 12/8/05 +0100, Ake Hedman, eurosource wrote:
>This is the right approach surely. I'm at that state now and have no
>other alternative then to back a bit and go through this "the right
>way". I just have myself to blame. Have used watchdogs for many years on
>PIC, AVR and other processors and expected no problem there except for
>the usual forgetting to feed it in certain places. Oh well it's my first
>project on this processor family so this makes me learn useful stuff
>just as you write (just a bit hard to appreciate that right now ;-) ).
>Really need the watchdog to work in this application though so there is
>no shortcut.
One thought that occurs to me, and I have no idea whether it is an issue
with this processor, is that some watchdogs must be cleared before they are
enabled or you run the risk of them firing as soon as you enable
them. Whether or not they do depends on when you start them and how the
registers initialize etc...
Robert
" 'Freedom' has no meaning of itself. There are always restrictions, be
they legal, genetic, or physical. If you don't believe me, try to chew a
radio signal. " -- Kelvin Throop, III
http://www.aeolusdevelopment.com/
>This is the right approach surely. I'm at that state now and have no
>other alternative then to back a bit and go through this "the right
>way". I just have myself to blame. Have used watchdogs for many years on
>PIC, AVR and other processors and expected no problem there except for
>the usual forgetting to feed it in certain places. Oh well it's my first
>project on this processor family so this makes me learn useful stuff
>just as you write (just a bit hard to appreciate that right now ;-) ).
>Really need the watchdog to work in this application though so there is
>no shortcut.
One thought that occurs to me, and I have no idea whether it is an issue
with this processor, is that some watchdogs must be cleared before they are
enabled or you run the risk of them firing as soon as you enable
them. Whether or not they do depends on when you start them and how the
registers initialize etc...
Robert
" 'Freedom' has no meaning of itself. There are always restrictions, be
they legal, genetic, or physical. If you don't believe me, try to chew a
radio signal. " -- Kelvin Throop, III
http://www.aeolusdevelopment.com/
Reply by ●December 9, 20052005-12-09
Basically, your method works fine...
UNTIL: you start adding interrupt service routines!
This is why:
void WDOG_pet()
{
WDFEED = 0xAA;
/* Interrupt occurs here...> dog will NOT pet properly!!!
***/
WDFEED = 0x55;
}
/**** example uses Keil compiler directives ***/
/********** The following is what I wound up doing, (gotta avoid that
spurious interrupt issue with the ARM also!!! ***/
/**** The actual interface that everybody uses ***/
void WDOG_pet (void)
{
SYSSWI_service (12,0,0,0);
}
/***** How the SYSSWI_service works, (based on SWI) ***/
unsigned SYSSWI_service (SYSSWI opcode, int id, void *pObj, unsigned
_user1) __swi(12)
{
switch (opcode)
{
case SYSSWI_WDOGPET:
SYSSWI_watchDogPet ();
break;
...
}
return (0);
}
/***** How the SYSSWI_watchDogPet () works ***/
static void SYSSWI_watchDogPet (void)
{
ARM_disableFIQ (); /* make sure FIQ is disabled
*/
WDFEED = 0xAA;
WDFEED = 0x55;
ARM_enableFIQ (); /* re-enable the FIQ
*/
}
/***** The IRQ is automatically disabled by vectoring to the SWI...
however, you need to make the operation atomic with respect to FIQ,
which is NOT disabled ***/
PUBLIC ARM_disableFIQ?A ; interface is ARM mode
ARM_disableFIQ?A PROC CODE32
MRS R0,CPSR
ORR R0,R0,#0x0040 ; Mask just the FIQ
MSR CPSR_c,R0
BX R14
ENDP
PUBLIC ARM_enableFIQ?A ; interface is ARM mode
ARM_enableFIQ?A PROC CODE32
MRS R0,CPSR
BIC R0,R0,#0x0040 ; Enable just the FIQ
MSR CPSR_c,R0
BX R14
ENDP
END --- In lpc2000@lpc2..., "Ake Hedman, eurosource" <akhe@b...>
wrote:
>
> Hi all.
>
> I am trying to enable the watchdog but the result is a total hang of
the
> board. Not even the bootloader is possible to reach after the crash
and
> I have to reapply power with P0.14 low to get access to the
botloader
> again. Reset is not enough.
>
> The code to initialize the watchdog is
>
> // initialize the watchdog timer
> WDTC = 0xffffffff; // 15000000; // One
second
> = 15000000
> WDMOD = WDEN | WDRESET; // Activate watchdog
> WDFEED = 0xAA; WDFEED = 0x55;
>
> I must have misunderstood the WD functionality. What am I doing
wrong?
> In the above code the watchdog should not trigger until 5 minutes
> elapsed so even if a vector should be wrong the code that follow
should
> run for a while but as soon as I write to the WDMOD register I get a
hang.
>
> /Ake
>
> --
> ---
> Ake Hedman (YAP - Yet Another Programmer)
> eurosource, Brattbergavägen 17, 820 50 LOS, Sweden
> Phone: (46) 657 413430 Cellular: (46) 73 84 84 102
> Company home: http://www.eurosource.se
> Kryddor/Te/Kaffe: http://www.brattberg.com
> Personal homepage: http://www.eurosource.se/akhe
> Automated home: http://www.vscp.org
>
UNTIL: you start adding interrupt service routines!
This is why:
void WDOG_pet()
{
WDFEED = 0xAA;
/* Interrupt occurs here...> dog will NOT pet properly!!!
***/
WDFEED = 0x55;
}
/**** example uses Keil compiler directives ***/
/********** The following is what I wound up doing, (gotta avoid that
spurious interrupt issue with the ARM also!!! ***/
/**** The actual interface that everybody uses ***/
void WDOG_pet (void)
{
SYSSWI_service (12,0,0,0);
}
/***** How the SYSSWI_service works, (based on SWI) ***/
unsigned SYSSWI_service (SYSSWI opcode, int id, void *pObj, unsigned
_user1) __swi(12)
{
switch (opcode)
{
case SYSSWI_WDOGPET:
SYSSWI_watchDogPet ();
break;
...
}
return (0);
}
/***** How the SYSSWI_watchDogPet () works ***/
static void SYSSWI_watchDogPet (void)
{
ARM_disableFIQ (); /* make sure FIQ is disabled
*/
WDFEED = 0xAA;
WDFEED = 0x55;
ARM_enableFIQ (); /* re-enable the FIQ
*/
}
/***** The IRQ is automatically disabled by vectoring to the SWI...
however, you need to make the operation atomic with respect to FIQ,
which is NOT disabled ***/
PUBLIC ARM_disableFIQ?A ; interface is ARM mode
ARM_disableFIQ?A PROC CODE32
MRS R0,CPSR
ORR R0,R0,#0x0040 ; Mask just the FIQ
MSR CPSR_c,R0
BX R14
ENDP
PUBLIC ARM_enableFIQ?A ; interface is ARM mode
ARM_enableFIQ?A PROC CODE32
MRS R0,CPSR
BIC R0,R0,#0x0040 ; Enable just the FIQ
MSR CPSR_c,R0
BX R14
ENDP
END --- In lpc2000@lpc2..., "Ake Hedman, eurosource" <akhe@b...>
wrote:
>
> Hi all.
>
> I am trying to enable the watchdog but the result is a total hang of
the
> board. Not even the bootloader is possible to reach after the crash
and
> I have to reapply power with P0.14 low to get access to the
botloader
> again. Reset is not enough.
>
> The code to initialize the watchdog is
>
> // initialize the watchdog timer
> WDTC = 0xffffffff; // 15000000; // One
second
> = 15000000
> WDMOD = WDEN | WDRESET; // Activate watchdog
> WDFEED = 0xAA; WDFEED = 0x55;
>
> I must have misunderstood the WD functionality. What am I doing
wrong?
> In the above code the watchdog should not trigger until 5 minutes
> elapsed so even if a vector should be wrong the code that follow
should
> run for a while but as soon as I write to the WDMOD register I get a
hang.
>
> /Ake
>
> --
> ---
> Ake Hedman (YAP - Yet Another Programmer)
> eurosource, Brattbergavägen 17, 820 50 LOS, Sweden
> Phone: (46) 657 413430 Cellular: (46) 73 84 84 102
> Company home: http://www.eurosource.se
> Kryddor/Te/Kaffe: http://www.brattberg.com
> Personal homepage: http://www.eurosource.se/akhe
> Automated home: http://www.vscp.org
>
Reply by ●December 9, 20052005-12-09
Robert Adsett wrote:
> At 10:58 AM 12/8/05 +0100, Ake Hedman, eurosource wrote:
> >This is the right approach surely. I'm at that state now and have no
> >other alternative then to back a bit and go through this "the right
> >way". I just have myself to blame. Have used watchdogs for many years on
> >PIC, AVR and other processors and expected no problem there except for
> >the usual forgetting to feed it in certain places. Oh well it's my first
> >project on this processor family so this makes me learn useful stuff
> >just as you write (just a bit hard to appreciate that right now ;-) ).
> >Really need the watchdog to work in this application though so there is
> >no shortcut.
>
> One thought that occurs to me, and I have no idea whether it is an issue
> with this processor, is that some watchdogs must be cleared before
> they are
> enabled or you run the risk of them firing as soon as you enable
> them. Whether or not they do depends on when you start them and how the
> registers initialize etc...
>
> Robert
Good thought! Sadly it did not help on my problems. But I agree this is
probably something one should do. The watchdog is initialized to 0xff
on reset according to the manual. The question here is if it is updated
while disabled or will stay at 0xff until enabled. Have to test that.
Thanks!
/Ake >
> " 'Freedom' has no meaning of itself. There are always
> restrictions, be
> they legal, genetic, or physical. If you don't believe me, try to chew a
> radio signal. " -- Kelvin Throop, III
> http://www.aeolusdevelopment.com/ >
> SPONSORED LINKS
> Microprocessor
> <http://groups.yahoo.com/gads?t=ms&k=Microprocessor&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w451+microprocessor&c=4&s&.sig=tsVC-J9hJ5qyXg0WPR0l6g>
> Microcontrollers
> <http://groups.yahoo.com/gads?t=ms&k=Microcontrollers&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w451+microprocessor&c=4&s&.sig=DvJVNqC_pqRTm8Xq01nxwg>
> Pic microcontrollers
> <http://groups.yahoo.com/gads?t=ms&k=Pic+microcontrollers&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w451+microprocessor&c=4&s&.sig=TpkoX4KofDJ7c6LyBvUqVQ>
>
> 8051 microprocessor
> <http://groups.yahoo.com/gads?t=ms&k51+microprocessor&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w451+microprocessor&c=4&s&.sig=1Ipf1Fjfbd_HVIlekkDP-A >
>
> >. >
>
--
---
Ake Hedman (YAP - Yet Another Programmer)
eurosource, Brattbergavägen 17, 820 50 LOS, Sweden
Phone: (46) 657 413430 Cellular: (46) 73 84 84 102
Company home: http://www.eurosource.se
Kryddor/Te/Kaffe: http://www.brattberg.com
Personal homepage: http://www.eurosource.se/akhe
Automated home: http://www.vscp.org
> At 10:58 AM 12/8/05 +0100, Ake Hedman, eurosource wrote:
> >This is the right approach surely. I'm at that state now and have no
> >other alternative then to back a bit and go through this "the right
> >way". I just have myself to blame. Have used watchdogs for many years on
> >PIC, AVR and other processors and expected no problem there except for
> >the usual forgetting to feed it in certain places. Oh well it's my first
> >project on this processor family so this makes me learn useful stuff
> >just as you write (just a bit hard to appreciate that right now ;-) ).
> >Really need the watchdog to work in this application though so there is
> >no shortcut.
>
> One thought that occurs to me, and I have no idea whether it is an issue
> with this processor, is that some watchdogs must be cleared before
> they are
> enabled or you run the risk of them firing as soon as you enable
> them. Whether or not they do depends on when you start them and how the
> registers initialize etc...
>
> Robert
Good thought! Sadly it did not help on my problems. But I agree this is
probably something one should do. The watchdog is initialized to 0xff
on reset according to the manual. The question here is if it is updated
while disabled or will stay at 0xff until enabled. Have to test that.
Thanks!
/Ake >
> " 'Freedom' has no meaning of itself. There are always
> restrictions, be
> they legal, genetic, or physical. If you don't believe me, try to chew a
> radio signal. " -- Kelvin Throop, III
> http://www.aeolusdevelopment.com/ >
> SPONSORED LINKS
> Microprocessor
> <http://groups.yahoo.com/gads?t=ms&k=Microprocessor&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w451+microprocessor&c=4&s&.sig=tsVC-J9hJ5qyXg0WPR0l6g>
> Microcontrollers
> <http://groups.yahoo.com/gads?t=ms&k=Microcontrollers&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w451+microprocessor&c=4&s&.sig=DvJVNqC_pqRTm8Xq01nxwg>
> Pic microcontrollers
> <http://groups.yahoo.com/gads?t=ms&k=Pic+microcontrollers&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w451+microprocessor&c=4&s&.sig=TpkoX4KofDJ7c6LyBvUqVQ>
>
> 8051 microprocessor
> <http://groups.yahoo.com/gads?t=ms&k51+microprocessor&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w451+microprocessor&c=4&s&.sig=1Ipf1Fjfbd_HVIlekkDP-A >
>
> >. >
>
--
---
Ake Hedman (YAP - Yet Another Programmer)
eurosource, Brattbergavägen 17, 820 50 LOS, Sweden
Phone: (46) 657 413430 Cellular: (46) 73 84 84 102
Company home: http://www.eurosource.se
Kryddor/Te/Kaffe: http://www.brattberg.com
Personal homepage: http://www.eurosource.se/akhe
Automated home: http://www.vscp.org
Reply by ●December 9, 20052005-12-09
Ken,
Can you explain why you think there's a problem with an interrupt
between the two writes?
According to the User Manual: "Once 0xAA is written to
the WDFEED register the next operation in the Watchdog register space
should be a WRITE (0x55) to the WDFFED register otherwise the
watchdog is triggered."
I take this to mean that the next write to the WDFEED register has to
be 0x55 following the 0xaa: why should it matter if this is one cycle
on, or 1000 cycles on (e.g. to take account of any interrupt)? I'm
assuming here that the interrupt itself doesn't go near the watchdog.
Also, for disabling interrupts, why not just disable IRQ and FIQ in
the same write to the CPSR? Is there some problem with this?
regards
Brendan --- In lpc2000@lpc2..., "Ken Wada" <kwada@a...> wrote:
>
> Basically, your method works fine...
> UNTIL: you start adding interrupt service routines!
>
> This is why:
> void WDOG_pet()
> {
> WDFEED = 0xAA;
> /* Interrupt occurs here...> dog will NOT pet
properly!!!
> ***/
> WDFEED = 0x55;
> }
>
> /**** example uses Keil compiler directives ***/
> /********** The following is what I wound up doing, (gotta avoid
that
> spurious interrupt issue with the ARM also!!! ***/
>
> /**** The actual interface that everybody uses ***/
> void WDOG_pet (void)
> {
> SYSSWI_service (12,0,0,0);
> }
>
> /***** How the SYSSWI_service works, (based on SWI) ***/
> unsigned SYSSWI_service (SYSSWI opcode, int id, void *pObj,
unsigned
> _user1) __swi(12)
> {
> switch (opcode)
> {
> case SYSSWI_WDOGPET:
> SYSSWI_watchDogPet ();
> break;
> ...
> }
> return (0);
> }
>
> /***** How the SYSSWI_watchDogPet () works ***/
> static void SYSSWI_watchDogPet (void)
> {
> ARM_disableFIQ (); /* make sure FIQ is
disabled
> */
> WDFEED = 0xAA;
> WDFEED = 0x55;
> ARM_enableFIQ (); /* re-enable the
FIQ
> */
> }
>
> /***** The IRQ is automatically disabled by vectoring to the SWI...
> however, you need to make the operation atomic with respect to FIQ,
> which is NOT disabled ***/
>
> PUBLIC ARM_disableFIQ?A ; interface is ARM mode
>
> ARM_disableFIQ?A PROC CODE32
> MRS R0,CPSR
> ORR R0,R0,#0x0040 ; Mask just the FIQ
> MSR CPSR_c,R0
> BX R14
>
> ENDP
>
> PUBLIC ARM_enableFIQ?A ; interface is ARM mode
>
> ARM_enableFIQ?A PROC CODE32
> MRS R0,CPSR
> BIC R0,R0,#0x0040 ; Enable just the FIQ
> MSR CPSR_c,R0
> BX R14
>
> ENDP
> END > --- In lpc2000@lpc2..., "Ake Hedman, eurosource"
<akhe@b...>
> wrote:
> >
> > Hi all.
> >
> > I am trying to enable the watchdog but the result is a total hang
of
> the
> > board. Not even the bootloader is possible to reach after the
crash
> and
> > I have to reapply power with P0.14 low to get access to the
> botloader
> > again. Reset is not enough.
> >
> > The code to initialize the watchdog is
> >
> > // initialize the watchdog timer
> > WDTC = 0xffffffff; // 15000000; // One
> second
> > = 15000000
> > WDMOD = WDEN | WDRESET; // Activate
watchdog
> > WDFEED = 0xAA; WDFEED = 0x55;
> >
> > I must have misunderstood the WD functionality. What am I doing
> wrong?
> > In the above code the watchdog should not trigger until 5 minutes
> > elapsed so even if a vector should be wrong the code that follow
> should
> > run for a while but as soon as I write to the WDMOD register I
get a
> hang.
> >
> > /Ake
> >
> > --
> > ---
> > Ake Hedman (YAP - Yet Another Programmer)
> > eurosource, Brattbergavägen 17, 820 50 LOS, Sweden
> > Phone: (46) 657 413430 Cellular: (46) 73 84 84 102
> > Company home: http://www.eurosource.se
> > Kryddor/Te/Kaffe: http://www.brattberg.com
> > Personal homepage: http://www.eurosource.se/akhe
> > Automated home: http://www.vscp.org
> >
>
Reply by ●December 9, 20052005-12-09
Ken,
yes this is probably it (as zdravko_k_d@zdra... also pointed out
earlier). Strange not to have an atomic feed. First time I have come
across that. I have the code taken apart now to try to track this down.
But all the symptoms of the problems I have match what should be
expected from the watchdog triggering from something else then not just
lack of feed.
What happens if the watchdog is feed with the wrong sequence? Is it
triggered or does it just ignore it?
Appreciate your input Ken.
/Ake
Ken Wada wrote:
> Basically, your method works fine...
> UNTIL: you start adding interrupt service routines!
>
> This is why:
> void WDOG_pet()
> {
> WDFEED = 0xAA;
> /* Interrupt occurs here...> dog will NOT pet properly!!!
> ***/
> WDFEED = 0x55;
> }
>
> /**** example uses Keil compiler directives ***/
> /********** The following is what I wound up doing, (gotta avoid that
> spurious interrupt issue with the ARM also!!! ***/
>
> /**** The actual interface that everybody uses ***/
> void WDOG_pet (void)
> {
> SYSSWI_service (12,0,0,0);
> }
>
> /***** How the SYSSWI_service works, (based on SWI) ***/
> unsigned SYSSWI_service (SYSSWI opcode, int id, void *pObj, unsigned
> _user1) __swi(12)
> {
> switch (opcode)
> {
> case SYSSWI_WDOGPET:
> SYSSWI_watchDogPet ();
> break;
> ...
> }
> return (0);
> }
>
> /***** How the SYSSWI_watchDogPet () works ***/
> static void SYSSWI_watchDogPet (void)
> {
> ARM_disableFIQ (); /* make sure FIQ is disabled
> */
> WDFEED = 0xAA;
> WDFEED = 0x55;
> ARM_enableFIQ (); /* re-enable the FIQ
> */
> }
>
> /***** The IRQ is automatically disabled by vectoring to the SWI...
> however, you need to make the operation atomic with respect to FIQ,
> which is NOT disabled ***/
>
> PUBLIC ARM_disableFIQ?A ; interface is ARM mode
>
> ARM_disableFIQ?A PROC CODE32
> MRS R0,CPSR
> ORR R0,R0,#0x0040 ; Mask just the FIQ
> MSR CPSR_c,R0
> BX R14
>
> ENDP
>
> PUBLIC ARM_enableFIQ?A ; interface is ARM mode
>
> ARM_enableFIQ?A PROC CODE32
> MRS R0,CPSR
> BIC R0,R0,#0x0040 ; Enable just the FIQ
> MSR CPSR_c,R0
> BX R14
>
> ENDP
> END > --- In lpc2000@lpc2..., "Ake Hedman, eurosource" <akhe@b...>
> wrote:
> >
> > Hi all.
> >
> > I am trying to enable the watchdog but the result is a total hang of
> the
> > board. Not even the bootloader is possible to reach after the crash
> and
> > I have to reapply power with P0.14 low to get access to the
> botloader
> > again. Reset is not enough.
> >
> > The code to initialize the watchdog is
> >
> > // initialize the watchdog timer
> > WDTC = 0xffffffff; // 15000000; // One
> second
> > = 15000000
> > WDMOD = WDEN | WDRESET; // Activate watchdog
> > WDFEED = 0xAA; WDFEED = 0x55;
> >
> > I must have misunderstood the WD functionality. What am I doing
> wrong?
> > In the above code the watchdog should not trigger until 5 minutes
> > elapsed so even if a vector should be wrong the code that follow
> should
> > run for a while but as soon as I write to the WDMOD register I get a
> hang.
> >
> > /Ake
> >
> > --
> > ---
> > Ake Hedman (YAP - Yet Another Programmer)
> > eurosource, Brattbergavägen 17, 820 50 LOS, Sweden
> > Phone: (46) 657 413430 Cellular: (46) 73 84 84 102
> > Company home: http://www.eurosource.se
> > Kryddor/Te/Kaffe: http://www.brattberg.com
> > Personal homepage: http://www.eurosource.se/akhe
> > Automated home: http://www.vscp.org
> >
> SPONSORED LINKS
> Microprocessor
> <http://groups.yahoo.com/gads?t=ms&k=Microprocessor&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w451+microprocessor&c=4&s&.sig=tsVC-J9hJ5qyXg0WPR0l6g>
> Microcontrollers
> <http://groups.yahoo.com/gads?t=ms&k=Microcontrollers&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w451+microprocessor&c=4&s&.sig=DvJVNqC_pqRTm8Xq01nxwg>
> Pic microcontrollers
> <http://groups.yahoo.com/gads?t=ms&k=Pic+microcontrollers&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w451+microprocessor&c=4&s&.sig=TpkoX4KofDJ7c6LyBvUqVQ>
>
> 8051 microprocessor
> <http://groups.yahoo.com/gads?t=ms&k51+microprocessor&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w451+microprocessor&c=4&s&.sig=1Ipf1Fjfbd_HVIlekkDP-A >
>
> >. >
>
--
---
Ake Hedman (YAP - Yet Another Programmer)
eurosource, Brattbergavägen 17, 820 50 LOS, Sweden
Phone: (46) 657 413430 Cellular: (46) 73 84 84 102
Company home: http://www.eurosource.se
Kryddor/Te/Kaffe: http://www.brattberg.com
Personal homepage: http://www.eurosource.se/akhe
Automated home: http://www.vscp.org
yes this is probably it (as zdravko_k_d@zdra... also pointed out
earlier). Strange not to have an atomic feed. First time I have come
across that. I have the code taken apart now to try to track this down.
But all the symptoms of the problems I have match what should be
expected from the watchdog triggering from something else then not just
lack of feed.
What happens if the watchdog is feed with the wrong sequence? Is it
triggered or does it just ignore it?
Appreciate your input Ken.
/Ake
Ken Wada wrote:
> Basically, your method works fine...
> UNTIL: you start adding interrupt service routines!
>
> This is why:
> void WDOG_pet()
> {
> WDFEED = 0xAA;
> /* Interrupt occurs here...> dog will NOT pet properly!!!
> ***/
> WDFEED = 0x55;
> }
>
> /**** example uses Keil compiler directives ***/
> /********** The following is what I wound up doing, (gotta avoid that
> spurious interrupt issue with the ARM also!!! ***/
>
> /**** The actual interface that everybody uses ***/
> void WDOG_pet (void)
> {
> SYSSWI_service (12,0,0,0);
> }
>
> /***** How the SYSSWI_service works, (based on SWI) ***/
> unsigned SYSSWI_service (SYSSWI opcode, int id, void *pObj, unsigned
> _user1) __swi(12)
> {
> switch (opcode)
> {
> case SYSSWI_WDOGPET:
> SYSSWI_watchDogPet ();
> break;
> ...
> }
> return (0);
> }
>
> /***** How the SYSSWI_watchDogPet () works ***/
> static void SYSSWI_watchDogPet (void)
> {
> ARM_disableFIQ (); /* make sure FIQ is disabled
> */
> WDFEED = 0xAA;
> WDFEED = 0x55;
> ARM_enableFIQ (); /* re-enable the FIQ
> */
> }
>
> /***** The IRQ is automatically disabled by vectoring to the SWI...
> however, you need to make the operation atomic with respect to FIQ,
> which is NOT disabled ***/
>
> PUBLIC ARM_disableFIQ?A ; interface is ARM mode
>
> ARM_disableFIQ?A PROC CODE32
> MRS R0,CPSR
> ORR R0,R0,#0x0040 ; Mask just the FIQ
> MSR CPSR_c,R0
> BX R14
>
> ENDP
>
> PUBLIC ARM_enableFIQ?A ; interface is ARM mode
>
> ARM_enableFIQ?A PROC CODE32
> MRS R0,CPSR
> BIC R0,R0,#0x0040 ; Enable just the FIQ
> MSR CPSR_c,R0
> BX R14
>
> ENDP
> END > --- In lpc2000@lpc2..., "Ake Hedman, eurosource" <akhe@b...>
> wrote:
> >
> > Hi all.
> >
> > I am trying to enable the watchdog but the result is a total hang of
> the
> > board. Not even the bootloader is possible to reach after the crash
> and
> > I have to reapply power with P0.14 low to get access to the
> botloader
> > again. Reset is not enough.
> >
> > The code to initialize the watchdog is
> >
> > // initialize the watchdog timer
> > WDTC = 0xffffffff; // 15000000; // One
> second
> > = 15000000
> > WDMOD = WDEN | WDRESET; // Activate watchdog
> > WDFEED = 0xAA; WDFEED = 0x55;
> >
> > I must have misunderstood the WD functionality. What am I doing
> wrong?
> > In the above code the watchdog should not trigger until 5 minutes
> > elapsed so even if a vector should be wrong the code that follow
> should
> > run for a while but as soon as I write to the WDMOD register I get a
> hang.
> >
> > /Ake
> >
> > --
> > ---
> > Ake Hedman (YAP - Yet Another Programmer)
> > eurosource, Brattbergavägen 17, 820 50 LOS, Sweden
> > Phone: (46) 657 413430 Cellular: (46) 73 84 84 102
> > Company home: http://www.eurosource.se
> > Kryddor/Te/Kaffe: http://www.brattberg.com
> > Personal homepage: http://www.eurosource.se/akhe
> > Automated home: http://www.vscp.org
> >
> SPONSORED LINKS
> Microprocessor
> <http://groups.yahoo.com/gads?t=ms&k=Microprocessor&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w451+microprocessor&c=4&s&.sig=tsVC-J9hJ5qyXg0WPR0l6g>
> Microcontrollers
> <http://groups.yahoo.com/gads?t=ms&k=Microcontrollers&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w451+microprocessor&c=4&s&.sig=DvJVNqC_pqRTm8Xq01nxwg>
> Pic microcontrollers
> <http://groups.yahoo.com/gads?t=ms&k=Pic+microcontrollers&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w451+microprocessor&c=4&s&.sig=TpkoX4KofDJ7c6LyBvUqVQ>
>
> 8051 microprocessor
> <http://groups.yahoo.com/gads?t=ms&k51+microprocessor&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w451+microprocessor&c=4&s&.sig=1Ipf1Fjfbd_HVIlekkDP-A >
>
> >. >
>
--
---
Ake Hedman (YAP - Yet Another Programmer)
eurosource, Brattbergavägen 17, 820 50 LOS, Sweden
Phone: (46) 657 413430 Cellular: (46) 73 84 84 102
Company home: http://www.eurosource.se
Kryddor/Te/Kaffe: http://www.brattberg.com
Personal homepage: http://www.eurosource.se/akhe
Automated home: http://www.vscp.org
Reply by ●December 9, 20052005-12-09
From extensive testing...I have found that the LPC22xx just ignores an
invalid feed.
I have come across this in Motorola's Power PC chip also.
Ken Wada
--- In lpc2000@lpc2..., "Ake Hedman, eurosource" <akhe@b...>
wrote:
>
> Ken,
>
> yes this is probably it (as zdravko_k_d@y... also pointed out
> earlier). Strange not to have an atomic feed. First time I have
come
> across that. I have the code taken apart now to try to track this
down.
> But all the symptoms of the problems I have match what should be
> expected from the watchdog triggering from something else then not
just
> lack of feed.
>
> What happens if the watchdog is feed with the wrong sequence? Is it
> triggered or does it just ignore it?
>
> Appreciate your input Ken.
>
> /Ake
>
> Ken Wada wrote:
>
> > Basically, your method works fine...
> > UNTIL: you start adding interrupt service routines!
> >
> > This is why:
> > void WDOG_pet()
> > {
> > WDFEED = 0xAA;
> > /* Interrupt occurs here...> dog will NOT pet
properly!!!
> > ***/
> > WDFEED = 0x55;
> > }
> >
> > /**** example uses Keil compiler directives ***/
> > /********** The following is what I wound up doing, (gotta avoid
that
> > spurious interrupt issue with the ARM also!!! ***/
> >
> > /**** The actual interface that everybody uses ***/
> > void WDOG_pet (void)
> > {
> > SYSSWI_service (12,0,0,0);
> > }
> >
> > /***** How the SYSSWI_service works, (based on SWI) ***/
> > unsigned SYSSWI_service (SYSSWI opcode, int id, void *pObj,
unsigned
> > _user1) __swi(12)
> > {
> > switch (opcode)
> > {
> > case SYSSWI_WDOGPET:
> > SYSSWI_watchDogPet ();
> > break;
> > ...
> > }
> > return (0);
> > }
> >
> > /***** How the SYSSWI_watchDogPet () works ***/
> > static void SYSSWI_watchDogPet (void)
> > {
> > ARM_disableFIQ (); /* make sure FIQ is disabled
> > */
> > WDFEED = 0xAA;
> > WDFEED = 0x55;
> > ARM_enableFIQ (); /* re-enable the FIQ
> > */
> > }
> >
> > /***** The IRQ is automatically disabled by vectoring to the SWI..
.
> > however, you need to make the operation atomic with respect to
FIQ,
> > which is NOT disabled ***/
> >
> > PUBLIC ARM_disableFIQ?A ; interface is ARM mode
> >
> > ARM_disableFIQ?A PROC CODE32
> > MRS R0,CPSR
> > ORR R0,R0,#0x0040 ; Mask just the FIQ
> > MSR CPSR_c,R0
> > BX R14
> >
> > ENDP
> >
> > PUBLIC ARM_enableFIQ?A ; interface is ARM mode
> >
> > ARM_enableFIQ?A PROC CODE32
> > MRS R0,CPSR
> > BIC R0,R0,#0x0040 ; Enable just the FIQ
> > MSR CPSR_c,R0
> > BX R14
> >
> > ENDP
> > END
> >
> >
> > --- In lpc2000@lpc2..., "Ake Hedman, eurosource" <akhe@b..
.>
> > wrote:
> > >
> > > Hi all.
> > >
> > > I am trying to enable the watchdog but the result is a total
hang of
> > the
> > > board. Not even the bootloader is possible to reach after the
crash
> > and
> > > I have to reapply power with P0.14 low to get access to the
> > botloader
> > > again. Reset is not enough.
> > >
> > > The code to initialize the watchdog is
> > >
> > > // initialize the watchdog timer
> > > WDTC = 0xffffffff; // 15000000; //
One
> > second
> > > = 15000000
> > > WDMOD = WDEN | WDRESET; // Activate
watchdog
> > > WDFEED = 0xAA; WDFEED = 0x55;
> > >
> > > I must have misunderstood the WD functionality. What am I doing
> > wrong?
> > > In the above code the watchdog should not trigger until 5
minutes
> > > elapsed so even if a vector should be wrong the code that follow
> > should
> > > run for a while but as soon as I write to the WDMOD register I
get a
> > hang.
> > >
> > > /Ake
> > >
> > > --
> > > ---
> > > Ake Hedman (YAP - Yet Another Programmer)
> > > eurosource, Brattbergavägen 17, 820 50 LOS, Sweden
> > > Phone: (46) 657 413430 Cellular: (46) 73 84 84 102
> > > Company home: http://www.eurosource.se
> > > Kryddor/Te/Kaffe: http://www.brattberg.com
> > > Personal homepage: http://www.eurosource.se/akhe
> > > Automated home: http://www.vscp.org
> > >
> >
> >
> >
> >
> >
> >
> > SPONSORED LINKS
> > Microprocessor
> > <http://groups.yahoo.com/gads?
t=ms&k=Microprocessor&w1=Microprocessor&w2=Microcontrollers&w3=Pic+mic
rocontrollers&w451+microprocessor&c=4&s&.
sig=tsVC-J9hJ5qyXg0WPR0l6g>
> > Microcontrollers
> > <http://groups.yahoo.com/gads?
t=ms&k=Microcontrollers&w1=Microprocessor&w2=Microcontrollers&w3=Pic+m
icrocontrollers&w451+microprocessor&c=4&s&.
sig=DvJVNqC_pqRTm8Xq01nxwg>
> > Pic microcontrollers
> > <http://groups.yahoo.com/gads?
t=ms&k=Pic+microcontrollers&w1=Microprocessor&w2=Microcontrollers&w3=P
ic+microcontrollers&w451+microprocessor&c=4&s&.
sig=TpkoX4KofDJ7c6LyBvUqVQ>
> >
> > 8051 microprocessor
> > <http://groups.yahoo.com/gads?
t=ms&k51+microprocessor&w1=Microprocessor&w2=Microcontrollers&w3=Pi
c+microcontrollers&w451+microprocessor&c=4&s&.
sig=1Ipf1Fjfbd_HVIlekkDP-A>
> >
> >
> >
> >
----------------------------------
--
> > >.
> >
> >
> >
----------------------------------
--
> > --
> ---
> Ake Hedman (YAP - Yet Another Programmer)
> eurosource, Brattbergavägen 17, 820 50 LOS, Sweden
> Phone: (46) 657 413430 Cellular: (46) 73 84 84 102
> Company home: http://www.eurosource.se
> Kryddor/Te/Kaffe: http://www.brattberg.com
> Personal homepage: http://www.eurosource.se/akhe
> Automated home: http://www.vscp.org
invalid feed.
I have come across this in Motorola's Power PC chip also.
Ken Wada
--- In lpc2000@lpc2..., "Ake Hedman, eurosource" <akhe@b...>
wrote:
>
> Ken,
>
> yes this is probably it (as zdravko_k_d@y... also pointed out
> earlier). Strange not to have an atomic feed. First time I have
come
> across that. I have the code taken apart now to try to track this
down.
> But all the symptoms of the problems I have match what should be
> expected from the watchdog triggering from something else then not
just
> lack of feed.
>
> What happens if the watchdog is feed with the wrong sequence? Is it
> triggered or does it just ignore it?
>
> Appreciate your input Ken.
>
> /Ake
>
> Ken Wada wrote:
>
> > Basically, your method works fine...
> > UNTIL: you start adding interrupt service routines!
> >
> > This is why:
> > void WDOG_pet()
> > {
> > WDFEED = 0xAA;
> > /* Interrupt occurs here...> dog will NOT pet
properly!!!
> > ***/
> > WDFEED = 0x55;
> > }
> >
> > /**** example uses Keil compiler directives ***/
> > /********** The following is what I wound up doing, (gotta avoid
that
> > spurious interrupt issue with the ARM also!!! ***/
> >
> > /**** The actual interface that everybody uses ***/
> > void WDOG_pet (void)
> > {
> > SYSSWI_service (12,0,0,0);
> > }
> >
> > /***** How the SYSSWI_service works, (based on SWI) ***/
> > unsigned SYSSWI_service (SYSSWI opcode, int id, void *pObj,
unsigned
> > _user1) __swi(12)
> > {
> > switch (opcode)
> > {
> > case SYSSWI_WDOGPET:
> > SYSSWI_watchDogPet ();
> > break;
> > ...
> > }
> > return (0);
> > }
> >
> > /***** How the SYSSWI_watchDogPet () works ***/
> > static void SYSSWI_watchDogPet (void)
> > {
> > ARM_disableFIQ (); /* make sure FIQ is disabled
> > */
> > WDFEED = 0xAA;
> > WDFEED = 0x55;
> > ARM_enableFIQ (); /* re-enable the FIQ
> > */
> > }
> >
> > /***** The IRQ is automatically disabled by vectoring to the SWI..
.
> > however, you need to make the operation atomic with respect to
FIQ,
> > which is NOT disabled ***/
> >
> > PUBLIC ARM_disableFIQ?A ; interface is ARM mode
> >
> > ARM_disableFIQ?A PROC CODE32
> > MRS R0,CPSR
> > ORR R0,R0,#0x0040 ; Mask just the FIQ
> > MSR CPSR_c,R0
> > BX R14
> >
> > ENDP
> >
> > PUBLIC ARM_enableFIQ?A ; interface is ARM mode
> >
> > ARM_enableFIQ?A PROC CODE32
> > MRS R0,CPSR
> > BIC R0,R0,#0x0040 ; Enable just the FIQ
> > MSR CPSR_c,R0
> > BX R14
> >
> > ENDP
> > END
> >
> >
> > --- In lpc2000@lpc2..., "Ake Hedman, eurosource" <akhe@b..
.>
> > wrote:
> > >
> > > Hi all.
> > >
> > > I am trying to enable the watchdog but the result is a total
hang of
> > the
> > > board. Not even the bootloader is possible to reach after the
crash
> > and
> > > I have to reapply power with P0.14 low to get access to the
> > botloader
> > > again. Reset is not enough.
> > >
> > > The code to initialize the watchdog is
> > >
> > > // initialize the watchdog timer
> > > WDTC = 0xffffffff; // 15000000; //
One
> > second
> > > = 15000000
> > > WDMOD = WDEN | WDRESET; // Activate
watchdog
> > > WDFEED = 0xAA; WDFEED = 0x55;
> > >
> > > I must have misunderstood the WD functionality. What am I doing
> > wrong?
> > > In the above code the watchdog should not trigger until 5
minutes
> > > elapsed so even if a vector should be wrong the code that follow
> > should
> > > run for a while but as soon as I write to the WDMOD register I
get a
> > hang.
> > >
> > > /Ake
> > >
> > > --
> > > ---
> > > Ake Hedman (YAP - Yet Another Programmer)
> > > eurosource, Brattbergavägen 17, 820 50 LOS, Sweden
> > > Phone: (46) 657 413430 Cellular: (46) 73 84 84 102
> > > Company home: http://www.eurosource.se
> > > Kryddor/Te/Kaffe: http://www.brattberg.com
> > > Personal homepage: http://www.eurosource.se/akhe
> > > Automated home: http://www.vscp.org
> > >
> >
> >
> >
> >
> >
> >
> > SPONSORED LINKS
> > Microprocessor
> > <http://groups.yahoo.com/gads?
t=ms&k=Microprocessor&w1=Microprocessor&w2=Microcontrollers&w3=Pic+mic
rocontrollers&w451+microprocessor&c=4&s&.
sig=tsVC-J9hJ5qyXg0WPR0l6g>
> > Microcontrollers
> > <http://groups.yahoo.com/gads?
t=ms&k=Microcontrollers&w1=Microprocessor&w2=Microcontrollers&w3=Pic+m
icrocontrollers&w451+microprocessor&c=4&s&.
sig=DvJVNqC_pqRTm8Xq01nxwg>
> > Pic microcontrollers
> > <http://groups.yahoo.com/gads?
t=ms&k=Pic+microcontrollers&w1=Microprocessor&w2=Microcontrollers&w3=P
ic+microcontrollers&w451+microprocessor&c=4&s&.
sig=TpkoX4KofDJ7c6LyBvUqVQ>
> >
> > 8051 microprocessor
> > <http://groups.yahoo.com/gads?
t=ms&k51+microprocessor&w1=Microprocessor&w2=Microcontrollers&w3=Pi
c+microcontrollers&w451+microprocessor&c=4&s&.
sig=1Ipf1Fjfbd_HVIlekkDP-A>
> >
> >
> >
> >
----------------------------------
--
> > >.
> >
> >
> >
----------------------------------
--
> > --
> ---
> Ake Hedman (YAP - Yet Another Programmer)
> eurosource, Brattbergavägen 17, 820 50 LOS, Sweden
> Phone: (46) 657 413430 Cellular: (46) 73 84 84 102
> Company home: http://www.eurosource.se
> Kryddor/Te/Kaffe: http://www.brattberg.com
> Personal homepage: http://www.eurosource.se/akhe
> Automated home: http://www.vscp.org
Reply by ●December 9, 20052005-12-09
--- In lpc2000@lpc2..., "brendanmurphy37"
<brendan.murphy@i...
> wrote: > Ken,
>
> Can you explain why you think there's a problem with an interrupt
> between the two writes?
>
> According to the User Manual: "Once 0xAA is written to
> the WDFEED register the next operation in the Watchdog register
space
> should be a WRITE (0x55) to the WDFFED register otherwise the
> watchdog is triggered."
>
> I take this to mean that the next write to the WDFEED register has
to
> be 0x55 following the 0xaa: why should it matter if this is one
cycle
> on, or 1000 cycles on (e.g. to take account of any interrupt)? I'm
> assuming here that the interrupt itself doesn't go near the
watchdog.
It makes a bit difference! If you WRITE (0x55), the processor expects
a WRITE(0xAA) on the very next cycle. If this is done outside an
interrupt context, the interrupt service routine will pretty much
guarantee that this condition is violated!
>
> Also, for disabling interrupts, why not just disable IRQ and FIQ in
> the same write to the CPSR? Is there some problem with this?
Yep...huge problem. Actually, you will see this type of problem with
many processors/especially DSP's with fully pipelined architecture.
The Philips User manual calls this the spurious interrupt problem.
Actually, Philips basically took their cautionary note directly from
the ARM users guide.
Gone are the good-old days of doing something like EA=0, as per 8051..
.these pipelined architectures are a bit different when it comes to
instruction processing.
Fortunately, all of these modern architectures give you a way to do
these types of operations, (albeit with a bit more effort), via some
software interrupt (SWI) instruction.
My 1st encounter with this was with the Intel 80386 chip. This chip
had an instruction pipeline, and I had to use the int86() SWI command
in order to properly code up the atomic sections.
Ken Wada
>
> regards
> Brendan > --- In lpc2000@lpc2..., "Ken Wada" <kwada@a...> wrote:
> >
> > Basically, your method works fine...
> > UNTIL: you start adding interrupt service routines!
> >
> > This is why:
> > void WDOG_pet()
> > {
> > WDFEED = 0xAA;
> > /* Interrupt occurs here...> dog will NOT pet
> properly!!!
> > ***/
> > WDFEED = 0x55;
> > }
> >
> > /**** example uses Keil compiler directives ***/
> > /********** The following is what I wound up doing, (gotta avoid
> that
> > spurious interrupt issue with the ARM also!!! ***/
> >
> > /**** The actual interface that everybody uses ***/
> > void WDOG_pet (void)
> > {
> > SYSSWI_service (12,0,0,0);
> > }
> >
> > /***** How the SYSSWI_service works, (based on SWI) ***/
> > unsigned SYSSWI_service (SYSSWI opcode, int id, void *pObj,
> unsigned
> > _user1) __swi(12)
> > {
> > switch (opcode)
> > {
> > case SYSSWI_WDOGPET:
> > SYSSWI_watchDogPet ();
> > break;
> > ...
> > }
> > return (0);
> > }
> >
> > /***** How the SYSSWI_watchDogPet () works ***/
> > static void SYSSWI_watchDogPet (void)
> > {
> > ARM_disableFIQ (); /* make sure FIQ is
> disabled
> > */
> > WDFEED = 0xAA;
> > WDFEED = 0x55;
> > ARM_enableFIQ (); /* re-enable the
> FIQ
> > */
> > }
> >
> > /***** The IRQ is automatically disabled by vectoring to the SWI..
.
> > however, you need to make the operation atomic with respect to
FIQ,
> > which is NOT disabled ***/
> >
> > PUBLIC ARM_disableFIQ?A ; interface is ARM mode
> >
> > ARM_disableFIQ?A PROC CODE32
> > MRS R0,CPSR
> > ORR R0,R0,#0x0040 ; Mask just the FIQ
> > MSR CPSR_c,R0
> > BX R14
> >
> > ENDP
> >
> > PUBLIC ARM_enableFIQ?A ; interface is ARM mode
> >
> > ARM_enableFIQ?A PROC CODE32
> > MRS R0,CPSR
> > BIC R0,R0,#0x0040 ; Enable just the FIQ
> > MSR CPSR_c,R0
> > BX R14
> >
> > ENDP
> > END
> >
> >
> > --- In lpc2000@lpc2..., "Ake Hedman, eurosource"
> <akhe@b...>
> > wrote:
> > >
> > > Hi all.
> > >
> > > I am trying to enable the watchdog but the result is a total
hang
> of
> > the
> > > board. Not even the bootloader is possible to reach after the
> crash
> > and
> > > I have to reapply power with P0.14 low to get access to the
> > botloader
> > > again. Reset is not enough.
> > >
> > > The code to initialize the watchdog is
> > >
> > > // initialize the watchdog timer
> > > WDTC = 0xffffffff; // 15000000; //
One
> > second
> > > = 15000000
> > > WDMOD = WDEN | WDRESET; // Activate
> watchdog
> > > WDFEED = 0xAA; WDFEED = 0x55;
> > >
> > > I must have misunderstood the WD functionality. What am I doing
> > wrong?
> > > In the above code the watchdog should not trigger until 5
minutes
> > > elapsed so even if a vector should be wrong the code that follow
> > should
> > > run for a while but as soon as I write to the WDMOD register I
> get a
> > hang.
> > >
> > > /Ake
> > >
> > > --
> > > ---
> > > Ake Hedman (YAP - Yet Another Programmer)
> > > eurosource, Brattbergavägen 17, 820 50 LOS, Sweden
> > > Phone: (46) 657 413430 Cellular: (46) 73 84 84 102
> > > Company home: http://www.eurosource.se
> > > Kryddor/Te/Kaffe: http://www.brattberg.com
> > > Personal homepage: http://www.eurosource.se/akhe
> > > Automated home: http://www.vscp.org
> > >
> >
>
> wrote: > Ken,
>
> Can you explain why you think there's a problem with an interrupt
> between the two writes?
>
> According to the User Manual: "Once 0xAA is written to
> the WDFEED register the next operation in the Watchdog register
space
> should be a WRITE (0x55) to the WDFFED register otherwise the
> watchdog is triggered."
>
> I take this to mean that the next write to the WDFEED register has
to
> be 0x55 following the 0xaa: why should it matter if this is one
cycle
> on, or 1000 cycles on (e.g. to take account of any interrupt)? I'm
> assuming here that the interrupt itself doesn't go near the
watchdog.
It makes a bit difference! If you WRITE (0x55), the processor expects
a WRITE(0xAA) on the very next cycle. If this is done outside an
interrupt context, the interrupt service routine will pretty much
guarantee that this condition is violated!
>
> Also, for disabling interrupts, why not just disable IRQ and FIQ in
> the same write to the CPSR? Is there some problem with this?
Yep...huge problem. Actually, you will see this type of problem with
many processors/especially DSP's with fully pipelined architecture.
The Philips User manual calls this the spurious interrupt problem.
Actually, Philips basically took their cautionary note directly from
the ARM users guide.
Gone are the good-old days of doing something like EA=0, as per 8051..
.these pipelined architectures are a bit different when it comes to
instruction processing.
Fortunately, all of these modern architectures give you a way to do
these types of operations, (albeit with a bit more effort), via some
software interrupt (SWI) instruction.
My 1st encounter with this was with the Intel 80386 chip. This chip
had an instruction pipeline, and I had to use the int86() SWI command
in order to properly code up the atomic sections.
Ken Wada
>
> regards
> Brendan > --- In lpc2000@lpc2..., "Ken Wada" <kwada@a...> wrote:
> >
> > Basically, your method works fine...
> > UNTIL: you start adding interrupt service routines!
> >
> > This is why:
> > void WDOG_pet()
> > {
> > WDFEED = 0xAA;
> > /* Interrupt occurs here...> dog will NOT pet
> properly!!!
> > ***/
> > WDFEED = 0x55;
> > }
> >
> > /**** example uses Keil compiler directives ***/
> > /********** The following is what I wound up doing, (gotta avoid
> that
> > spurious interrupt issue with the ARM also!!! ***/
> >
> > /**** The actual interface that everybody uses ***/
> > void WDOG_pet (void)
> > {
> > SYSSWI_service (12,0,0,0);
> > }
> >
> > /***** How the SYSSWI_service works, (based on SWI) ***/
> > unsigned SYSSWI_service (SYSSWI opcode, int id, void *pObj,
> unsigned
> > _user1) __swi(12)
> > {
> > switch (opcode)
> > {
> > case SYSSWI_WDOGPET:
> > SYSSWI_watchDogPet ();
> > break;
> > ...
> > }
> > return (0);
> > }
> >
> > /***** How the SYSSWI_watchDogPet () works ***/
> > static void SYSSWI_watchDogPet (void)
> > {
> > ARM_disableFIQ (); /* make sure FIQ is
> disabled
> > */
> > WDFEED = 0xAA;
> > WDFEED = 0x55;
> > ARM_enableFIQ (); /* re-enable the
> FIQ
> > */
> > }
> >
> > /***** The IRQ is automatically disabled by vectoring to the SWI..
.
> > however, you need to make the operation atomic with respect to
FIQ,
> > which is NOT disabled ***/
> >
> > PUBLIC ARM_disableFIQ?A ; interface is ARM mode
> >
> > ARM_disableFIQ?A PROC CODE32
> > MRS R0,CPSR
> > ORR R0,R0,#0x0040 ; Mask just the FIQ
> > MSR CPSR_c,R0
> > BX R14
> >
> > ENDP
> >
> > PUBLIC ARM_enableFIQ?A ; interface is ARM mode
> >
> > ARM_enableFIQ?A PROC CODE32
> > MRS R0,CPSR
> > BIC R0,R0,#0x0040 ; Enable just the FIQ
> > MSR CPSR_c,R0
> > BX R14
> >
> > ENDP
> > END
> >
> >
> > --- In lpc2000@lpc2..., "Ake Hedman, eurosource"
> <akhe@b...>
> > wrote:
> > >
> > > Hi all.
> > >
> > > I am trying to enable the watchdog but the result is a total
hang
> of
> > the
> > > board. Not even the bootloader is possible to reach after the
> crash
> > and
> > > I have to reapply power with P0.14 low to get access to the
> > botloader
> > > again. Reset is not enough.
> > >
> > > The code to initialize the watchdog is
> > >
> > > // initialize the watchdog timer
> > > WDTC = 0xffffffff; // 15000000; //
One
> > second
> > > = 15000000
> > > WDMOD = WDEN | WDRESET; // Activate
> watchdog
> > > WDFEED = 0xAA; WDFEED = 0x55;
> > >
> > > I must have misunderstood the WD functionality. What am I doing
> > wrong?
> > > In the above code the watchdog should not trigger until 5
minutes
> > > elapsed so even if a vector should be wrong the code that follow
> > should
> > > run for a while but as soon as I write to the WDMOD register I
> get a
> > hang.
> > >
> > > /Ake
> > >
> > > --
> > > ---
> > > Ake Hedman (YAP - Yet Another Programmer)
> > > eurosource, Brattbergavägen 17, 820 50 LOS, Sweden
> > > Phone: (46) 657 413430 Cellular: (46) 73 84 84 102
> > > Company home: http://www.eurosource.se
> > > Kryddor/Te/Kaffe: http://www.brattberg.com
> > > Personal homepage: http://www.eurosource.se/akhe
> > > Automated home: http://www.vscp.org
> > >
> >
>