Lpc2000

Hi,

I am using an LPC2138 with IAR compiler.

Turning on WDT for the first time. I was testing it a few different 
ways. One way involves a Data Abort IRQ. My data abort IRQ falls into 
an endless loop (on purpose). It seems that when I create an illegal 
access to trigger the data abort IRQ the WDT never fires. The code 
enters the Data Abort IRQ, hits my endless loop and sits there 
forever - no WDT reset! Anyone know why?

Thanks group

--- In lpc2000@yahoogroups.com, "relentless_6995" <bobd@...> wrote:

> Turning on WDT for the first time. I was testing it a few different 
> ways. One way involves a Data Abort IRQ. My data abort IRQ falls into 
> an endless loop (on purpose). It seems that when I create an illegal 
> access to trigger the data abort IRQ the WDT never fires. The code 
> enters the Data Abort IRQ, hits my endless loop and sits there 
> forever - no WDT reset! Anyone know why?

It is because the watchdog timer on LPC is not wired to the Reset
interrupt priority level of ARM7.  Thus the Data Abort exception that
you are not dismissing locks out watchdog reset.

You could go down the chain (Data Abort, FIQ, IRQ, Prefetch Abort,
then Undefined Instruction/SWI to discover at what level the watchdog
reset is wired to ... I would if I relied on the watchdog to get me
out undefined situations, but then I only use the watchdog to trigger
a reset when I want it to.

It is not clear if this behaviour in LPC is a design or implementation
error.

Jaya

At 12:01 AM 4/18/2006 +0000, jayasooriah wrote:
>--- In lpc2000@yahoogroups.com, "relentless_6995" <bobd@...> wrote:
>
> > Turning on WDT for the first time. I was testing it a few different
> > ways. One way involves a Data Abort IRQ. My data abort IRQ falls into
> > an endless loop (on purpose). It seems that when I create an illegal
> > access to trigger the data abort IRQ the WDT never fires. The code
> > enters the Data Abort IRQ, hits my endless loop and sits there
> > forever - no WDT reset! Anyone know why?
>
>It is because the watchdog timer on LPC is not wired to the Reset
>interrupt priority level of ARM7.  Thus the Data Abort exception that
>you are not dismissing locks out watchdog reset.

<snip>
>if I relied on the watchdog to get me
>out undefined situations, but then I only use the watchdog to trigger
>a reset when I want it to.

Well, there are ways of getting into undefined situations that don't 
involve SW.  They have to be guarded against as well.  A watchdog may not 
be perfect and an internal one less so than an external WD but it is part 
of good defensive practice.

>It is not clear if this behaviour in LPC is a design or implementation
>error.

Yikes, if true that renders the WDT useless.  Have you verified this?

I'll have to set aside some time to check it out.


" '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/

Jaya,

The watchdog generates a reset when it expires - see any of the user 
Manual's description of the watchdog and reset sequence for details.

From memory, reset is the highest priority exception on an ARM and 
cannot be masked. Therefore, whatever is being observed in this 
case, isn't related to priority.

If you have some specific evidence of a problem with the watchdog, 
maybe you could post the details, instead of making vague references 
to it?

Thanks
Brendan

--- In lpc2000@yahoogroups.com, "jayasooriah" <jayasooriah@...> 
wrote:
> It is because the watchdog timer on LPC is not wired to the Reset
> interrupt priority level of ARM7.  Thus the Data Abort exception 
that
> you are not dismissing locks out watchdog reset.
> 
> You could go down the chain (Data Abort, FIQ, IRQ, Prefetch Abort,
> then Undefined Instruction/SWI to discover at what level the 
watchdog
> reset is wired to ... I would if I relied on the watchdog to get me
> out undefined situations, but then I only use the watchdog to 
trigger
> a reset when I want it to.
> 
> It is not clear if this behaviour in LPC is a design or 
implementation

> error.
> 
> Jaya
>

No comment.

--- In lpc2000@yahoogroups.com, "brendanmurphy37"
<brendanmurphy37@...> wrote:

> If you have some specific evidence of a problem with the watchdog, 
> maybe you could post the details, instead of making vague references 
> to it?

Sorry I cannot help you with your needs.

By my understanding of the original problem he said he is deliberately
causing a data abort exception to be raised and while processing this
exception has created an endless loop.

Now by my understanding of the Philips LPC's they are only capable of
dealing with single IRQ's. I.e. they have no ability to stack IRQ's and
branch from within a current IRQ to service one that is a higher priority
automatically (you could always do this yourself inside the IRQ if you
wanted to I guess).

It strikes me that this being the case he will never actually fully service
and clear the original IRQ to allow an update of the CPSR, he'll simply sit
inside it forever and as such it doesn't really matter how many other IRQ's
fire as he'll never get back to a state whereby the CPSR reflects that he
has a new IRQ to do something with - hence his WDT will create a reset IRQ
which will never get actioned...

Is this not what we're seeing here or did I misunderstand something?

I'll have to have a quick play with a device and see if I can replicate
this.

Andy

-----Original Message-----
From: lpc2000@yahoogroups.com [mailto:lpc2000@yahoogroups.com]On Behalf
Of brendanmurphy37
Sent: 18 April 2006 10:10
To: lpc2000@yahoogroups.com
Subject: [lpc2000] Re: WDT reset while in an ISR



Jaya,

The watchdog generates a reset when it expires - see any of the user
Manual's description of the watchdog and reset sequence for details.

From memory, reset is the highest priority exception on an ARM and
cannot be masked. Therefore, whatever is being observed in this
case, isn't related to priority.

If you have some specific evidence of a problem with the watchdog,
maybe you could post the details, instead of making vague references
to it?

Thanks
Brendan

--- In lpc2000@yahoogroups.com, "jayasooriah" <jayasooriah@...>
wrote:
> It is because the watchdog timer on LPC is not wired to the Reset
> interrupt priority level of ARM7.  Thus the Data Abort exception
that
> you are not dismissing locks out watchdog reset.
>
> You could go down the chain (Data Abort, FIQ, IRQ, Prefetch Abort,
> then Undefined Instruction/SWI to discover at what level the
watchdog
> reset is wired to ... I would if I relied on the watchdog to get me
> out undefined situations, but then I only use the watchdog to
trigger
> a reset when I want it to.
>
> It is not clear if this behaviour in LPC is a design or
implementation
> error.
>
> Jaya
>







Yahoo! Groups Links

Jaya,

I don't have any needs, nor do I need your help.

You made the following statement:

"It is because the watchdog timer on LPC is not wired to the Reset
interrupt priority level of ARM7"

This contradicts information in the User Manuals, where it is stated 
that the watchdog generates a reset.

Furthermore, there is no such thing as a "reset interrupt priority 
level". A reset is a type of exception (as is an IRQ or FIR 
interrupt). Resets have a higher priority than interrupts (and all 
other exceptions, such as data aborts etc.).

See the ARM ARM for details.

All I'm asking is that if you have information to the contrary, 
please share it rather than making incorrect statements and vague 
claims about problems.

Best wishes
Brendan

--- In lpc2000@yahoogroups.com, "jayasooriah" <jayasooriah@...> wrote:
>
> No comment.
> 
> --- In lpc2000@yahoogroups.com, "brendanmurphy37"
> <brendanmurphy37@> wrote:
> 
> > If you have some specific evidence of a problem with the 
watchdog, 
> > maybe you could post the details, instead of making vague 
references 

> > to it?
> 
> Sorry I cannot help you with your needs.
>

Andy,

Check out the ARM Architecture Reference Manual for details on 
exceptions (section 2.6 in the edition I'm looking at). Reset, IRQ, 
data abort are all types of exception. They have a fixed priority 
order defined by the architecture. Masking out IRQs will not mask out 
higher priority exceptions, such as FIQs, data aborts or resets.

As far as I know, resets (the highest priority exception) cannot be 
masked out: if one is generated (on the LPC2000 either on the 
external pin, or from the watchdog), it will always be taken.

Without more information from the original poster, it is difficult to 
guess what might be happening.

It would certainly be interesting to see a real example where resets 
do not apear to be serviced. Until someone provides it though, my 
working assumption would tend to be that the informnation from ARM 
and Philips is more than likely correct.

Brendan

--- In lpc2000@yahoogroups.com, "Andrew Berney" <amb@...> wrote:
>
> By my understanding of the original problem he said he is 
deliberately
> causing a data abort exception to be raised and while processing 
this
> exception has created an endless loop.
> 
> Now by my understanding of the Philips LPC's they are only capable 
of
> dealing with single IRQ's. I.e. they have no ability to stack IRQ's 
and
> branch from within a current IRQ to service one that is a higher 
priority
> automatically (you could always do this yourself inside the IRQ if 
you
> wanted to I guess).
> 
> It strikes me that this being the case he will never actually fully 
service
> and clear the original IRQ to allow an update of the CPSR, he'll 
simply sit
> inside it forever and as such it doesn't really matter how many 
other IRQ's
> fire as he'll never get back to a state whereby the CPSR reflects 
that he
> has a new IRQ to do something with - hence his WDT will create a 
reset IRQ
> which will never get actioned...
> 
> Is this not what we're seeing here or did I misunderstand something?
> 
> I'll have to have a quick play with a device and see if I can 
replicate
> this.
> 
> Andy
> 
> -----Original Message-----
> From: lpc2000@yahoogroups.com [mailto:lpc2000@yahoogroups.com]On 
Behalf
> Of brendanmurphy37
> Sent: 18 April 2006 10:10
> To: lpc2000@yahoogroups.com
> Subject: [lpc2000] Re: WDT reset while in an ISR
> 
> 
> 
> Jaya,
> 
> The watchdog generates a reset when it expires - see any of the user
> Manual's description of the watchdog and reset sequence for details.
> 
> From memory, reset is the highest priority exception on an ARM and
> cannot be masked. Therefore, whatever is being observed in this
> case, isn't related to priority.
> 
> If you have some specific evidence of a problem with the watchdog,
> maybe you could post the details, instead of making vague references
> to it?
> 
> Thanks
> Brendan
> 
> --- In lpc2000@yahoogroups.com, "jayasooriah" <jayasooriah@>
> wrote:
> > It is because the watchdog timer on LPC is not wired to the Reset
> > interrupt priority level of ARM7.  Thus the Data Abort exception
> that
> > you are not dismissing locks out watchdog reset.
> >
> > You could go down the chain (Data Abort, FIQ, IRQ, Prefetch Abort,
> > then Undefined Instruction/SWI to discover at what level the
> watchdog
> > reset is wired to ... I would if I relied on the watchdog to get 
me

> > out undefined situations, but then I only use the watchdog to
> trigger
> > a reset when I want it to.
> >
> > It is not clear if this behaviour in LPC is a design or
> implementation
> > error.
> >
> > Jaya
> >
> 
> 
> 
> 
> 
> 
> 
> Yahoo! Groups Links
>

Dear Brendan,

Please refrain from ask me anything if you do not need my help.

I do not wish to engage with you on this or any other topic.

Kind regards,

Jaya

--- In lpc2000@yahoogroups.com, "brendanmurphy37"
<brendanmurphy37@...> wrote:

>
> 
> Jaya,
> 
> I don't have any needs, nor do I need your help.
> 
> You made the following statement:
> 
> "It is because the watchdog timer on LPC is not wired to the Reset
> interrupt priority level of ARM7"
> 
> This contradicts information in the User Manuals, where it is stated 
> that the watchdog generates a reset.
> 
> Furthermore, there is no such thing as a "reset interrupt priority 
> level". A reset is a type of exception (as is an IRQ or FIR 
> interrupt). Resets have a higher priority than interrupts (and all 
> other exceptions, such as data aborts etc.).
> 
> See the ARM ARM for details.
> 
> All I'm asking is that if you have information to the contrary, 
> please share it rather than making incorrect statements and vague 
> claims about problems.
> 
> Best wishes
> Brendan

Hi Andrew,

--- In lpc2000@yahoogroups.com, "Andrew Berney" <amb@...> wrote:
>
> By my understanding of the original problem he said he is deliberately
> causing a data abort exception to be raised and while processing this
> exception has created an endless loop.

Yes you are right in that this is what the original post that started
this thread seemed to suggest.  I responded with what I thought was
going on based on what I know about the six ARM IPLs.

> Now by my understanding of the Philips LPC's they are only capable of
> dealing with single IRQ's. I.e. they have no ability to stack IRQ's and
> branch from within a current IRQ to service one that is a higher
priority
> automatically (you could always do this yourself inside the IRQ if you
> wanted to I guess).

I was not aware of this limitation.  Are you sure?  Is this stated
anywhere?

> It strikes me that this being the case he will never actually fully
service
> and clear the original IRQ to allow an update of the CPSR, he'll
simply sit
> inside it forever and as such it doesn't really matter how many
other IRQ's
> fire as he'll never get back to a state whereby the CPSR reflects
that he
> has a new IRQ to do something with - hence his WDT will create a
reset IRQ
> which will never get actioned...
> 
> Is this not what we're seeing here or did I misunderstand something?
> 
> I'll have to have a quick play with a device and see if I can replicate
> this.

I would be interested in what you find out.  I do not have my jig
handy handy at the moment.

Jaya

--- In lpc2000@yahoogroups.com, "relentless_6995" <bobd@...> wrote:
>
> Hi,
> 
> I am using an LPC2138 with IAR compiler.
> 
> Turning on WDT for the first time. I was testing it a few different 
> ways. One way involves a Data Abort IRQ. My data abort IRQ falls into 
> an endless loop (on purpose). It seems that when I create an illegal 
> access to trigger the data abort IRQ the WDT never fires. The code 
> enters the Data Abort IRQ, hits my endless loop and sits there 
> forever - no WDT reset! Anyone know why?
> 
> Thanks group
>

Did you enable WDMOD[WDRESET] or just WDMOD[WDEN] ?
Without WDMOD[WDRESET] set you do not get a RESET, but just a watchdog
interrupt, which will be just as dependant on your interrupt setup as
other interrupts are.

-- Dave

Jaya,

OK - I'll give up asking you to back your claims, as it doesn't seem 
to work.

I don't see an issue though with pointing out some of the factual 
errors contained in your posts, which is what my last post was mostly 
about.

I would (and have) welcomed such corrections to my own posts in the 
past: it helps prevent inaccurate and misleading information from 
propagating.

Best wishes
Brendan

--- In lpc2000@yahoogroups.com, "jayasooriah" <jayasooriah@...> wrote:
>
> Dear Brendan,
> 
> Please refrain from ask me anything if you do not need my help.
> 
> I do not wish to engage with you on this or any other topic.
> 
> Kind regards,
> 
> Jaya
> 
> --- In lpc2000@yahoogroups.com, "brendanmurphy37"
> <brendanmurphy37@> wrote:
> >
> > 
> > Jaya,
> > 
> > I don't have any needs, nor do I need your help.
> > 
> > You made the following statement:
> > 
> > "It is because the watchdog timer on LPC is not wired to the Reset
> > interrupt priority level of ARM7"
> > 
> > This contradicts information in the User Manuals, where it is 
stated 
> > that the watchdog generates a reset.
> > 
> > Furthermore, there is no such thing as a "reset interrupt 
priority 
> > level". A reset is a type of exception (as is an IRQ or FIR 
> > interrupt). Resets have a higher priority than interrupts (and 
all 

> > other exceptions, such as data aborts etc.).
> > 
> > See the ARM ARM for details.
> > 
> > All I'm asking is that if you have information to the contrary, 
> > please share it rather than making incorrect statements and vague 
> > claims about problems.
> > 
> > Best wishes
> > Brendan
>

jayasooriah wrote:

> Please refrain from ask me anything if you do not need my help.
> 
> I do not wish to engage with you on this or any other topic.

Honestly Jaya, when you make assertions like:

   It is because the watchdog timer on LPC is not wired to the Reset
   interrupt priority level of ARM7.  Thus the Data Abort exception that
   you are not dismissing locks out watchdog reset.

and then someone asks you to back up the assertion with
evidence from either a manual or specific code that shows the
breakage, they are not asking for your help.

As a scientist, it is simply irresponsible to make a claim and
not be willing to share detailed, reproducible steps that
lead you to your conclusion.

If someone challenges (with detailed, reproducible steps) one
of your conclusions, it must be refuted in a similar way, or
the point must be conceded.

Please respond to the original question, which is to provide
proof that the watchdog timer reset can be "locked out".

I'm not asking for your help on a specific question here, I'm
asking you to help the broader LPC community to determine if the
WDT has a real problem.

Ralph

Thanks, Ralph: very well put. I fear you're wasting your time, 
though...

Brendan

--- In lpc2000@yahoogroups.com, Ralph Hempel <rhempel@...> wrote:
>
> jayasooriah wrote:
> 
> > Please refrain from ask me anything if you do not need my help.
> > 
> > I do not wish to engage with you on this or any other topic.
> 
> Honestly Jaya, when you make assertions like:
> 
>    It is because the watchdog timer on LPC is not wired to the Reset
>    interrupt priority level of ARM7.  Thus the Data Abort exception 
that

>    you are not dismissing locks out watchdog reset.
> 
> and then someone asks you to back up the assertion with
> evidence from either a manual or specific code that shows the
> breakage, they are not asking for your help.
> 
> As a scientist, it is simply irresponsible to make a claim and
> not be willing to share detailed, reproducible steps that
> lead you to your conclusion.
> 
> If someone challenges (with detailed, reproducible steps) one
> of your conclusions, it must be refuted in a similar way, or
> the point must be conceded.
> 
> Please respond to the original question, which is to provide
> proof that the watchdog timer reset can be "locked out".
> 
> I'm not asking for your help on a specific question here, I'm
> asking you to help the broader LPC community to determine if the
> WDT has a real problem.
> 
> Ralph
>

Thank you Brendan.

--- In lpc2000@yahoogroups.com, "brendanmurphy37"
<brendanmurphy37@...> wrote:

> Jaya,
> 
> OK - I'll give up asking you to back your claims, as it doesn't seem 
> to work.
> 
> I don't see an issue though with pointing out some of the factual 
> errors contained in your posts, which is what my last post was mostly 
> about.
> 
> I would (and have) welcomed such corrections to my own posts in the 
> past: it helps prevent inaccurate and misleading information from 
> propagating.
> 
> Best wishes
> Brendan

Dear Ralph,

This kind of argument gets nowhere.

It was not an assertion, but a response to a claim by the poster who
started the thread.  The original claim was that while in Data Abort
exception watchdog timer overflow does not trigger a reset.

If only one did not get bogged down by misinterpreting the definitive
form of expression I use in my *response*, perhaps one would have seen
from further posts I made on the same thread that:

1/  I do not used the watchdog for this purpose;
2/  I have not verified the original claim; and
3/  I do not have the means to verify the claim.

[My explanation was only in the context of the impressive LPC family
errata sheets, past discussions about watchdog timer problems and the
work around proposed by Philips.]

Thus I am deeply sorry that I am unable help you or the broader LPC
community to investigate this matter further at this time

Perhaps someone else can liaise directly with the original poster and
tell us what the findings are.

Kind regards,

Jaya

--- In lpc2000@yahoogroups.com, Ralph Hempel <rhempel@...> wrote:

>
> jayasooriah wrote:
> 
> > Please refrain from ask me anything if you do not need my help.
> > 
> > I do not wish to engage with you on this or any other topic.
> 
> Honestly Jaya, when you make assertions like:
> 
>    It is because the watchdog timer on LPC is not wired to the Reset
>    interrupt priority level of ARM7.  Thus the Data Abort exception that
>    you are not dismissing locks out watchdog reset.
> 
> and then someone asks you to back up the assertion with
> evidence from either a manual or specific code that shows the
> breakage, they are not asking for your help.
> 
> As a scientist, it is simply irresponsible to make a claim and
> not be willing to share detailed, reproducible steps that
> lead you to your conclusion.
> 
> If someone challenges (with detailed, reproducible steps) one
> of your conclusions, it must be refuted in a similar way, or
> the point must be conceded.
> 
> Please respond to the original question, which is to provide
> proof that the watchdog timer reset can be "locked out".
> 
> I'm not asking for your help on a specific question here, I'm
> asking you to help the broader LPC community to determine if the
> WDT has a real problem.
> 
> Ralph

Jaya,

You can deny it all you want. The fact is that in:

http://groups.yahoo.com/group/lpc2000/message/15370

you made the following assertion:

"It is because the watchdog timer on LPC is not wired to the Reset
interrupt priority level of ARM7.  Thus the Data Abort exception that
you are not dismissing locks out watchdog reset."

As I pointed out, this has no factual basis whatsoever. 

All Ralph and I asked you to do was provide some proof to the 
contrary. I've now given up on this, as asking you for evidence for 
your claims gets nowhere. Denying you made them in the first place is 
downright bizarre: the evidence you made the claim is there for all 
to see.

I will agree with one thing you say: "this kind of argument gets 
nowhere".

Brendan.

--- In lpc2000@yahoogroups.com, "jayasooriah" <jayasooriah@...> wrote:
>
> Dear Ralph,
> 
> This kind of argument gets nowhere.
> 
> It was not an assertion, but a response to a claim by the poster who
> started the thread.  The original claim was that while in Data Abort
> exception watchdog timer overflow does not trigger a reset.
> 
> If only one did not get bogged down by misinterpreting the 
definitive
> form of expression I use in my *response*, perhaps one would have 
seen
> from further posts I made on the same thread that:
> 
> 1/  I do not used the watchdog for this purpose;
> 2/  I have not verified the original claim; and
> 3/  I do not have the means to verify the claim.
> 
> [My explanation was only in the context of the impressive LPC family
> errata sheets, past discussions about watchdog timer problems and 
the
> work around proposed by Philips.]
> 
> Thus I am deeply sorry that I am unable help you or the broader LPC
> community to investigate this matter further at this time
> 
> Perhaps someone else can liaise directly with the original poster 
and
> tell us what the findings are.
> 
> Kind regards,
> 
> Jaya
> 
> --- In lpc2000@yahoogroups.com, Ralph Hempel <rhempel@> wrote:
> >
> > jayasooriah wrote:
> > 
> > > Please refrain from ask me anything if you do not need my help.
> > > 
> > > I do not wish to engage with you on this or any other topic.
> > 
> > Honestly Jaya, when you make assertions like:
> > 
> >    It is because the watchdog timer on LPC is not wired to the 
Reset
> >    interrupt priority level of ARM7.  Thus the Data Abort 
exception that

> >    you are not dismissing locks out watchdog reset.
> > 
> > and then someone asks you to back up the assertion with
> > evidence from either a manual or specific code that shows the
> > breakage, they are not asking for your help.
> > 
> > As a scientist, it is simply irresponsible to make a claim and
> > not be willing to share detailed, reproducible steps that
> > lead you to your conclusion.
> > 
> > If someone challenges (with detailed, reproducible steps) one
> > of your conclusions, it must be refuted in a similar way, or
> > the point must be conceded.
> > 
> > Please respond to the original question, which is to provide
> > proof that the watchdog timer reset can be "locked out".
> > 
> > I'm not asking for your help on a specific question here, I'm
> > asking you to help the broader LPC community to determine if the
> > WDT has a real problem.
> > 
> > Ralph
>

No comment.

--- In lpc2000@yahoogroups.com, "brendanmurphy37"
<brendanmurphy37@...> wrote:

>
> 
> Jaya,
> 
> You can deny it all you want. The fact is that in:
> 
> http://groups.yahoo.com/group/lpc2000/message/15370
> 
> you made the following assertion:
> 
> "It is because the watchdog timer on LPC is not wired to the Reset
> interrupt priority level of ARM7.  Thus the Data Abort exception that
> you are not dismissing locks out watchdog reset."
> 
> As I pointed out, this has no factual basis whatsoever. 
> 
> All Ralph and I asked you to do was provide some proof to the 
> contrary. I've now given up on this, as asking you for evidence for 
> your claims gets nowhere. Denying you made them in the first place is 
> downright bizarre: the evidence you made the claim is there for all 
> to see.
> 
> I will agree with one thing you say: "this kind of argument gets 
> nowhere".
> 
> Brendan.

Jaya, 

> No comment.

If you've got no comment, don't comment.  You're just digging yourself a
deeper hole.

--
Paul Curtis, Rowley Associates Ltd   http://www.rowley.co.uk 
CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors

Hi John,

I see you back in support of distractions yet again :)

Have you finished your interrupt example yet?  I am sort of waiting on
your solution to see if I can improve.

Kind regards,

Jaya

PS:  My "No comment" was an attempt to stop this question from being
asked six times.

--- In lpc2000@yahoogroups.com, "Paul Curtis" <plc@...> wrote:

>
> Jaya, 
> 
> > No comment.
> 
> If you've got no comment, don't comment.  You're just digging yourself a
> deeper hole.
> 
> --
> Paul Curtis, Rowley Associates Ltd   http://www.rowley.co.uk 
> CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors
>

Sincere apologies before I get flamed -- I got Paul and John mixed up.

I withraw the statement second sentence unconditionally  - Jaya

--- In lpc2000@yahoogroups.com, "jayasooriah" <jayasooriah@...> wrote:
>
> Hi John,
> 
> I see you back in support of distractions yet again :)
> 
> Have you finished your interrupt example yet?  I am sort of waiting on
> your solution to see if I can improve.
> 
> Kind regards,
> 
> Jaya
> 
> PS:  My "No comment" was an attempt to stop this question from being
> asked six times.
> 
> --- In lpc2000@yahoogroups.com, "Paul Curtis" <plc@> wrote:
> >
> > Jaya, 
> > 
> > > No comment.
> > 
> > If you've got no comment, don't comment.  You're just digging
yourself a

