Sign in

Not a member? | Forgot your Password?

Search lpc2000

Search tips

Subscribe to lpc2000

Free PDF Downloads

An Engineer's Guide to the LPC2100 Series

Advanced Linux Programming

What Every Programmer Should Know About Memory

Introduction to Embedded Systems

C++ Tutorial

Embedded Systems - Theory and Design Methodology

Microcontroller Programming and Interfacing

Introduction to Microcontrollers


More Free PDF Downloads

Discussion Groups

See Also

ElectronicsDSPFPGA

Find us on Facebook





Discussion Groups | LPC2000 | VIC on LPC2129

Discussion group dedicated to the Philips LPC2000 family of ARM MCUs

VIC on LPC2129 - Steffen Rose - Jun 21 12:02:00 2005

Hello,

where can I find more information about the
Vectored Interrupt Controller, especially about the SPURIOUS
INTERRUPTS?

In my system are many interrupts enabled and my system resets
from time to time. My idea is the occurrence of this SPURIOUS
INTERRUPTS.

Is there a symptom, that I can confirm this?

OT: Is there a german expert?
Thank you
--
Steffen Rose





Re: VIC on LPC2129 - Ken Wada - Jun 21 17:08:00 2005

Go here:
http://www.arm.com:8765/cs.html?url=http%3A//www.arm.
com/pdfs/DDI0181E_vic_pl190_r1p2_trm.pdf&qt=vic&col=armcom&n=1

This site has complete specs on the ARM VIC.

Ken Wada

--- In lpc2000@lpc2..., Steffen Rose <ro@p...> wrote:
> Hello,
>
> where can I find more information about the
> Vectored Interrupt Controller, especially about the SPURIOUS
> INTERRUPTS?
>
> In my system are many interrupts enabled and my system resets
> from time to time. My idea is the occurrence of this SPURIOUS
> INTERRUPTS.
>
> Is there a symptom, that I can confirm this?
>
> OT: Is there a german expert?
> Thank you
> --
> Steffen Rose




VIC on LPC2129 - Stephen Pelc - Jun 21 16:59:00 2005

From: Steffen Rose <ro@ro@....>

> where can I find more information about the Vectored
> Interrupt Controller, especially about the SPURIOUS
> INTERRUPTS?

> In my system are many interrupts enabled and my system resets
> from time to time. My idea is the occurrence of this SPURIOUS
> INTERRUPTS.

The VIC is a PL190 macrocell from the standard ARM set. The full
documentation is available (and seemingly correct) at:
www.arm.com

It is certainly available on the Tech Ref. CD (well worth while)
which is available free of charge from the ARM web site.

Stephen
--
Stephen Pelc, stephen@step...
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 23 80 631441, fax: +44 23 80 339691
web: http://www.mpeltd.demon.co.uk - free VFX Forth downloads




_____________________________
 Free pdf download: An Engineer's Guide to the LPC2100 Series.


Re: VIC on LPC2129 --> spurious interrupts - Charles Manning - Jun 21 23:02:00 2005

On Wednesday 22 June 2005 08:59, Stephen Pelc wrote:
> From: Steffen Rose <ro@ro@....>
>
> > where can I find more information about the Vectored
> > Interrupt Controller, especially about the SPURIOUS
> > INTERRUPTS?
> >
> > In my system are many interrupts enabled and my system resets
> > from time to time. My idea is the occurrence of this SPURIOUS
> > INTERRUPTS.

Spurious interrupts have been discussed a few times before. I suggest
searching the archives.

Basically they occur when an interrupt happens, but no handler was set up to
handle it.

Two typical causes:
1) Fiddling with the VIC while interrupts are enabled. Disable interrupts at
the ARM code level (ie in the CPSR) while fiddling with the VIC.
2) Erroneous VIC set up.




Re: VIC on LPC2129 - big1ogre - Aug 10 15:09:00 2005

Hi, Steffen,

I have similar problems, using vectored interrupts from UART0, UART1,
I2C and SPI0. It appears that you occasionally get vectored to the
default IRQ handler address. The default is 0x00000000,
(VICDefVectAddr) which equals the reset vector. I will look as the CPU
is resetting. If you implement a default ISR and point VICDefVectAddr
to the routine, you'll find that it is being called from time to
time.
The idea is to look at VICIRQStatus to see which peripheral caused the
interrupt, but in my case, it is always zero. I have done some logic
analyzer checks, and it appears that the default ISR is called only
when an ISR is executing and a new IRQ is asserted. If I find out
more, I'll post it.

