I'm seeing some odd WDT behaviour - need a reality check please....
According to the UM :
"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."
My reading of this is that as long as the 55 is the next thing written into the
WDT register space,
the delay between writing the AA and the 55 is not important,provided of course
that it is within
the WDT timeout value, and that no other registers in the WDT address space are
accessed inbetween.
However I appear to be seeing WDT resets occurring, I think, when an interrupt
occurs between the
AA and the 55. Disabling interrupts between writing the 2 values appears to make
the problem go
away. (I say appears as this is one of those nasty problems that only happens
occasionally...)
I have now confirmed (by setting IO pins to flag the WDT feed and interrupt
entry) that the spurious
reset occurs when an interrupt occurs between the AA and the 55.
I am wondering if there is some undocumented maximum delay requirement for
writing the 2 bytes to
WDFEED, or if there is something like an address decoding issue causing some I/O
areas other than
the WDT area to spuriously trigger the WDT.
The interrupt is a rather frequent PWM timer interrupt, which sends some data to
the SSP port. It is
a FIQ, although I vaguely recall seeing something similar on the LPC2103 using
IRQs.
I've not looked at the fine details of the timing yet, but from what I can
see so far, I think the
reset is occurring at the instant of the interrupt happenning, not due to any
hardware accesses done
by the interrupt code.
In my app I can live with disabling ints when resetting the WDT, but it would be
good to understand
exactly what's happenning...
LPC213x/01 watchdog issue
Started by ●September 11, 2007
Reply by ●September 11, 20072007-09-11
What you are seeing is a "feature". In the case of the LPC2148, the
User Manual in 20.1 Features includes:
"Incorrect/Incomplete feed sequence causes reset/interrupt if enabled."
I didn't find any description of "incomplete" but I suspect that a
significant delay between writing the two values constitutes "incomplete".
It is clear that the PLL feed sequence can not be interrupted (Section
3.8.6) and I would extend that concept to the WDT feed.
Richard
--- In l..., Mike Harrison wrote:
>
> I'm seeing some odd WDT behaviour - need a reality check please....
>
> According to the UM :
> "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."
>
> My reading of this is that as long as the 55 is the next thing
written into the WDT register space,
> the delay between writing the AA and the 55 is not
important,provided of course that it is within
> the WDT timeout value, and that no other registers in the WDT
address space are accessed inbetween.
>
> However I appear to be seeing WDT resets occurring, I think, when
an interrupt occurs between the
> AA and the 55. Disabling interrupts between writing the 2 values
appears to make the problem go
> away. (I say appears as this is one of those nasty problems that
only happens occasionally...)
>
> I have now confirmed (by setting IO pins to flag the WDT feed and
interrupt entry) that the spurious
> reset occurs when an interrupt occurs between the AA and the 55.
>
> I am wondering if there is some undocumented maximum delay
requirement for writing the 2 bytes to
> WDFEED, or if there is something like an address decoding issue
causing some I/O areas other than
> the WDT area to spuriously trigger the WDT.
>
> The interrupt is a rather frequent PWM timer interrupt, which sends
some data to the SSP port. It is
> a FIQ, although I vaguely recall seeing something similar on the
LPC2103 using IRQs.
>
> I've not looked at the fine details of the timing yet, but from what
I can see so far, I think the
> reset is occurring at the instant of the interrupt happenning, not
due to any hardware accesses done
> by the interrupt code.
>
> In my app I can live with disabling ints when resetting the WDT, but
it would be good to understand
> exactly what's happenning...
>
User Manual in 20.1 Features includes:
"Incorrect/Incomplete feed sequence causes reset/interrupt if enabled."
I didn't find any description of "incomplete" but I suspect that a
significant delay between writing the two values constitutes "incomplete".
It is clear that the PLL feed sequence can not be interrupted (Section
3.8.6) and I would extend that concept to the WDT feed.
Richard
--- In l..., Mike Harrison wrote:
>
> I'm seeing some odd WDT behaviour - need a reality check please....
>
> According to the UM :
> "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."
>
> My reading of this is that as long as the 55 is the next thing
written into the WDT register space,
> the delay between writing the AA and the 55 is not
important,provided of course that it is within
> the WDT timeout value, and that no other registers in the WDT
address space are accessed inbetween.
>
> However I appear to be seeing WDT resets occurring, I think, when
an interrupt occurs between the
> AA and the 55. Disabling interrupts between writing the 2 values
appears to make the problem go
> away. (I say appears as this is one of those nasty problems that
only happens occasionally...)
>
> I have now confirmed (by setting IO pins to flag the WDT feed and
interrupt entry) that the spurious
> reset occurs when an interrupt occurs between the AA and the 55.
>
> I am wondering if there is some undocumented maximum delay
requirement for writing the 2 bytes to
> WDFEED, or if there is something like an address decoding issue
causing some I/O areas other than
> the WDT area to spuriously trigger the WDT.
>
> The interrupt is a rather frequent PWM timer interrupt, which sends
some data to the SSP port. It is
> a FIQ, although I vaguely recall seeing something similar on the
LPC2103 using IRQs.
>
> I've not looked at the fine details of the timing yet, but from what
I can see so far, I think the
> reset is occurring at the instant of the interrupt happenning, not
due to any hardware accesses done
> by the interrupt code.
>
> In my app I can live with disabling ints when resetting the WDT, but
it would be good to understand
> exactly what's happenning...
>
Reply by ●September 11, 20072007-09-11
On Tue, 11 Sep 2007 15:23:15 -0000, you wrote:
>What you are seeing is a "feature". In the case of the LPC2148, the
>User Manual in 20.1 Features includes:
>
>"Incorrect/Incomplete feed sequence causes reset/interrupt if enabled."
>
>I didn't find any description of "incomplete" but I suspect that a
>significant delay between writing the two values constitutes "incomplete".
>
>It is clear that the PLL feed sequence can not be interrupted (Section
>3.8.6) and I would extend that concept to the WDT feed.
The only definition of 'incomplete' is the text below referring to accesses 'in the watchdog
register space'
I'm in the process of narrowing this down, and so far, it appears that accesses to I/O areas outside
the WDT area, within an interrupt, cause a spurious reset.
Accessing the same I/O areas in the foreground task between the WD feed sequence have no effect.
As far as I can tell, it does NOT seem to be a function of the time interval between the 2 WDT write
operations.
One of the I/O areas that causes it is T0IR, which is a little unfortunate as this needs to be
written to clear the timer interrupt....
I'm investigating further...
>Richard
>
>--- In l..., Mike Harrison wrote:
>>
>> I'm seeing some odd WDT behaviour - need a reality check please....
>>
>> According to the UM :
>> "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."
>>
>> My reading of this is that as long as the 55 is the next thing
>written into the WDT register space,
>> the delay between writing the AA and the 55 is not
>important,provided of course that it is within
>> the WDT timeout value, and that no other registers in the WDT
>address space are accessed inbetween.
>>
>> However I appear to be seeing WDT resets occurring, I think, when
>an interrupt occurs between the
>> AA and the 55. Disabling interrupts between writing the 2 values
>appears to make the problem go
>> away. (I say appears as this is one of those nasty problems that
>only happens occasionally...)
>>
>> I have now confirmed (by setting IO pins to flag the WDT feed and
>interrupt entry) that the spurious
>> reset occurs when an interrupt occurs between the AA and the 55.
>>
>> I am wondering if there is some undocumented maximum delay
>requirement for writing the 2 bytes to
>> WDFEED, or if there is something like an address decoding issue
>causing some I/O areas other than
>> the WDT area to spuriously trigger the WDT.
>>
>> The interrupt is a rather frequent PWM timer interrupt, which sends
>some data to the SSP port. It is
>> a FIQ, although I vaguely recall seeing something similar on the
>LPC2103 using IRQs.
>>
>> I've not looked at the fine details of the timing yet, but from what
>I can see so far, I think the
>> reset is occurring at the instant of the interrupt happenning, not
>due to any hardware accesses done
>> by the interrupt code.
>>
>> In my app I can live with disabling ints when resetting the WDT, but
>it would be good to understand
>> exactly what's happenning...
>>Yahoo! Groups Links
>
>What you are seeing is a "feature". In the case of the LPC2148, the
>User Manual in 20.1 Features includes:
>
>"Incorrect/Incomplete feed sequence causes reset/interrupt if enabled."
>
>I didn't find any description of "incomplete" but I suspect that a
>significant delay between writing the two values constitutes "incomplete".
>
>It is clear that the PLL feed sequence can not be interrupted (Section
>3.8.6) and I would extend that concept to the WDT feed.
The only definition of 'incomplete' is the text below referring to accesses 'in the watchdog
register space'
I'm in the process of narrowing this down, and so far, it appears that accesses to I/O areas outside
the WDT area, within an interrupt, cause a spurious reset.
Accessing the same I/O areas in the foreground task between the WD feed sequence have no effect.
As far as I can tell, it does NOT seem to be a function of the time interval between the 2 WDT write
operations.
One of the I/O areas that causes it is T0IR, which is a little unfortunate as this needs to be
written to clear the timer interrupt....
I'm investigating further...
>Richard
>
>--- In l..., Mike Harrison wrote:
>>
>> I'm seeing some odd WDT behaviour - need a reality check please....
>>
>> According to the UM :
>> "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."
>>
>> My reading of this is that as long as the 55 is the next thing
>written into the WDT register space,
>> the delay between writing the AA and the 55 is not
>important,provided of course that it is within
>> the WDT timeout value, and that no other registers in the WDT
>address space are accessed inbetween.
>>
>> However I appear to be seeing WDT resets occurring, I think, when
>an interrupt occurs between the
>> AA and the 55. Disabling interrupts between writing the 2 values
>appears to make the problem go
>> away. (I say appears as this is one of those nasty problems that
>only happens occasionally...)
>>
>> I have now confirmed (by setting IO pins to flag the WDT feed and
>interrupt entry) that the spurious
>> reset occurs when an interrupt occurs between the AA and the 55.
>>
>> I am wondering if there is some undocumented maximum delay
>requirement for writing the 2 bytes to
>> WDFEED, or if there is something like an address decoding issue
>causing some I/O areas other than
>> the WDT area to spuriously trigger the WDT.
>>
>> The interrupt is a rather frequent PWM timer interrupt, which sends
>some data to the SSP port. It is
>> a FIQ, although I vaguely recall seeing something similar on the
>LPC2103 using IRQs.
>>
>> I've not looked at the fine details of the timing yet, but from what
>I can see so far, I think the
>> reset is occurring at the instant of the interrupt happenning, not
>due to any hardware accesses done
>> by the interrupt code.
>>
>> In my app I can live with disabling ints when resetting the WDT, but
>it would be good to understand
>> exactly what's happenning...
>>Yahoo! Groups Links
>
Reply by ●September 11, 20072007-09-11
Mike Harrison Wrote
>According to the UM :
>"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."
>
>My reading of this is that as long as the 55 is the next thing written
into the WDT
>register space,
>the delay between writing the AA and the 55 is not important,provided of
course that it
>is within
>the WDT timeout value, and that no other registers in the WDT address
space are accessed >inbetween.
>
>I have now confirmed (by setting IO pins to flag the WDT feed and
interrupt entry) that
>the spurious
>reset occurs when an interrupt occurs between the AA and the 55.
I suspect a documentation bug. Previous data sheets (for other variants)
indicated that you needed to have back to back writes on the same bus or
the feed would be incorrect (both PLL and WDT appear to use the same
mechanism). I suspect they mean register space to indicate the APB but I
agree your interpretation is the logical one.
Robert
--------------------------------
mail2web.com - Microsoft Exchange solutions from a leading provider -
http://link.mail2web.com/Business/Exchange
>According to the UM :
>"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."
>
>My reading of this is that as long as the 55 is the next thing written
into the WDT
>register space,
>the delay between writing the AA and the 55 is not important,provided of
course that it
>is within
>the WDT timeout value, and that no other registers in the WDT address
space are accessed >inbetween.
>
>I have now confirmed (by setting IO pins to flag the WDT feed and
interrupt entry) that
>the spurious
>reset occurs when an interrupt occurs between the AA and the 55.
I suspect a documentation bug. Previous data sheets (for other variants)
indicated that you needed to have back to back writes on the same bus or
the feed would be incorrect (both PLL and WDT appear to use the same
mechanism). I suspect they mean register space to indicate the APB but I
agree your interpretation is the logical one.
Robert
--------------------------------
mail2web.com - Microsoft Exchange solutions from a leading provider -
http://link.mail2web.com/Business/Exchange
Reply by ●September 11, 20072007-09-11
On Tue, 11 Sep 2007 11:46:47 -0400, you wrote:
>Mike Harrison Wrote
>>According to the UM :
>>"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."
>>
>>My reading of this is that as long as the 55 is the next thing written
>into the WDT
>>register space,
>>the delay between writing the AA and the 55 is not important,provided of
>course that it
>>is within
>>the WDT timeout value, and that no other registers in the WDT address
>space are accessed >inbetween.
>>>I have now confirmed (by setting IO pins to flag the WDT feed and
>interrupt entry) that
>>the spurious
>>reset occurs when an interrupt occurs between the AA and the 55.
>
>I suspect a documentation bug. Previous data sheets (for other variants)
>indicated that you needed to have back to back writes on the same bus or
>the feed would be incorrect (both PLL and WDT appear to use the same
>mechanism). I suspect they mean register space to indicate the APB but I
>agree your interpretation is the logical one.
I now think that is the case, i.e. any APB area can cause it - I think I may have been getting
confused by the fact that FIO accesses didn't trigger it.
This is a rather dumb design decision (or maybe something they intended to fix, hence the wording in
the UM), as it effectively makes it difficult to attain the best possible interrupt latency when the
WDT is enabled. It would be much better if it worked as documented, i.e. only acesses within the WDT
address space caused a reset.
In some circumstances you may be able to synchronise the WDT reset with a time you know when certain
interrupts shouldn't be happenning, but this not always practical.
>Mike Harrison Wrote
>>According to the UM :
>>"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."
>>
>>My reading of this is that as long as the 55 is the next thing written
>into the WDT
>>register space,
>>the delay between writing the AA and the 55 is not important,provided of
>course that it
>>is within
>>the WDT timeout value, and that no other registers in the WDT address
>space are accessed >inbetween.
>>>I have now confirmed (by setting IO pins to flag the WDT feed and
>interrupt entry) that
>>the spurious
>>reset occurs when an interrupt occurs between the AA and the 55.
>
>I suspect a documentation bug. Previous data sheets (for other variants)
>indicated that you needed to have back to back writes on the same bus or
>the feed would be incorrect (both PLL and WDT appear to use the same
>mechanism). I suspect they mean register space to indicate the APB but I
>agree your interpretation is the logical one.
I now think that is the case, i.e. any APB area can cause it - I think I may have been getting
confused by the fact that FIO accesses didn't trigger it.
This is a rather dumb design decision (or maybe something they intended to fix, hence the wording in
the UM), as it effectively makes it difficult to attain the best possible interrupt latency when the
WDT is enabled. It would be much better if it worked as documented, i.e. only acesses within the WDT
address space caused a reset.
In some circumstances you may be able to synchronise the WDT reset with a time you know when certain
interrupts shouldn't be happenning, but this not always practical.
Reply by ●September 11, 20072007-09-11
On Tue, 11 Sep 2007 11:46:47 -0400, you wrote:
>Mike Harrison Wrote
>>According to the UM :
>>"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."
>>
>>My reading of this is that as long as the 55 is the next thing written
>into the WDT
>>register space,
>>the delay between writing the AA and the 55 is not important,provided of
>course that it
>>is within
>>the WDT timeout value, and that no other registers in the WDT address
>space are accessed >inbetween.
>>>I have now confirmed (by setting IO pins to flag the WDT feed and
>interrupt entry) that
>>the spurious
>>reset occurs when an interrupt occurs between the AA and the 55.
>
>I suspect a documentation bug. Previous data sheets (for other variants)
>indicated that you needed to have back to back writes on the same bus or
>the feed would be incorrect (both PLL and WDT appear to use the same
>mechanism). I suspect they mean register space to indicate the APB but I
>agree your interpretation is the logical one.
>
>Robert
I just had a reply from NXP confirming that it is an error in the docs as described above.
>Mike Harrison Wrote
>>According to the UM :
>>"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."
>>
>>My reading of this is that as long as the 55 is the next thing written
>into the WDT
>>register space,
>>the delay between writing the AA and the 55 is not important,provided of
>course that it
>>is within
>>the WDT timeout value, and that no other registers in the WDT address
>space are accessed >inbetween.
>>>I have now confirmed (by setting IO pins to flag the WDT feed and
>interrupt entry) that
>>the spurious
>>reset occurs when an interrupt occurs between the AA and the 55.
>
>I suspect a documentation bug. Previous data sheets (for other variants)
>indicated that you needed to have back to back writes on the same bus or
>the feed would be incorrect (both PLL and WDT appear to use the same
>mechanism). I suspect they mean register space to indicate the APB but I
>agree your interpretation is the logical one.
>
>Robert
I just had a reply from NXP confirming that it is an error in the docs as described above.
Reply by ●September 11, 20072007-09-11
> I now think that is the case, i.e. any APB area can
cause it - I
think I may have been getting
> confused by the fact that FIO accesses didn't trigger it.
>
> This is a rather dumb design decision (or maybe something they
intended to fix, hence the wording in
> the UM), as it effectively makes it difficult to attain the best
possible interrupt latency when the
> WDT is enabled. It would be much better if it worked as documented,
i.e. only acesses within the WDT
> address space caused a reset.
>
> In some circumstances you may be able to synchronise the WDT reset
with a time you know when certain
> interrupts shouldn't be happenning, but this not always practical.
>
The problem with any WDT is to prevent errant programming from
resetting it. To that end, it seems reasonable to protect the gadget
by imposing limitations on how it is reset and how it handles
"incomplete" feed sequences. Only perfect code should continue to run
without a WDT reset. Code that bumps into something that looks like a
portion of a WDT reset must be trapped.
Then too, even if you succeed in getting some non-consecutive sequence
to work with THIS silicon revision, there is no assurance it will work
with the next one.
If you have a spare timer, you could interrupt somewhat before the WDT
times out and do the WDT reset.
Richard
think I may have been getting
> confused by the fact that FIO accesses didn't trigger it.
>
> This is a rather dumb design decision (or maybe something they
intended to fix, hence the wording in
> the UM), as it effectively makes it difficult to attain the best
possible interrupt latency when the
> WDT is enabled. It would be much better if it worked as documented,
i.e. only acesses within the WDT
> address space caused a reset.
>
> In some circumstances you may be able to synchronise the WDT reset
with a time you know when certain
> interrupts shouldn't be happenning, but this not always practical.
>
The problem with any WDT is to prevent errant programming from
resetting it. To that end, it seems reasonable to protect the gadget
by imposing limitations on how it is reset and how it handles
"incomplete" feed sequences. Only perfect code should continue to run
without a WDT reset. Code that bumps into something that looks like a
portion of a WDT reset must be trapped.
Then too, even if you succeed in getting some non-consecutive sequence
to work with THIS silicon revision, there is no assurance it will work
with the next one.
If you have a spare timer, you could interrupt somewhat before the WDT
times out and do the WDT reset.
Richard
Reply by ●September 11, 20072007-09-11
--- In l..., Mike Harrison wrote:
> But it should not be so fussy that you effectively have to disable
interrupts (albeit briefly) for
> it to be useful, as this unnecessarily degrades interrupt latency.
>
> If it behaved as per the manual, i.e. only an access within the WDT
space causes an immediate reset,
> it would be much more sensible, and would not compromise system
reliability significantly.
>
Agreed - I'd definitely class it as a bug rather than a feature.
On one product set, we use the watchdog and disable interrupts when
feeding it - no big deal, as it's only a few cycles every second.
On the other, for timing reasons we use FIQs that are never disabled.
Luckily we don't need a watchdog on that system (a sensor used in a lab
environment): I'm not too sure what we'd do if we needed one (probably
use an external watchdog).
Brendan
> But it should not be so fussy that you effectively have to disable
interrupts (albeit briefly) for
> it to be useful, as this unnecessarily degrades interrupt latency.
>
> If it behaved as per the manual, i.e. only an access within the WDT
space causes an immediate reset,
> it would be much more sensible, and would not compromise system
reliability significantly.
>
Agreed - I'd definitely class it as a bug rather than a feature.
On one product set, we use the watchdog and disable interrupts when
feeding it - no big deal, as it's only a few cycles every second.
On the other, for timing reasons we use FIQs that are never disabled.
Luckily we don't need a watchdog on that system (a sensor used in a lab
environment): I'm not too sure what we'd do if we needed one (probably
use an external watchdog).
Brendan
Reply by ●September 11, 20072007-09-11
On Tue, 11 Sep 2007 19:32:07 -0000, you wrote:
>--- In l..., Mike Harrison wrote:
>
>> But it should not be so fussy that you effectively have to disable
>interrupts (albeit briefly) for
>> it to be useful, as this unnecessarily degrades interrupt latency.
>>
>> If it behaved as per the manual, i.e. only an access within the WDT
>space causes an immediate reset,
>> it would be much more sensible, and would not compromise system
>reliability significantly.
>>Agreed - I'd definitely class it as a bug rather than a feature.
>
>On one product set, we use the watchdog and disable interrupts when
>feeding it - no big deal, as it's only a few cycles every second.
>
>On the other, for timing reasons we use FIQs that are never disabled.
>Luckily we don't need a watchdog on that system (a sensor used in a lab
>environment): I'm not too sure what we'd do if we needed one (probably
>use an external watchdog).
well I suppose you could always kick the watchdog on exit from the FIQ code...;-)
>--- In l..., Mike Harrison wrote:
>
>> But it should not be so fussy that you effectively have to disable
>interrupts (albeit briefly) for
>> it to be useful, as this unnecessarily degrades interrupt latency.
>>
>> If it behaved as per the manual, i.e. only an access within the WDT
>space causes an immediate reset,
>> it would be much more sensible, and would not compromise system
>reliability significantly.
>>Agreed - I'd definitely class it as a bug rather than a feature.
>
>On one product set, we use the watchdog and disable interrupts when
>feeding it - no big deal, as it's only a few cycles every second.
>
>On the other, for timing reasons we use FIQs that are never disabled.
>Luckily we don't need a watchdog on that system (a sensor used in a lab
>environment): I'm not too sure what we'd do if we needed one (probably
>use an external watchdog).
well I suppose you could always kick the watchdog on exit from the FIQ code...;-)
Reply by ●September 11, 20072007-09-11
On Tue, 11 Sep 2007 16:57:23 -0000, you wrote:
>> I now think that is the case, i.e. any APB area can cause it - I
>think I may have been getting
>> confused by the fact that FIO accesses didn't trigger it.
>>
>> This is a rather dumb design decision (or maybe something they
>intended to fix, hence the wording in
>> the UM), as it effectively makes it difficult to attain the best
>possible interrupt latency when the
>> WDT is enabled. It would be much better if it worked as documented,
>i.e. only acesses within the WDT
>> address space caused a reset.
>>
>> In some circumstances you may be able to synchronise the WDT reset
>with a time you know when certain
>> interrupts shouldn't be happenning, but this not always practical.
>>The problem with any WDT is to prevent errant programming from
>resetting it.
But it should not be so fussy that you effectively have to disable interrupts (albeit briefly) for
it to be useful, as this unnecessarily degrades interrupt latency.
If it behaved as per the manual, i.e. only an access within the WDT space causes an immediate reset,
it would be much more sensible, and would not compromise system reliability significantly.
>> I now think that is the case, i.e. any APB area can cause it - I
>think I may have been getting
>> confused by the fact that FIO accesses didn't trigger it.
>>
>> This is a rather dumb design decision (or maybe something they
>intended to fix, hence the wording in
>> the UM), as it effectively makes it difficult to attain the best
>possible interrupt latency when the
>> WDT is enabled. It would be much better if it worked as documented,
>i.e. only acesses within the WDT
>> address space caused a reset.
>>
>> In some circumstances you may be able to synchronise the WDT reset
>with a time you know when certain
>> interrupts shouldn't be happenning, but this not always practical.
>>The problem with any WDT is to prevent errant programming from
>resetting it.
But it should not be so fussy that you effectively have to disable interrupts (albeit briefly) for
it to be useful, as this unnecessarily degrades interrupt latency.
If it behaved as per the manual, i.e. only an access within the WDT space causes an immediate reset,
it would be much more sensible, and would not compromise system reliability significantly.
