Lpc2000

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
>