[ECOS] Zero vector interrupts (SIVEC=0) on MPC8xxx

[ECOS] Zero vector interrupts (SIVEC=0) on MPC8xxx

[Danny Sade]

Hi All,
Did anyone encounter zero vector interrupt (SIVEC = 0) on the MPC8xxx ?  I recently encountered this kind of interrupts, and according to Freescale support and the documentation this kind of interrupt may occur during normal operation and a service routine for this interrupt must be provided.
The thing is that the current HAL implementation, at the macro hal_intc_decode at variant.inc, decodes this interrupt as a decrementer interrupt.  As a result, whenever this zero vector interrupt is asserted the tick ISR is called.  If the there are only few such interrupts, this is hardly noticed.  But obviously, when there are many such interrupts all the time related services (such as cyg_thread_delay() ) cannot not function the way they should.
I'm not sure what is causing these zero vector interrupts.  I can tell that it is related to the IDMA - whenever I have a lot of IDMA transactions, I see a lot of zero vector interrupts.

Any ideas?

Thanks

Danny

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

RE: [ECOS] Zero vector interrupts (SIVEC=0) on MPC8xxx

[Christophe Coutand]

Hi Danny,

Spurious or bad interrupts seem to be a known issue on 8260. what type
of CPU are you using?
http://lists.ozlabs.org/pipermail/linuxppc-dev/2004-January/016316.html
http://ozlabs.org/pipermail/linuxppc-embedded/2004-February/013247.html

Most of the HAL for PowerPC are written with the idea that external
interrupt number 0 is never valid, therefore 0 is allocated to the
decrementer interrupt. This is not true for PowerQuick III. For instance
on MPC8572 interrupt number 0 is related to L2 cache. I think the
easiest way for you is to map the decrementer interrupt
(CYGNUM_HAL_INTERRUPT_DECREMENTER) to something else then 0 and change
your variant.inc to handle it properly until you find the reason for the
spurious interrupts.

Christophe


-----Original Message-----
From: ecos-discuss-owner@ecos.sourceware.org
[mailto:ecos-discuss-owner@ecos.sourceware.org] On Behalf Of Danny Sade
Sent: Tuesday, September 01, 2009 10:21 AM
To: ecos-discuss@ecos.sourceware.org
Subject: [ECOS] Zero vector interrupts (SIVEC=0) on MPC8xxx

Hi All,
Did anyone encounter zero vector interrupt (SIVEC = 0) on the MPC8xxx ?
I recently encountered this kind of interrupts, and according to
Freescale support and the documentation this kind of interrupt may occur
during normal operation and a service routine for this interrupt must be
provided.
The thing is that the current HAL implementation, at the macro
hal_intc_decode at variant.inc, decodes this interrupt as a decrementer
interrupt.  As a result, whenever this zero vector interrupt is asserted
the tick ISR is called.  If the there are only few such interrupts, this
is hardly noticed.  But obviously, when there are many such interrupts
all the time related services (such as cyg_thread_delay() ) cannot not
function the way they should.
I'm not sure what is causing these zero vector interrupts.  I can tell
that it is related to the IDMA - whenever I have a lot of IDMA
transactions, I see a lot of zero vector interrupts.

Any ideas?

Thanks

Danny

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss


--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

RE: [ECOS] Zero vector interrupts (SIVEC=0) on MPC8xxx

[Danny Sade]

Hi Christophe, 

> what type of CPU are you using?

I'm using 8247 (PowerQUICC II)

> I think the easiest way for you is to map the decrementer interrupt
> (CYGNUM_HAL_INTERRUPT_DECREMENTER) to something else then 0 and change your variant.inc to
> handle it properly until you find the reason for the spurious interrupts.

I wasn't aware to this mapping option. For the mean time I've defined the macro cygpkg_plf_intc_handler
in my plf_regs.h, and I'm using this macro to identify this case and map the zero vector interrupt to some
other vector which I don't use.

In any case, as far as I understand, an ISR for this zero vector interrupt should always be provided since these
Interrupts are asserted during normal operation.

Thanks

Danny

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss