Yahoo Groups archive
Thread
2005-06-21 by Steffen Rose
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
2005-06-21 by Stephen Pelc
From: Steffen Rose <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@... 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
2005-06-21 by Ken Wada
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@yahoogroups.com, 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
2005-06-22 by Charles Manning
On Wednesday 22 June 2005 08:59, Stephen Pelc wrote: > From: Steffen Rose <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.
2005-08-10 by big1ogre
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@...] Sent: Tuesday, June 21, 2005 11:02 AM To: lpc2000@yahoogroups.com 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
2005-08-11 by Steffen Rose
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
2005-08-11 by brendanmurphy37
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@yahoogroups.com, 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
2005-08-11 by Jim Parziale
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@...> 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@yahoogroups.com, 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&w5=8085+microprocessor&c=5&s=120&.sig=OPqm0ilH6VyGn-geZ0nNwA> > Microprocessor<http://groups.yahoo.com/gads?t=ms&k=Microprocessor&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&w5=8085+microprocessor&c=5&s=120&.sig=e6n93hF7rArBsrPQJltQ_w> Intel > microprocessors<http://groups.yahoo.com/gads?t=ms&k=Intel+microprocessors&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&w5=8085+microprocessor&c=5&s=120&.sig=EENrTtKaQUw-Vd0BgTdDmw> Pic > microcontrollers<http://groups.yahoo.com/gads?t=ms&k=Pic+microcontrollers&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&w5=8085+microprocessor&c=5&s=120&.sig=iYT6za1gT3-VT1hwIylDpw> 8085 > microprocessor<http://groups.yahoo.com/gads?t=ms&k=8085+microprocessor&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&w5=8085+microprocessor&c=5&s=120&.sig=PhYMBsCkQptYbazQFyNujQ> > ------------------------------ > 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<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/>. > > > ------------------------------ > -- ---------------------------------------------------------- Jim Parziale Email: nuncio.bitis@... Malden, MA ---------------------------------------------------------- [Non-text portions of this message have been removed]
2005-08-11 by DECwiz (Fred van Kempen)
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@...> 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@...> 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@yahoogroups.com, 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&w5=8085+microprocessor&c=5&s=120&.sig=OPqm0ilH6VyGn-geZ0nNwA>
> Microprocessor<http://groups.yahoo.com/gads?t=ms&k=Microprocessor&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&w5=8085+microprocessor&c=5&s=120&.sig=e6n93hF7rArBsrPQJltQ_w> Intel
> microprocessors<http://groups.yahoo.com/gads?t=ms&k=Intel+microprocessors&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&w5=8085+microprocessor&c=5&s=120&.sig=EENrTtKaQUw-Vd0BgTdDmw> Pic
> microcontrollers<http://groups.yahoo.com/gads?t=ms&k=Pic+microcontrollers&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&w5=8085+microprocessor&c=5&s=120&.sig=iYT6za1gT3-VT1hwIylDpw> 8085
> microprocessor<http://groups.yahoo.com/gads?t=ms&k=8085+microprocessor&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&w5=8085+microprocessor&c=5&s=120&.sig=PhYMBsCkQptYbazQFyNujQ>
> ------------------------------
> 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<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/>.
>
>
> ------------------------------
>
--
----------------------------------------------------------
Jim Parziale
Email: nuncio.bitis@...
Malden, MA
----------------------------------------------------------
[Non-text portions of this message have been removed]
---------------------------------
YAHOO! GROUPS LINKS
Visit your group "lpc2000" on the web.
To unsubscribe from this group, send an email to:
lpc2000-unsubscribe@yahoogroups.com
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
---------------------------------
[Non-text portions of this message have been removed]2005-08-11 by Jim Parziale
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@...> 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@... Malden, MA ---------------------------------------------------------- [Non-text portions of this message have been removed]
2005-08-11 by Bill Knight
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@...> 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@...> 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@yahoogroups.com, 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&w5=8085+microprocessor&c=5&s=120&.sig=OPqm0ilH6VyGn-geZ0nNwA> >> Microprocessor<http://groups.yahoo.com/gads?t=ms&k=Microprocessor&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&w5=8085+microprocessor&c=5&s=120&.sig=e6n93hF7rArBsrPQJltQ_w> Intel >> microprocessors<http://groups.yahoo.com/gads?t=ms&k=Intel+microprocessors&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&w5=8085+microprocessor&c=5&s=120&.sig=EENrTtKaQUw-Vd0BgTdDmw> Pic >> microcontrollers<http://groups.yahoo.com/gads?t=ms&k=Pic+microcontrollers&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&w5=8085+microprocessor&c=5&s=120&.sig=iYT6za1gT3-VT1hwIylDpw> 8085 >> microprocessor<http://groups.yahoo.com/gads?t=ms&k=8085+microprocessor&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&w5=8085+microprocessor&c=5&s=120&.sig=PhYMBsCkQptYbazQFyNujQ> >> ------------------------------ >> 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<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/>. >> >> >> ------------------------------ >> >-- >---------------------------------------------------------- >Jim Parziale >Email: nuncio.bitis@... >Malden, MA >---------------------------------------------------------- >[Non-text portions of this message have been removed] >--------------------------------- >YAHOO! GROUPS LINKS > Visit your group "lpc2000" on the web. > > To unsubscribe from this group, send an email to: > lpc2000-unsubscribe@yahoogroups.com > > Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. >--------------------------------- >[Non-text portions of this message have been removed] > >Yahoo! Groups Links >