Lpc2000

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



>