Lpc2000

Karl,

Thanks for this: I was worried I'd been misreading the manual in 
someway, or missing something.

We don't turn interrupts off to feed the watchdog, as both 
conditions (short interrupts and not touching the watchdog registers 
in any interrupt handler) are both met. Our watchdog time is 1 
second, by the way: if an interrupt ran for this length of time, I 
think it would deserve to be kicked!

I'd also agree on the interrupt points: provided you're careful with 
your interrupt dispatch code (which can be quite simple if you stick 
to supervisor, IRQ and FIQ modes as you suggest), you shouldn't have 
problems. Pipelining, as you also suggest, is pretty much 
transparent to almost all code.

As an aside, it's probably worth looking at the original ARM 
documentation if you need to look at CPU registers/interrupts in 
detail: it's much more comprehensive that that provided by Philips 
on the topic.

Brendan

--- In lpc2000@yahoogroups.com, "Karl Olsen" <kro@p...> wrote:
>
> ---- Original Message ----
> From: "Ken Wada" <kwada@a...>
> To: <lpc2000@yahoogroups.com>
> Sent: Friday, December 09, 2005 9:02 PM
> Subject: [lpc2000] Re: Problem with watchdog
> 
> > --- In lpc2000@yahoogroups.com, "brendanmurphy37" 
<brendan.murphy@i...
> >> wrote:
> >>
> >> 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!
> 
> Not according to the LPC214x manual.  The second feed cycle write 
does not
> need to be the very next processor cycle, just the next access to 
the
> watchdog register space, which is 0xE000 0000 - 0xE000 3FFF.  So 
you can
> write 0xAA to WDFEED, handle an interrupt that does lots of things 
(provided
> it doesn't access any watchdog registers, or take too long), and 
back in the
> main program write 0x55 to WDFEED.  If you write 0xAA to WDFEED, 
and then
> write something other than 0x55 to WDFEED, or access another 
watchdog
> register, then you have a feed error which gives an immediate 
reset.
> 
> 
> >> 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.
> 
> The manual mentions two unrelated kinds of spurious interrupts.  
One where a
> peripheral asserts an interrupt source but deasserts it again when 
the
> program has entered the IRQ handler and asks the VIC about the 
interrupt
> source, and one where an IRQ occurs during an MSR instruction that 
disables
> both IRQ and FIQ.  In the latter case, FIQs are disabled during 
the whole
> IRQ handler, and this might be inacceptably long since the 
foreground
> program only expected FIQs to be disabled for a few cycles before 
reenabling
> them.  Can be solved by disabling IRQs and FIQs separately.
> 
> 
> > 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.
> 
> In the ARM7TDMI without memory protection, there is little reason 
to use
> other modes than System, IRQ, and FIQ.  Disabling all interrupts 
is just a
> matter of
> 
>   msr cpsr_c, #0xDF    /* Set System mode, IRQ and FIQ disabled */
> 
> or, if it is a problem that FIQs can be disabled for the duration 
of the IRQ
> handler:
> 
>   msr cpsr_c, #0x9F    /* Set System mode, IRQ disabled */
>   msr cpsr_c, #0xDF    /* Set System mode, IRQ and FIQ disabled */
> 
> And enabling them:
> 
>   msr cpsr_c, #0x1F    /* Set System mode, IRQ and FIQ enabled */
> 
> Other than this specific case, the pipelining itself is very 
invisible to
> programs.  The PC appears to be 8 ahead of the current instruction 
if you
> read the PC register, and when returning from a FIQ or IRQ 
handler, you must
> subtract 4 from the LR.
> 
> 
> > 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.
> 
> SWI can be useful in Thumb mode because it only takes two bytes 
vs. four
> bytes for a BL, and it can be a win when a function is called from 
many
> places.  It isn't necessary for doing critical sections.
> 
> Karl Olsen
>