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
Started by ●June 21, 2005
Reply by ●June 21, 20052005-06-21
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
> 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
Reply by ●June 21, 20052005-06-21
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
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
Reply by ●June 22, 20052005-06-22
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.
> 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.
Reply by ●August 10, 20052005-08-10
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
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
Reply by ●August 11, 20052005-08-11
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
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
Reply by ●August 11, 20052005-08-11
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
Reply by ●August 11, 20052005-08-11
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
----------------------
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
----------------------
Reply by ●August 11, 20052005-08-11
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 ---------------------------------
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 ---------------------------------
Reply by ●August 11, 20052005-08-11
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
----------------------
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
----------------------