Lars

--------------
------------------------------

From: Steffen Rose [mailto:ro@ro@....]
Sent: Tuesday, June 21, 2005 11:02 AM
To: lpc2000@lpc2...
Subject: [lpc2000] VIC on LPC2129
Hello,

where can I find more information about the
Vectored Interrupt Controller, especially about the SPURIOUS
INTERRUPTS?

In my system are many interrupts enabled and my system resets
from time to time. My idea is the occurrence of this SPURIOUS
INTERRUPTS.

Is there a symptom, that I can confirm this?

OT: Is there a german expert?
Thank you
--
Steffen Rose




Re: VIC on LPC2129 - Steffen Rose - Aug 11 2:58:00 2005

Hi,

On Wednesday 10 August 2005 20:40, you wrote:
> I have similar problems, using vectored interrupts from UART0,
> UART1, I2C and SPI0. It appears that you occasionally get
> vectored to the default IRQ handler address. The default is
> 0x00000000, (VICDefVectAddr) which equals the reset vector. I
> will look as the CPU is resetting. If you implement a default
> ISR and point VICDefVectAddr to the routine, you’ll find that
> it is being called from time to time. The idea is to look at
> VICIRQStatus to see which peripheral caused the interrupt, but
> in my case, it is always zero. I have done some logic analyzer
> checks, and it appears that the default ISR is called only
> when an ISR is executing and a new IRQ is asserted. If I fond
> out more, I’ll post it.

In our case the solution was, that a second interrupt was
triggered at the time we was within an interrupt routine.
Now we added a empty default interrupt. Nothing more. The second
interrupt will called after returning from the first interrupt
routine. >> In my system are many interrupts enabled and my system resets
>> from time to time. My idea is the occurrence of this SPURIOUS
>> INTERRUPTS.

--
Steffen Rose




_____________________________
 Free pdf download: An Engineer's Guide to the LPC2100 Series.


Re: VIC on LPC2129 - brendanmurphy37 - Aug 11 5:32:00 2005


We had the same problem when we stressed the part with lots of
interrupts: to be safe you definitely do need a default interrupt
handler. It can be completely empty: just return. Everything works
just fine if you do this. However, if you don't, the default value of
zero in the default interrupt location in the VIC will cause periodic
jumps to zero.

I can't recall the exact part we had this problem on, but my guess is
that it's probably more than one, and the problem occurs regardess of
the type of interrupt (we were using timer, UART0 and UART1 at the
time the problem manifested itself).

Brendan

--- In lpc2000@lpc2..., Steffen Rose <ro@p...> wrote:
> Hi,
>
> On Wednesday 10 August 2005 20:40, you wrote:
> > I have similar problems, using vectored interrupts from UART0,
> > UART1, I2C and SPI0. It appears that you occasionally get
> > vectored to the default IRQ handler address. The default is
> > 0x00000000, (VICDefVectAddr) which equals the reset vector. I
> > will look as the CPU is resetting. If you implement a default
> > ISR and point VICDefVectAddr to the routine, you’ll find that
> > it is being called from time to time. The idea is to look at
> > VICIRQStatus to see which peripheral caused the interrupt, but
> > in my case, it is always zero. I have done some logic analyzer
> > checks, and it appears that the default ISR is called only
> > when an ISR is executing and a new IRQ is asserted. If I fond
> > out more, I’ll post it.
>
> In our case the solution was, that a second interrupt was
> triggered at the time we was within an interrupt routine.
> Now we added a empty default interrupt. Nothing more. The second
> interrupt will called after returning from the first interrupt
> routine. > >> In my system are many interrupts enabled and my system resets
> >> from time to time. My idea is the occurrence of this SPURIOUS
> >> INTERRUPTS.
>
> --
> Steffen Rose




Re: VIC on LPC2129 - Jim Parziale - Aug 11 7:33:00 2005

But would the problem occur with FIQ interrupts as well as IRQ? In other
words, it's really a "problem" with the VIC?
I agree though - you really *do* need to set up a default VIC handler. I'll
bet that's what it's there for...

