It depends on the capabilities of the interrupt controller. Maybe you have to drop the support for nested interrupts. The bsp_interrupt_dispatch() function for a state of the art interrupt controller looks like this (arm-gic-irq.c):

void bsp_interrupt_dispatch(void)
{
  volatile gic_cpuif *cpuif = GIC_CPUIF;
  uint32_t icciar = cpuif->icciar;
  rtems_vector_number vector = GIC_CPUIF_ICCIAR_ACKINTID_GET(icciar);
  rtems_vector_number spurious = 1023;

  if (vector != spurious) {
    uint32_t psr = _ARMV4_Status_irq_enable();

    bsp_interrupt_handler_dispatch(vector);

    _ARMV4_Status_restore(psr);

    cpuif->icceoir = icciar;
  }
}

On 28/05/15 13:50, ragu nath wrote:
Hi Sebastian,

The problem is with rx interrupt. We are enabling rx interrupt before
it is processed. The rtems server task do not get an opportunity to
run.

I found this might be the logical explanation of the issue.
bsp_interrupt_dispatch() calls bsp_interrupt_server_trigger which
disables the rx interrupt and creates BSP_INTERRUPT_EVENT .  For this
event, bsp_interrupt_server_task() was supposed to call the actual
interrupt handler and then enable the rx interrupt. But before the
event is processed, we enable the rx interrupt in dispatch function.
So again rx interrupt is generated and event is created and the cycle
goes on. Server task is never executed in turn actual interrupt
handler is never executed.

Since we enable the interrupt, it occurs again and again as we never handle it.

Is there any other possibility that I might need to look into?


Thanks,
Ragunath

On Thu, May 28, 2015 at 4:58 PM, Sebastian Huber
<sebastian.hu...@embedded-brains.de> wrote:
Hello,

the bsp_interrupt_dispatch() is quite complicated in the beagle BSP. Is the
interrupt controller of this chip really that broken? Sane interrupt
controllers block interrupts of equal or lower priority relative to the
currently pending interrupt.

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Reply via email to