Lpc2000

---- Original Message ----
From: "Ken Wada" <kwada@...>
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