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
>
VIC on LPC2129
Started by ●June 21, 2005