Jim

On 8/11/05, brendanmurphy37 <brendan.murphy@bren...> wrote:
>
>
> We had the same problem when we stressed the part with lots of
> interrupts: to be safe you definitely do need a default interrupt
> handler. It can be completely empty: just return. Everything works
> just fine if you do this. However, if you don't, the default value of
> zero in the default interrupt location in the VIC will cause periodic
> jumps to zero.
>
> I can't recall the exact part we had this problem on, but my guess is
> that it's probably more than one, and the problem occurs regardess of
> the type of interrupt (we were using timer, UART0 and UART1 at the
> time the problem manifested itself).
>
> Brendan
>
> --- In lpc2000@lpc2..., Steffen Rose <ro@p...> wrote:
> > Hi,
> >
> > On Wednesday 10 August 2005 20:40, you wrote:
> > > I have similar problems, using vectored interrupts from UART0,
> > > UART1, I2C and SPI0. It appears that you occasionally get
> > > vectored to the default IRQ handler address. The default is
> > > 0x00000000, (VICDefVectAddr) which equals the reset vector. I
> > > will look as the CPU is resetting. If you implement a default
> > > ISR and point VICDefVectAddr to the routine, you'll find that
> > > it is being called from time to time. The idea is to look at
> > > VICIRQStatus to see which peripheral caused the interrupt, but
> > > in my case, it is always zero. I have done some logic analyzer
> > > checks, and it appears that the default ISR is called only
> > > when an ISR is executing and a new IRQ is asserted. If I fond
> > > out more, I'll post it.
> >
> > In our case the solution was, that a second interrupt was
> > triggered at the time we was within an interrupt routine.
> > Now we added a empty default interrupt. Nothing more. The second
> > interrupt will called after returning from the first interrupt
> > routine.
> >
> >
> > >> In my system are many interrupts enabled and my system resets
> > >> from time to time. My idea is the occurrence of this SPURIOUS
> > >> INTERRUPTS.
> >
> > --
> > Steffen Rose >
>
> SPONSORED LINKS
> Microcontrollers<http://groups.yahoo.com/gads?t=ms&k=Microcontrollers&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&w585+microprocessor&c=5&s0&.sig=OPqm0ilH6VyGn-geZ0nNwA>
> Microprocessor<http://groups.yahoo.com/gads?t=ms&k=Microprocessor&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&w585+microprocessor&c=5&s0&.sig93hF7rArBsrPQJltQ_w> Intel
> microprocessors<http://groups.yahoo.com/gads?t=ms&k=Intel+microprocessors&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&w585+microprocessor&c=5&s0&.sigrTtKaQUw-Vd0BgTdDmw> Pic
> microcontrollers<http://groups.yahoo.com/gads?t=ms&k=Pic+microcontrollers&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&w585+microprocessor&c=5&s0&.sig=iYT6za1gT3-VT1hwIylDpw> 8085
> microprocessor<http://groups.yahoo.com/gads?t=ms&k85+microprocessor&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&w585+microprocessor&c=5&s0&.sig=PhYMBsCkQptYbazQFyNujQ>
> ------------------------------
> >. > ------------------------------
>
--
----------------------
Jim Parziale
Email: nuncio.bitis@nunc...
Malden, MA
----------------------




Re: VIC on LPC2129 - DECwiz \Fred van Kempen\ - Aug 11 7:42:00 2005

FIQ's dont use the vectoring system, they jump right into the
handler, so most likely won't have this issue. And yes, it is
possible for the VIC to loose track, and just issue a null
vector, I've seen it happen on 2294's as well, under extreme
load.

--fred

Jim Parziale <nuncio.bitis@nunc...> wrote:
But would the problem occur with FIQ interrupts as well as IRQ? In other
words, it's really a "problem" with the VIC?
I agree though - you really *do* need to set up a default VIC handler. I'll
bet that's what it's there for...

Jim

