Lpc2000

I personally use

void dummy(void){}

for ALL unused vectors.


brendanmurphy37 wrote:

>
> There's been a degree of noise recently on the issue of spurious
> interrupts, the importance of which has been blown out of all
> proportion. Various claims have been thrown into the mix, which
> might lead one to believe that there's some sort of serious,
> undocumented and underlying flaw in the LPC2000. It's my belief,
> based on the information available and direct experience of the
> issue, that (1) there is an issue with spurious interrupts; (2) it
> can be a problem; and (3), the fix is simple.
>
> 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. 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.
>
> 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.
>
> 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. One final minor point is that the above assumes
> that the assembler code that dispatches the `C' interrupt handler,
> and to which it returns, writes to VICVectAddr after the function
> returns. If not, you'll need to add something like the following to
> the interrupt handler:
>
> VICVectAddr = 0xff;
>
> The only disadvantages that I can see to this whole issue is that
> (1) you have to be aware of it (2) you have to provide a fix (which
> can be very simple though) and (3) there is an overhead in handling
> the spurious interrupt (it happens so rarely though this can be
> discounted).
>
> All of this is well documented, by the way.
>
> There's no case where interrupts are lost or the system will get
> locked or fail in some mysterious way. If anyone (including and
> especially Philips)  has information or hard evidence to the
> contrary, I'd be very interested to hear it, as I'm sure others
> would.
>
> Further information for those interested:
>
> There is an app note from Philips that shows how you can handle the
> source of the interrupt in your default interrupt handler. You can
> obviously do this, although you are faced with the issue of
> identifying the source. To my mind this approach is somewhat
> misguided: it's unnecessarily complex, and it will be difficult to
> test (due to the very sporadic nature of the problem arising). I
> think it's better to just do nothing in the default handler: the
> peripheral's interrupt will remain asserted and the correct vectored
> interrupt will be entered subsequently (maybe not immediately if a
> higher priority interrupt has happened in the meantime).
>
> 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.
>
> Brendan
>
>
>
>
>
>
>
>
> SPONSORED LINKS
> Microcontrollers 
> <http://groups.yahoo.com/gads?t=ms&k=Microcontrollers&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s=95&.sig=mfaAujKZXA2Z_vxre9sGnQ> 
> 	Microprocessor 
> <http://groups.yahoo.com/gads?t=ms&k=Microprocessor&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s=95&.sig=9jjd2D3GOLIESVQssLmLsA> 
> 	Intel microprocessors 
> <http://groups.yahoo.com/gads?t=ms&k=Intel+microprocessors&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s=95&.sig=OMnZuqMZX95mgutt4B-tDw> 
>
> Pic microcontrollers 
> <http://groups.yahoo.com/gads?t=ms&k=Pic+microcontrollers&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s=95&.sig=Malspbd0T4Rq3M4Q0nHrfw> 
>
>
>
> ------------------------------------------------------------------------
> YAHOO! GROUPS LINKS
>
>     *  Visit your group "lpc2000
>       <http://groups.yahoo.com/group/lpc2000>" on the web.
>        
>     *  To unsubscribe from this group, send an email to:
>        lpc2000-unsubscribe@yahoogroups.com
>       <mailto:lpc2000-unsubscribe@yahoogroups.com?subject=Unsubscribe>
>        
>     *  Your use of Yahoo! Groups is subject to the Yahoo! Terms of
>       Service <http://docs.yahoo.com/info/terms/>.
>
>
> ------------------------------------------------------------------------
>


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