> > deeper hole.
> > 
> > --
> > Paul Curtis, Rowley Associates Ltd   http://www.rowley.co.uk 
> > CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors
> >
>

Jaya,

What question? I didn't ask one. All I pointed out was that information 
you posted was incorrect. As you've no further comment to make, I'm 
assuming you've now accepted this.

Can we please stop, now?

Brendan

--- In lpc2000@yahoogroups.com, "jayasooriah" <jayasooriah@...> wrote:

> PS:  My "No comment" was an attempt to stop this question from being
> asked six times.
>

Jaya,

Keep up the good work!  This thread was amazingly entertaining.

Geoffrey

  ----- Original Message ----- 
  From: jayasooriah 
  To: lpc2000@yahoogroups.com 
  Sent: Tuesday, April 18, 2006 8:03 AM
  Subject: [lpc2000] Re: WDT reset while in an ISR


  Hi John,

  I see you back in support of distractions yet again :)

  Have you finished your interrupt example yet?  I am sort of waiting on
  your solution to see if I can improve.

  Kind regards,

  Jaya

  PS:  My "No comment" was an attempt to stop this question from being
  asked six times.

  --- In lpc2000@yahoogroups.com, "Paul Curtis" <plc@...> wrote:
  >
  > Jaya, 
  > 
  > > No comment.
  > 
  > If you've got no comment, don't comment.  You're just digging yourself a
  > deeper hole.
  > 
  > --
  > Paul Curtis, Rowley Associates Ltd   http://www.rowley.co.uk 
  > CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors
  >