On 8/11/05, brendanmurphy37 <brendan.murphy@bren...> wrote:
>
>
> We had the same problem when we stressed the part with lots of
> interrupts: to be safe you definitely do need a default interrupt
> handler. It can be completely empty: just return. Everything works
> just fine if you do this. However, if you don't, the default value of
> zero in the default interrupt location in the VIC will cause periodic
> jumps to zero.
>
> I can't recall the exact part we had this problem on, but my guess is
> that it's probably more than one, and the problem occurs regardess of
> the type of interrupt (we were using timer, UART0 and UART1 at the
> time the problem manifested itself).
>
> Brendan
>
> --- In lpc2000@lpc2..., Steffen Rose <ro@p...> wrote:
> > Hi,
> >
> > On Wednesday 10 August 2005 20:40, you wrote:
> > > I have similar problems, using vectored interrupts from UART0,
> > > UART1, I2C and SPI0. It appears that you occasionally get
> > > vectored to the default IRQ handler address. The default is
> > > 0x00000000, (VICDefVectAddr) which equals the reset vector. I
> > > will look as the CPU is resetting. If you implement a default
> > > ISR and point VICDefVectAddr to the routine, you'll find that
> > > it is being called from time to time. The idea is to look at
> > > VICIRQStatus to see which peripheral caused the interrupt, but
> > > in my case, it is always zero. I have done some logic analyzer
> > > checks, and it appears that the default ISR is called only
> > > when an ISR is executing and a new IRQ is asserted. If I fond
> > > out more, I'll post it.
> >
> > In our case the solution was, that a second interrupt was
> > triggered at the time we was within an interrupt routine.
> > Now we added a empty default interrupt. Nothing more. The second
> > interrupt will called after returning from the first interrupt
> > routine.
> >
> >
> > >> In my system are many interrupts enabled and my system resets
> > >> from time to time. My idea is the occurrence of this SPURIOUS
> > >> INTERRUPTS.
> >
> > --
> > Steffen Rose >
>
> SPONSORED LINKS
> Microcontrollers<http://groups.yahoo.com/gads?t=ms&k=Microcontrollers&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&w585+microprocessor&c=5&s0&.sig=OPqm0ilH6VyGn-geZ0nNwA>
> Microprocessor<http://groups.yahoo.com/gads?t=ms&k=Microprocessor&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&w585+microprocessor&c=5&s0&.sig93hF7rArBsrPQJltQ_w> Intel
> microprocessors<http://groups.yahoo.com/gads?t=ms&k=Intel+microprocessors&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&w585+microprocessor&c=5&s0&.sigrTtKaQUw-Vd0BgTdDmw> Pic
> microcontrollers<http://groups.yahoo.com/gads?t=ms&k=Pic+microcontrollers&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&w585+microprocessor&c=5&s0&.sig=iYT6za1gT3-VT1hwIylDpw> 8085
> microprocessor<http://groups.yahoo.com/gads?t=ms&k85+microprocessor&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&w585+microprocessor&c=5&s0&.sig=PhYMBsCkQptYbazQFyNujQ>
> ------------------------------
> >. > ------------------------------
>
--
----------------------
Jim Parziale
Email: nuncio.bitis@nunc...
Malden, MA
----------------------
---------------------------------
YAHOO! GROUPS LINKS ---------------------------------





Re: VIC on LPC2129 - Jim Parziale - Aug 11 7:48:00 2005

Well, I meant if you set up for FIQs to be handled by the VIC... it probably
would have the same problems.

On 8/11/05, DECwiz (Fred van Kempen) <decwiz@decw...> wrote:
>
> FIQ's dont use the vectoring system, they jump right into the
> handler, so most likely won't have this issue. And yes, it is
> possible for the VIC to loose track, and just issue a null
> vector, I've seen it happen on 2294's as well, under extreme
> load.
>
> --fred
--
----------------------
Jim Parziale
Email: nuncio.bitis@nunc...
Malden, MA
----------------------




Re: VIC on LPC2129 - Bill Knight - Aug 11 7:59:00 2005

The problem described is most likely not caused specifically by the VIC.
It is probably caused because the code is disabling the specific
interrupt while global interrupts are still enabled. If an interrupt
happens just as the instruction that disables the interrupt in the VIC is
executing, the processor will see the interrupt as enabled. However, by
the time the interrut cycle is allowed to execute at the end of the instruction
cycle the interrupt is no longer enabled in the VIC, hence the spurious
interrupt vector is used. A fix for this is to temporarily disable global
interrupts, disable the specific interrupt, then restore global interrupts
to their previous state.

