That explains a lot and makes a lot of sense. I was thinking about only
disabling the entire interrupt controller.
Thanks!
Isaac
On Thu, May 28, 2015 at 8:34 AM, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
> 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
