I am testing the WDT. I tred this (code below). Watchdog triggers IRQ
interrupt, but after that, the program is just spinning in ISR. Any
idea why - i cleared the interrupt flags? I also tred to feed the
watchdog inside ISR, but no help.
void WDT_interrupt( void )
{
ISR_ENTRY();
/* blink led */
VICVectAddr = 0x00000000; // clear this interrupt from the VIC
WDMOD &= ~WDTOF; // clear the time-out interrupt flag
ISR_EXIT();
}
void WDTInit( void )
{
VICIntSelect&=~VIC_BIT(VIC_WDT);
VICIntEnable=VIC_BIT(VIC_WDT);
VICVectCntl3=VIC_ENABLE|VIC_WDT;
VICVectAddr3=(uint32_t)WDT_interrupt;
WDTC = WDT_FEED_VALUE;
WDMOD = WDEN; // Watchdog Interrupt Enable
WDFEED = 0xAA; // Feeding sequence
WDFEED = 0x55;
}
WDT - interrupt problem
Started by ●February 8, 2007
Reply by ●February 8, 20072007-02-08
--- In l..., "klemen_dovrtel"
wrote:
>
> I am testing the WDT. I tred this (code below). Watchdog triggers IRQ
> interrupt, but after that, the program is just spinning in ISR. Any
> idea why - i cleared the interrupt flags? I also tred to feed the
> watchdog inside ISR, but no help.
>
> void WDT_interrupt( void )
> {
> ISR_ENTRY();
>
> /* blink led */
>
> VICVectAddr = 0x00000000; // clear this interrupt from the VIC
> WDMOD &= ~WDTOF; // clear the time-out interrupt flag
> ISR_EXIT();
> }
>
> void WDTInit( void )
> {
> VICIntSelect&=~VIC_BIT(VIC_WDT);
> VICIntEnable=VIC_BIT(VIC_WDT);
> VICVectCntl3=VIC_ENABLE|VIC_WDT;
> VICVectAddr3=(uint32_t)WDT_interrupt;
>
> WDTC = WDT_FEED_VALUE;
> WDMOD = WDEN; // Watchdog Interrupt Enable
>
> WDFEED = 0xAA; // Feeding sequence
> WDFEED = 0x55;
> }
>
The WDTOF flag can be cleared softwarely only after external reset and
not on watch dog interrupt. You have to disable the interrupt itself
else the result you get !!!!
Suvidh
wrote:
>
> I am testing the WDT. I tred this (code below). Watchdog triggers IRQ
> interrupt, but after that, the program is just spinning in ISR. Any
> idea why - i cleared the interrupt flags? I also tred to feed the
> watchdog inside ISR, but no help.
>
> void WDT_interrupt( void )
> {
> ISR_ENTRY();
>
> /* blink led */
>
> VICVectAddr = 0x00000000; // clear this interrupt from the VIC
> WDMOD &= ~WDTOF; // clear the time-out interrupt flag
> ISR_EXIT();
> }
>
> void WDTInit( void )
> {
> VICIntSelect&=~VIC_BIT(VIC_WDT);
> VICIntEnable=VIC_BIT(VIC_WDT);
> VICVectCntl3=VIC_ENABLE|VIC_WDT;
> VICVectAddr3=(uint32_t)WDT_interrupt;
>
> WDTC = WDT_FEED_VALUE;
> WDMOD = WDEN; // Watchdog Interrupt Enable
>
> WDFEED = 0xAA; // Feeding sequence
> WDFEED = 0x55;
> }
>
The WDTOF flag can be cleared softwarely only after external reset and
not on watch dog interrupt. You have to disable the interrupt itself
else the result you get !!!!
Suvidh
Reply by ●February 8, 20072007-02-08
--- In l..., "suvidhk" wrote:
>
> --- In l..., "klemen_dovrtel"
> wrote:
> >
> > I am testing the WDT. I tred this (code below). Watchdog triggers IRQ
> > interrupt, but after that, the program is just spinning in ISR. Any
> > idea why - i cleared the interrupt flags? I also tred to feed the
> > watchdog inside ISR, but no help.
> >
> > void WDT_interrupt( void )
> > {
> > ISR_ENTRY();
> >
> > /* blink led */
> >
> > VICVectAddr = 0x00000000; // clear this interrupt from the VIC
> > WDMOD &= ~WDTOF; // clear the time-out interrupt flag
> > ISR_EXIT();
> > }
> >
> > void WDTInit( void )
> > {
> > VICIntSelect&=~VIC_BIT(VIC_WDT);
> > VICIntEnable=VIC_BIT(VIC_WDT);
> > VICVectCntl3=VIC_ENABLE|VIC_WDT;
> > VICVectAddr3=(uint32_t)WDT_interrupt;
> >
> > WDTC = WDT_FEED_VALUE;
> > WDMOD = WDEN; // Watchdog Interrupt Enable
> >
> > WDFEED = 0xAA; // Feeding sequence
> > WDFEED = 0x55;
> > }
> > The WDTOF flag can be cleared softwarely only after external reset and
> not on watch dog interrupt. You have to disable the interrupt itself
> else the result you get !!!!
> Suvidh
>
What is the purpose of this interrupt then, if it can be used only once?
Regards
Klemen
>
> --- In l..., "klemen_dovrtel"
> wrote:
> >
> > I am testing the WDT. I tred this (code below). Watchdog triggers IRQ
> > interrupt, but after that, the program is just spinning in ISR. Any
> > idea why - i cleared the interrupt flags? I also tred to feed the
> > watchdog inside ISR, but no help.
> >
> > void WDT_interrupt( void )
> > {
> > ISR_ENTRY();
> >
> > /* blink led */
> >
> > VICVectAddr = 0x00000000; // clear this interrupt from the VIC
> > WDMOD &= ~WDTOF; // clear the time-out interrupt flag
> > ISR_EXIT();
> > }
> >
> > void WDTInit( void )
> > {
> > VICIntSelect&=~VIC_BIT(VIC_WDT);
> > VICIntEnable=VIC_BIT(VIC_WDT);
> > VICVectCntl3=VIC_ENABLE|VIC_WDT;
> > VICVectAddr3=(uint32_t)WDT_interrupt;
> >
> > WDTC = WDT_FEED_VALUE;
> > WDMOD = WDEN; // Watchdog Interrupt Enable
> >
> > WDFEED = 0xAA; // Feeding sequence
> > WDFEED = 0x55;
> > }
> > The WDTOF flag can be cleared softwarely only after external reset and
> not on watch dog interrupt. You have to disable the interrupt itself
> else the result you get !!!!
> Suvidh
>
What is the purpose of this interrupt then, if it can be used only once?
Regards
Klemen
Reply by ●February 8, 20072007-02-08
--- In l..., "klemen_dovrtel"
wrote:
>
> --- In l..., "suvidhk" wrote:
> >
> > --- In l..., "klemen_dovrtel"
> > wrote:
> > >
> > > I am testing the WDT. I tred this (code below). Watchdog
triggers IRQ
> > > interrupt, but after that, the program is just spinning in ISR. Any
> > > idea why - i cleared the interrupt flags? I also tred to feed the
> > > watchdog inside ISR, but no help.
> > >
> > > void WDT_interrupt( void )
> > > {
> > > ISR_ENTRY();
> > >
> > > /* blink led */
> > >
> > > VICVectAddr = 0x00000000; // clear this interrupt from the VIC
> > > WDMOD &= ~WDTOF; // clear the time-out interrupt flag
> > > ISR_EXIT();
> > > }
> > >
> > > void WDTInit( void )
> > > {
> > > VICIntSelect&=~VIC_BIT(VIC_WDT);
> > > VICIntEnable=VIC_BIT(VIC_WDT);
> > > VICVectCntl3=VIC_ENABLE|VIC_WDT;
> > > VICVectAddr3=(uint32_t)WDT_interrupt;
> > >
> > > WDTC = WDT_FEED_VALUE;
> > > WDMOD = WDEN; // Watchdog Interrupt Enable
> > >
> > > WDFEED = 0xAA; // Feeding sequence
> > > WDFEED = 0x55;
> > > }
> > >
> >
> > The WDTOF flag can be cleared softwarely only after external reset and
> > not on watch dog interrupt. You have to disable the interrupt itself
> > else the result you get !!!!
> >
> >
> > Suvidh
> > What is the purpose of this interrupt then, if it can be used only once?
>
> Regards
> Klemen
>
Klemen,
Watchdog interrupt or reset occurs if you have some problems in the
execution say a spike had put your software flow in unpredictable
results. Hence resuming from this interrupt will be useless.
You can use the interrupt to debug or inform through some LED for
system problem. Also may log some data if possible for your debugging
purpose.
Hence letting the interrupt run will not be a watchdog functionality.
Right ?
Suvdih
wrote:
>
> --- In l..., "suvidhk" wrote:
> >
> > --- In l..., "klemen_dovrtel"
> > wrote:
> > >
> > > I am testing the WDT. I tred this (code below). Watchdog
triggers IRQ
> > > interrupt, but after that, the program is just spinning in ISR. Any
> > > idea why - i cleared the interrupt flags? I also tred to feed the
> > > watchdog inside ISR, but no help.
> > >
> > > void WDT_interrupt( void )
> > > {
> > > ISR_ENTRY();
> > >
> > > /* blink led */
> > >
> > > VICVectAddr = 0x00000000; // clear this interrupt from the VIC
> > > WDMOD &= ~WDTOF; // clear the time-out interrupt flag
> > > ISR_EXIT();
> > > }
> > >
> > > void WDTInit( void )
> > > {
> > > VICIntSelect&=~VIC_BIT(VIC_WDT);
> > > VICIntEnable=VIC_BIT(VIC_WDT);
> > > VICVectCntl3=VIC_ENABLE|VIC_WDT;
> > > VICVectAddr3=(uint32_t)WDT_interrupt;
> > >
> > > WDTC = WDT_FEED_VALUE;
> > > WDMOD = WDEN; // Watchdog Interrupt Enable
> > >
> > > WDFEED = 0xAA; // Feeding sequence
> > > WDFEED = 0x55;
> > > }
> > >
> >
> > The WDTOF flag can be cleared softwarely only after external reset and
> > not on watch dog interrupt. You have to disable the interrupt itself
> > else the result you get !!!!
> >
> >
> > Suvidh
> > What is the purpose of this interrupt then, if it can be used only once?
>
> Regards
> Klemen
>
Klemen,
Watchdog interrupt or reset occurs if you have some problems in the
execution say a spike had put your software flow in unpredictable
results. Hence resuming from this interrupt will be useless.
You can use the interrupt to debug or inform through some LED for
system problem. Also may log some data if possible for your debugging
purpose.
Hence letting the interrupt run will not be a watchdog functionality.
Right ?
Suvdih
Reply by ●February 8, 20072007-02-08
--- In l..., "suvidhk" wrote:
>
> --- In l..., "klemen_dovrtel"
> wrote:
> >
> > --- In l..., "suvidhk" wrote:
> > >
> > > --- In l..., "klemen_dovrtel"
> > > wrote:
> > > >
> > > > I am testing the WDT. I tred this (code below). Watchdog
> triggers IRQ
> > > > interrupt, but after that, the program is just spinning in
ISR. Any
> > > > idea why - i cleared the interrupt flags? I also tred to feed the
> > > > watchdog inside ISR, but no help.
> > > >
> > > > void WDT_interrupt( void )
> > > > {
> > > > ISR_ENTRY();
> > > >
> > > > /* blink led */
> > > >
> > > > VICVectAddr = 0x00000000; // clear this interrupt from the VIC
> > > > WDMOD &= ~WDTOF; // clear the time-out interrupt flag
> > > > ISR_EXIT();
> > > > }
> > > >
> > > > void WDTInit( void )
> > > > {
> > > > VICIntSelect&=~VIC_BIT(VIC_WDT);
> > > > VICIntEnable=VIC_BIT(VIC_WDT);
> > > > VICVectCntl3=VIC_ENABLE|VIC_WDT;
> > > > VICVectAddr3=(uint32_t)WDT_interrupt;
> > > >
> > > > WDTC = WDT_FEED_VALUE;
> > > > WDMOD = WDEN; // Watchdog Interrupt Enable
> > > >
> > > > WDFEED = 0xAA; // Feeding sequence
> > > > WDFEED = 0x55;
> > > > }
> > > >
> > >
> > > The WDTOF flag can be cleared softwarely only after external
reset and
> > > not on watch dog interrupt. You have to disable the interrupt itself
> > > else the result you get !!!!
> > >
> > >
> > > Suvidh
> > >
> >
> > What is the purpose of this interrupt then, if it can be used only
once?
> >
> > Regards
> > Klemen
> >
> Klemen,
> Watchdog interrupt or reset occurs if you have some problems in the
> execution say a spike had put your software flow in unpredictable
> results. Hence resuming from this interrupt will be useless.
> You can use the interrupt to debug or inform through some LED for
> system problem. Also may log some data if possible for your debugging
> purpose.
> Hence letting the interrupt run will not be a watchdog functionality.
> Right ?
> Suvdih
>
I was thinking of using watch dog as timer (i know it is not its basic
purpose). If there would be a way to clear the inteerupt flag in ISR,
the watch dog wouldn't lose functionality, but it would gain it. I
don't know why philips limited this option.
Regards
Klemen
>
> --- In l..., "klemen_dovrtel"
> wrote:
> >
> > --- In l..., "suvidhk" wrote:
> > >
> > > --- In l..., "klemen_dovrtel"
> > > wrote:
> > > >
> > > > I am testing the WDT. I tred this (code below). Watchdog
> triggers IRQ
> > > > interrupt, but after that, the program is just spinning in
ISR. Any
> > > > idea why - i cleared the interrupt flags? I also tred to feed the
> > > > watchdog inside ISR, but no help.
> > > >
> > > > void WDT_interrupt( void )
> > > > {
> > > > ISR_ENTRY();
> > > >
> > > > /* blink led */
> > > >
> > > > VICVectAddr = 0x00000000; // clear this interrupt from the VIC
> > > > WDMOD &= ~WDTOF; // clear the time-out interrupt flag
> > > > ISR_EXIT();
> > > > }
> > > >
> > > > void WDTInit( void )
> > > > {
> > > > VICIntSelect&=~VIC_BIT(VIC_WDT);
> > > > VICIntEnable=VIC_BIT(VIC_WDT);
> > > > VICVectCntl3=VIC_ENABLE|VIC_WDT;
> > > > VICVectAddr3=(uint32_t)WDT_interrupt;
> > > >
> > > > WDTC = WDT_FEED_VALUE;
> > > > WDMOD = WDEN; // Watchdog Interrupt Enable
> > > >
> > > > WDFEED = 0xAA; // Feeding sequence
> > > > WDFEED = 0x55;
> > > > }
> > > >
> > >
> > > The WDTOF flag can be cleared softwarely only after external
reset and
> > > not on watch dog interrupt. You have to disable the interrupt itself
> > > else the result you get !!!!
> > >
> > >
> > > Suvidh
> > >
> >
> > What is the purpose of this interrupt then, if it can be used only
once?
> >
> > Regards
> > Klemen
> >
> Klemen,
> Watchdog interrupt or reset occurs if you have some problems in the
> execution say a spike had put your software flow in unpredictable
> results. Hence resuming from this interrupt will be useless.
> You can use the interrupt to debug or inform through some LED for
> system problem. Also may log some data if possible for your debugging
> purpose.
> Hence letting the interrupt run will not be a watchdog functionality.
> Right ?
> Suvdih
>
I was thinking of using watch dog as timer (i know it is not its basic
purpose). If there would be a way to clear the inteerupt flag in ISR,
the watch dog wouldn't lose functionality, but it would gain it. I
don't know why philips limited this option.
Regards
Klemen
Reply by ●February 8, 20072007-02-08
--- In l..., "klemen_dovrtel"
wrote:
> I was thinking of using watch dog as timer (i know it is not its basic
> purpose). If there would be a way to clear the inteerupt flag in ISR,
> the watch dog wouldn't lose functionality, but it would gain it. I
> don't know why philips limited this option.
>
Most processors dont even have a Watchdog interupt, the wdog resets
the processor full stop. Having the possibility to set an interupt is
useful for debugging, but would not seem to have much role in using it
in production unless you specifficaly wished to reset by other means
and the wdog code went into a loop.
BTW, I believe the wdog module is inhereted from ARM, not phillips.
As virtually any serious embedded app uses a watchdog, there would
seem to be little point in allowing it to be used "also" as another timer.
BTW, if you really are stuck for timers and you have an unused UART
then you could always time by sending characters ;-)
wrote:
> I was thinking of using watch dog as timer (i know it is not its basic
> purpose). If there would be a way to clear the inteerupt flag in ISR,
> the watch dog wouldn't lose functionality, but it would gain it. I
> don't know why philips limited this option.
>
Most processors dont even have a Watchdog interupt, the wdog resets
the processor full stop. Having the possibility to set an interupt is
useful for debugging, but would not seem to have much role in using it
in production unless you specifficaly wished to reset by other means
and the wdog code went into a loop.
BTW, I believe the wdog module is inhereted from ARM, not phillips.
As virtually any serious embedded app uses a watchdog, there would
seem to be little point in allowing it to be used "also" as another timer.
BTW, if you really are stuck for timers and you have an unused UART
then you could always time by sending characters ;-)
Reply by ●February 9, 20072007-02-09
--- In l..., "nonuckingfumber" wrote:
>
> --- In l..., "klemen_dovrtel"
> wrote:
>
> > I was thinking of using watch dog as timer (i know it is not its basic
> > purpose). If there would be a way to clear the inteerupt flag in ISR,
> > the watch dog wouldn't lose functionality, but it would gain it. I
> > don't know why philips limited this option.
> >
> Most processors dont even have a Watchdog interupt, the wdog resets
> the processor full stop. Having the possibility to set an interupt is
> useful for debugging, but would not seem to have much role in using it
> in production unless you specifficaly wished to reset by other means
> and the wdog code went into a loop.
>
> BTW, I believe the wdog module is inhereted from ARM, not phillips.
>
> As virtually any serious embedded app uses a watchdog, there would
> seem to be little point in allowing it to be used "also" as another
timer.
>
> BTW, if you really are stuck for timers and you have an unused UART
> then you could always time by sending characters ;-)
>
I would use it as watchdog, if it would be good, so i tried to use it
as timer. :)
I saw posts on this mailing list about the problems with watch dog. If
the interrupt accur during feeding (right after WDFEED = 0xAA), the
watch dog will trigger reset, but if you disable interrupts before
feeding, then you have to be aware of possible spurious inerrupts
after enableng interrupts again (not to mention that you missed all
the interrupts while feeding the watch dog). So it is useless?
>
> --- In l..., "klemen_dovrtel"
> wrote:
>
> > I was thinking of using watch dog as timer (i know it is not its basic
> > purpose). If there would be a way to clear the inteerupt flag in ISR,
> > the watch dog wouldn't lose functionality, but it would gain it. I
> > don't know why philips limited this option.
> >
> Most processors dont even have a Watchdog interupt, the wdog resets
> the processor full stop. Having the possibility to set an interupt is
> useful for debugging, but would not seem to have much role in using it
> in production unless you specifficaly wished to reset by other means
> and the wdog code went into a loop.
>
> BTW, I believe the wdog module is inhereted from ARM, not phillips.
>
> As virtually any serious embedded app uses a watchdog, there would
> seem to be little point in allowing it to be used "also" as another
timer.
>
> BTW, if you really are stuck for timers and you have an unused UART
> then you could always time by sending characters ;-)
>
I would use it as watchdog, if it would be good, so i tried to use it
as timer. :)
I saw posts on this mailing list about the problems with watch dog. If
the interrupt accur during feeding (right after WDFEED = 0xAA), the
watch dog will trigger reset, but if you disable interrupts before
feeding, then you have to be aware of possible spurious inerrupts
after enableng interrupts again (not to mention that you missed all
the interrupts while feeding the watch dog). So it is useless?
Reply by ●February 9, 20072007-02-09
--- In l..., "klemen_dovrtel"
wrote:
> I would use it as watchdog, if it would be good, so i tried to use it
> as timer. :)
>
> I saw posts on this mailing list about the problems with watch dog. If
> the interrupt accur during feeding (right after WDFEED = 0xAA), the
> watch dog will trigger reset, but if you disable interrupts before
> feeding, then you have to be aware of possible spurious inerrupts
> after enableng interrupts again (not to mention that you missed all
> the interrupts while feeding the watch dog). So it is useless?
>
Er, no: not useless. An off-chip watchdog is always preferable, but for
what it is, it works just fine.
As you point out, you should disable interrupts for the duration of the
feed sequence, no different from any other piece of code that has to
run without interrupts enabled. As the feed sequence is short, there's
no real problem. You don't get spurious interrupts after a
disable/enable sequence, nor will you miss any interrupts that happened
when they were disabled.
So where's the problem?
Brendan
wrote:
> I would use it as watchdog, if it would be good, so i tried to use it
> as timer. :)
>
> I saw posts on this mailing list about the problems with watch dog. If
> the interrupt accur during feeding (right after WDFEED = 0xAA), the
> watch dog will trigger reset, but if you disable interrupts before
> feeding, then you have to be aware of possible spurious inerrupts
> after enableng interrupts again (not to mention that you missed all
> the interrupts while feeding the watch dog). So it is useless?
>
Er, no: not useless. An off-chip watchdog is always preferable, but for
what it is, it works just fine.
As you point out, you should disable interrupts for the duration of the
feed sequence, no different from any other piece of code that has to
run without interrupts enabled. As the feed sequence is short, there's
no real problem. You don't get spurious interrupts after a
disable/enable sequence, nor will you miss any interrupts that happened
when they were disabled.
So where's the problem?
Brendan
Reply by ●February 9, 20072007-02-09
> As virtually any serious embedded app uses a
watchdog, there would
> seem to be little point in allowing it to be used "also" as another
timer.
In 'any serious embedded app' you do not rely on a built-in,
electrically unlatchable (via noise) software enabled watchdog anyway.
Enjoy the snow :)
> seem to be little point in allowing it to be used "also" as another
timer.
In 'any serious embedded app' you do not rely on a built-in,
electrically unlatchable (via noise) software enabled watchdog anyway.
Enjoy the snow :)
Reply by ●February 10, 20072007-02-10
You can reset watchdog with feed sequence at reqular intervals either in
timer isr or in your code to avoid watchdog reset.
On 2/9/07, Brendan Murphy wrote:
>
> --- In l... ,
> "klemen_dovrtel"
> wrote:
>
> > I would use it as watchdog, if it would be good, so i tried to use it
> > as timer. :)
> >
> > I saw posts on this mailing list about the problems with watch dog. If
> > the interrupt accur during feeding (right after WDFEED = 0xAA), the
> > watch dog will trigger reset, but if you disable interrupts before
> > feeding, then you have to be aware of possible spurious inerrupts
> > after enableng interrupts again (not to mention that you missed all
> > the interrupts while feeding the watch dog). So it is useless?
> > Er, no: not useless. An off-chip watchdog is always preferable, but for
> what it is, it works just fine.
>
> As you point out, you should disable interrupts for the duration of the
> feed sequence, no different from any other piece of code that has to
> run without interrupts enabled. As the feed sequence is short, there's
> no real problem. You don't get spurious interrupts after a
> disable/enable sequence, nor will you miss any interrupts that happened
> when they were disabled.
>
> So where's the problem?
>
> Brendan
>
timer isr or in your code to avoid watchdog reset.
On 2/9/07, Brendan Murphy wrote:
>
> --- In l... ,
> "klemen_dovrtel"
> wrote:
>
> > I would use it as watchdog, if it would be good, so i tried to use it
> > as timer. :)
> >
> > I saw posts on this mailing list about the problems with watch dog. If
> > the interrupt accur during feeding (right after WDFEED = 0xAA), the
> > watch dog will trigger reset, but if you disable interrupts before
> > feeding, then you have to be aware of possible spurious inerrupts
> > after enableng interrupts again (not to mention that you missed all
> > the interrupts while feeding the watch dog). So it is useless?
> > Er, no: not useless. An off-chip watchdog is always preferable, but for
> what it is, it works just fine.
>
> As you point out, you should disable interrupts for the duration of the
> feed sequence, no different from any other piece of code that has to
> run without interrupts enabled. As the feed sequence is short, there's
> no real problem. You don't get spurious interrupts after a
> disable/enable sequence, nor will you miss any interrupts that happened
> when they were disabled.
>
> So where's the problem?
>
> Brendan
>