Regards
-Bill Knight
R O SoftWare &
http://www.theARMPatch.com On Thu, 11 Aug 2005 04:42:37 -0700 (PDT), DECwiz (Fred van Kempen) wrote:

>FIQ's dont use the vectoring system, they jump right into the
>handler, so most likely won't have this issue. And yes, it is
>possible for the VIC to loose track, and just issue a null
>vector, I've seen it happen on 2294's as well, under extreme
>load.
>
>--fred

>Jim Parziale <nuncio.bitis@nunc...> wrote:
>But would the problem occur with FIQ interrupts as well as IRQ? In other
>words, it's really a "problem" with the VIC?
>I agree though - you really *do* need to set up a default VIC handler. I'll
>bet that's what it's there for...

>Jim

>On 8/11/05, brendanmurphy37 <brendan.murphy@bren...> wrote:
>>
>>
>> We had the same problem when we stressed the part with lots of
>> interrupts: to be safe you definitely do need a default interrupt
>> handler. It can be completely empty: just return. Everything works
>> just fine if you do this. However, if you don't, the default value of
>> zero in the default interrupt location in the VIC will cause periodic
>> jumps to zero.
>>
>> I can't recall the exact part we had this problem on, but my guess is
>> that it's probably more than one, and the problem occurs regardess of
>> the type of interrupt (we were using timer, UART0 and UART1 at the
>> time the problem manifested itself).
>>
>> Brendan
>>
>> --- In lpc2000@lpc2..., Steffen Rose <ro@p...> wrote:
>> > Hi,
>> >
>> > On Wednesday 10 August 2005 20:40, you wrote:
>> > > I have similar problems, using vectored interrupts from UART0,
>> > > UART1, I2C and SPI0. It appears that you occasionally get
>> > > vectored to the default IRQ handler address. The default is
>> > > 0x00000000, (VICDefVectAddr) which equals the reset vector. I
>> > > will look as the CPU is resetting. If you implement a default
>> > > ISR and point VICDefVectAddr to the routine, you'll find that
>> > > it is being called from time to time. The idea is to look at
>> > > VICIRQStatus to see which peripheral caused the interrupt, but
>> > > in my case, it is always zero. I have done some logic analyzer
>> > > checks, and it appears that the default ISR is called only
>> > > when an ISR is executing and a new IRQ is asserted. If I fond
>> > > out more, I'll post it.
>> >
>> > In our case the solution was, that a second interrupt was
>> > triggered at the time we was within an interrupt routine.
>> > Now we added a empty default interrupt. Nothing more. The second
>> > interrupt will called after returning from the first interrupt
>> > routine.
>> >
>> >
>> > >> In my system are many interrupts enabled and my system resets
>> > >> from time to time. My idea is the occurrence of this SPURIOUS
>> > >> INTERRUPTS.
>> >
>> > --
>> > Steffen Rose
>>
>>
>>
>>
>> SPONSORED LINKS
>> Microcontrollers<http://groups.yahoo.com/gads?t=ms&k=Microcontrollers&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&w585+microprocessor&c=5&s0&.sig=OPqm0ilH6VyGn-geZ0nNwA>
>> Microprocessor<http://groups.yahoo.com/gads?t=ms&k=Microprocessor&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&w585+microprocessor&c=5&s0&.sig93hF7rArBsrPQJltQ_w> Intel
>> microprocessors<http://groups.yahoo.com/gads?t=ms&k=Intel+microprocessors&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&w585+microprocessor&c=5&s0&.sigrTtKaQUw-Vd0BgTdDmw> Pic
>> microcontrollers<http://groups.yahoo.com/gads?t=ms&k=Pic+microcontrollers&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&w585+microprocessor&c=5&s0&.sig=iYT6za1gT3-VT1hwIylDpw> 8085
>> microprocessor<http://groups.yahoo.com/gads?t=ms&k85+microprocessor&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&w585+microprocessor&c=5&s0&.sig=PhYMBsCkQptYbazQFyNujQ>
>> ------------------------------
>> >.
>>
>>
>> ------------------------------
>>
>--
>----------------------
>Jim Parziale
>Email: nuncio.bitis@nunc...
>Malden, MA
>----------------------


>
>---------------------------------
>YAHOO! GROUPS LINKS


>


>---------------------------------

>

>
>Yahoo! Groups Links
>