This interrupt server task is a hack. It works for proper interrupt
controllers. You must be able to disable a single interrupt source in
the interrupt controller.
On 28/05/15 14:23, Isaac Gutekunst wrote:
I'm going to chime in since this sounds like a similar problem I've
experienced on a PIC32.
I wanted to reword what Ragunath said in my own words to see if I
understand it.
1) The RX ISR fires, vectoring the code to the ISR entry.
2) The code in the ISR disables interrupts, creates an event to be
handled by RTEMS (in a non interrupt context)
3) At some point (dispatch function), interrupts are enabled
4) Since the RTEMS task responsible for performing non-generic
handling hasn't run, the hardware condition that created the initial
interrupt has not been cleared. Therefore, the interrupt controller
vectors to the ISR entry again, repeating the cycle.
Yes, this is how it works on the beagle BSP. With the ARM GIC it works
like this:
1) The RX ISR fires, vectoring the code to the ISR entry.
2) The code in the ISR disables exactly this interrupt source, creates
an event to be handled by RTEMS (in a non interrupt context)
3) The interrupt server thread eventually calls the real ISR routine
which clears the interrupt condition.
4) The interrupt server thread enables exactly this interrupt source.
In this case, the fundamental problem is that an ISR will continue
firing until the condition causing it is resolved. In the case of an
RX interrupt, that usually would mean reading data from a SFR or
buffer. I'm not familiar with this specific case, but it sounds
awfully similar.
Does this sound right?
If so, it seems like a rather fundamental problem I haven't been able
to resolve. I'm hoping someone has found a reasonable solution that I
wasn't smart enough to figure out my self.
Isaac
On Thu, May 28, 2015 at 8:01 AM, Sebastian Huber
<sebastian.hu...@embedded-brains.de
<mailto:sebastian.hu...@embedded-brains.de>> wrote:
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
<mailto: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 <tel:%2B49%2089%20189%2047%2041-16>
Fax : +49 89 189 47 41-09 <tel:%2B49%2089%20189%2047%2041-09>
E-Mail : sebastian.hu...@embedded-brains.de
<mailto: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 <mailto:devel@rtems.org>
http://lists.rtems.org/mailman/listinfo/devel
--
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