------------------------------------------------------------------------------
  YAHOO! GROUPS LINKS 

    a..  Visit your group "lpc2000" on the web.
      
    b..  To unsubscribe from this group, send an email to:
     lpc2000-unsubscribe@yahoogroups.com
      
    c..  Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. 


------------------------------------------------------------------------------



[Non-text portions of this message have been removed]

--- In lpc2000@yahoogroups.com, "brendanmurphy37"
<brendanmurphy37@...> wrote:

> Can we please stop, now?

How can I when you will not stop asking questions? :)

Well as the original poster I have some more news - the WDT does 
fire off a reset while the code is buried in an IRQ. For yet 
unexplained reasons the WDT that I had working appeared to no longer 
be getting activated. I took the few lines of code involved apart 
put them back together and walla it began working again - but I'm 
suspicious - best I can tell I have the exact same code again and 
now it works. It's like the WDT got jammed up into some mode where I 
couldn't start it (as whacked as that sounds)??

With WDT working again, I proceeded to purposely cause the DATA 
ABORT IRQ where the code gets trapped in an endless loop and indeed 
the WDT RESET does go off to start app over again. So that is the 
good news.

--- In lpc2000@yahoogroups.com, "jayasooriah" <jayasooriah@...> 
wrote:
>
> Hi Andrew,
> 
> --- In lpc2000@yahoogroups.com, "Andrew Berney" <amb@> wrote:
> >
> > By my understanding of the original problem he said he is 
deliberately
> > causing a data abort exception to be raised and while processing 
this
> > exception has created an endless loop.
> 
> Yes you are right in that this is what the original post that 
started
> this thread seemed to suggest.  I responded with what I thought was
> going on based on what I know about the six ARM IPLs.
> 
> > Now by my understanding of the Philips LPC's they are only 
capable of
> > dealing with single IRQ's. I.e. they have no ability to stack 
IRQ's and
> > branch from within a current IRQ to service one that is a higher
> priority
> > automatically (you could always do this yourself inside the IRQ 
if you
> > wanted to I guess).
> 
> I was not aware of this limitation.  Are you sure?  Is this stated
> anywhere?
> 
> > It strikes me that this being the case he will never actually 
fully
> service
> > and clear the original IRQ to allow an update of the CPSR, he'll
> simply sit
> > inside it forever and as such it doesn't really matter how many
> other IRQ's
> > fire as he'll never get back to a state whereby the CPSR reflects
> that he
> > has a new IRQ to do something with - hence his WDT will create a
> reset IRQ
> > which will never get actioned...
> > 
> > Is this not what we're seeing here or did I misunderstand 
something?
> > 
> > I'll have to have a quick play with a device and see if I can 
replicate

