With apologies to all for the length of this postÂ….
Jaya,
Many thanks for your response: I think it well worth it to try and
get to the bottom of this.
--- In lpc2000@yahoogroups.com, Jayasooriah <jayasooriah@...> wrote:
>
> Brendan,
>
> Yet again your post contradicts many findings by different people
in this
> forum. Furthermore it is not consistent with explanations in both
AN10414
> and PL190TRM.
I'd be curious to know which parts of the post contradict the many
findings of these different people: can you supply an example,
please?
>
> 1/ The issue you vaguely refer to as "certain conditions does not
provide
> correct vector address" has been explained precisely in AN10414.
What is
> missing or not the underlying cause.
I wasn't being vague, simply summarising in as brief a form as
possible the well-documented issue, that as you point out has
already been explained precisely elsewhere. Try reading it again and
telling me which part is inaccurate or wrong: "Â…in certain
conditions the VIC doesn't provide the correct vector addressÂ…". Why
bother repeating the details?
As for the underlying cause, I'm sure Philips (and ARM, if it's an
ARM issue) are very well aware of the underlying cause. It's of no
interest to me though: all I'm interested in is the observed
behaviour. I'm particularly not interested in speculating on the
underlying cause, attempting to use incomplete information to draw
wild conclusions.
>
> When the VIC raises the interrupt, it determines the source of the
> interrupt and loads this into the call vector. [Quick
experimentation
> suggests it does this correctly.]
>
> However if this interrupt was disabled (in the pipeline) after it
was
> raised, when the ISR reads this call vector, VIC returns the
default vector
> instead.
>
> It does not appear that call vector was corrupted and all
indications are
> that it is still there. It is not clear why the VIC chose not to
return
> the call vector -- I can only guess it was gated with interrupt
enable bit
> as a shortcut.
Can you explain this last statement, please? I'm fascinated.
>
> The solution to avoiding spurious interrupts (and not working
around by the
> default ISR polling all possible interrupt sources as recommended
in
> AN10414) involves determining why the VIC returned the default
vector.
It's not necessary to poll the interrupt sources if you're not
interested in handling the source of the spurious interrupt within
the default interrupt handler. Maybe you should read my post again?
True, it's something of a work around having a spurious interrupt
handler to handle a spurious interrupt, but as I pointed out, one
that's very easy and simple to live with (and as others have pointed
out, good programming practice in any case).
>
> [Note that this has little to do with the ARM7TDMI interface with
VIC as
> this problem is generic to all pipelined architectures.]
You'll have to explain the relevance of this last statement to me.
>
> 2/ According to AN10414 and PL190TMR, your fix that involves
ignoring the
> interrupt, and returning from interrupt by just writing 0xff to
the call
> vector register WILL NOT WORK.
Can you supply some evidence that it won't work, please? I'd love to
hear it.
>
> AN10414 states:
>
> >In this handler, the following should be done:
> >1. Find the source of the interrupt (if there are multiple
interrupt ources).
> >2. Clear the interrupt source (optional as shown in the UART
case).
> >3. Update the VIC by writing to the VIC Vector Address Register.
>
Agreed, this is all certainly true, but only if you want to handle
the source of the interrupt in the default interrupt handler, which
is what the app note is all about. My point is that you don't have
to. If I'm incorrect in this, I'm perfectly willing to admit I'm
wrong (I've been wrong many times before), but I'd like to see some
evidence first, or explanation from a credible source. By "credible"
by the way, I mean Philips or ARM.
> PL190TM states:
>
> >You must use this register as follows:
> >• the ISR reads the VICVectAddr Register when an IRQ interrupt is
generated
> >• at the end of the ISR, the VICVectAddr Register is written to,
to update
> >the priority hardware.
> >
> >Reading from or writing to the register at other times can cause
incorrect
> >operation.
Agreed: all true. If you read my post again you will see that I
explicitly mentioned you have to do this, even in an otherwise empty
interrupt handler. If you don't (read or write to the register that
is) you're on your own.
>
> 3/ The solution outlined in AN10414 IMO creates more problems and
imposes
> additional (difficult) constraints relating to mutual exclusion on
ALL
> ISRs, not just those relating to vectored interrupts.
Agreed: I think I used the term "misguided". The basic solution – to
provide a default interrupt handler – is however quite valid, simple
to implement and easy to prove correct.
>
> [I am in the processing of documenting a solution to the VIC
spurious
> interrupt problem on LPC2294. It is based on PREVENTING, not
HANDLING
> spurious interrupts. There are a issues still outstanding.]
I'd can't wait to see it! I assume you'll post it here?
>
> Based on what I have been working with over the last week, I know
that, if
> you do not appreciate the problem correctly, you are in be in for
a lot of
> surprises when you use the LPC in a system where there are lots of
random
> and and successive interrupts from the one source, for example an
> accelerometer.
Jaya, I can assure you I do appreciate this problem. As I think I
mentioned we actually experienced it before it was documented. The
system we discovered it on has many, many interrupts, from different
sources, at different rates (inclduing randomly), and different
priorities. I won't bore you or anyone else with the details: I find
it somewhat tedious when people describe in great detail how complex
their systems are, assuming they are somehow unique in this respect.
[Text removed here]
> > The issue is that in certain conditions the VIC doesn't provide
the
> > correct vector address (in VICVectAddr) when handling vectored
> > interrupts: it provides the default vector address
(VICDefVectAddr)
> > instead. This is a very rare occurrence. Mentioning this rarity
is
> > not to indicate it can be ignored, but is a warning that you're
> > unlikely to see it in normal testing.
>
> I would not call this a rare occurrence given the number of people
in this
> forum who raised spurious interrupt problems resulting in Philips
releasing
> an application note early this year.
I meant rare in the sense it doesn't happen very often on a
particular system, not that it has been rarely observed by different
people.
>
> > Whether this issue is specific
> > to the Philips parts, or is a general ARM issue (both core and
VIC
> > are ARM designs) is a moot point: the behaviour exists.
>
> It is not a moot point for those who cannot tolerate spurious
interrupts.
> They wish to know if VIC generates spurious interrupts in other
ARM7TDMI
> variants as claimed in AN10414.
We'll just have to disagree on this one: all I can say is that it's
a moot point for me, and I suspect most other people. To use an
analogy: if there's a problem with your Ford, and they blame a
component manufacturer, it might be of interest to you if you choose
your cars based on the behaviour of individual components, but it's
pretty academic to most people: they just want a car that works.
>
> [This is the my reason for looking into this problem.]
>
> > The problem is that the default initialisation of the
VICDefVectAddr
> > is zero. Hence, if this condition happens, the default
behaviour is
> > for the processor to jump to zero. On some systems this is
> > completely benign; on others it could be catastrophic.
> >
> > The fix is simple, and as already been pointed out, good
programming
> > practice in any case: you need to supply a default interrupt
handler
> > even if strictly speaking your system doesn't otherwise need
one.
>
> See above why this simple solution is not a solution.
Again, maybe I'm slow, but can you explain why it isn't?
>
> > This is the one we use:
> >
> > void default_interrupt_handler(void)
> > {
> > return;
> > }
> >
> > The VIC needs to be initialised with something like:
> >
> > VICDefVectAddr = (unsigned int) default_interrupt_handler;
> >
> > That's about it.
>
> When spurious interrupts are involved, ignorance is no bliss.
It's not ignoring the interrupt: just not handling it in the default
interrupt handler. As I explained, it will be handled later, as the
peripheral causing it will still be asserting it.
[More text removed here]
> If you ignore the interrupts as you propose, you will lose
interrupts for
> sure. Not only that, you could end up in live-lock situation.
>
Can you explain this live-lock situation and how it might arise?
[More text removed here]
> > As a note to Jaya: your concern over the UART CTI interrupt
> > being "ill conditioned" or "not latched" is misplaced. The
statement
> > in the app note about a character being received clearing the
CTI
> > interrupt is simply restating the UART description of the UART
> > Interrupt Identification Register (IIR): it will always happen,
> > regardless of whether or not there's a spurious interrupt (or
even a
> > VIC for that matter). There's no suggestion that the interrupt
isn't
> > latched and remain so until the IIR is read. My own previous
> > reference to this as "overwriting" may have been clumsy or
> > imprecise, but hardly "silly". You are of course entitled to
your
> > opinion.
>
> AN10414 very clearly states:
>
> >Now lets consider that a CTI interrupt took place and the VIC
reported
> >this event to the core. The core latched the IRQ state. So now
the core
> >would be in step3 (Section 2.1). Lets assume that at this very
moment a
> >character is received by the UART FIFO. This would clear the CTI
interrupt
> >thereby causing a spurious interrupt.
Correct! and all entirely consistent. As the UART description makes
clear, receiving a character (activity in the FIFO) will clear the
CTI interrupt. As the app note makes clear, changing the status
during this critical period causes the spurious interrupt. I suggest
you work through the details of how back-to-back CTI and received
character interrupts are handled (with and without a VIC, with and
without spurious interrupts) and all should become clear. Don't
forget not to confuse acknowledging interrupts in the peripheral and
acknowledging them in the VIC.
With best wishes.
Brendan