> > this.
> 
> I would be interested in what you find out.  I do not have my jig
> handy handy at the moment.
> 
> Jaya
>

--- In lpc2000@yahoogroups.com, "relentless_6995" <bobd@...> wrote:
>
> Well as the original poster I have some more news - the WDT does 
> fire off a reset while the code is buried in an IRQ. For yet 
> unexplained reasons the WDT that I had working appeared to no longer 
> be getting activated. I took the few lines of code involved apart 
> put them back together and walla it began working again - but I'm 
> suspicious - best I can tell I have the exact same code again and 
> now it works. It's like the WDT got jammed up into some mode where I 
> couldn't start it (as whacked as that sounds)??
> 
> With WDT working again, I proceeded to purposely cause the DATA 
> ABORT IRQ where the code gets trapped in an endless loop and indeed 
> the WDT RESET does go off to start app over again. So that is the 
> good news.

Thank you for the update.  Please feel free to keep us informed.

I am looking at (and documenting) at a very similar problem relating
to WD timer not initiating a reset all the time.  It seems to fit your
description.  Which LPC variant are you using?

The problem they were having is that on LPC2294 their WD recovery did
not work reliably.

I asked them to validate the recovery code.  They were able to show
that synchronous jumps to it always worked, but when the jump was
asynchronous the recovery failed 10 percent of the time under certain
conditions.  The symtoms are as if the processor locked up.

As they needed WD only during development stage, I got them to work
around the problem quite easily.

However I am interested in repeating this problem so that someone else
might benefit from more information about this problem that you seem
to have also encountered.

I will post details of this problem and the findings in my "LPC
problems and solutions page" when I find the time to verify a few
details myself.

Regards,

Jaya