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
>
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 PIC
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
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 *cpu
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 r
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.
On 28/05/15 13:14, ragu nath wrote:
Hi
Hi Ben,
I found the reason for system hang in BBB after link goes up. It is
caused by enabling the interrupt before it is processed creating a
continuous flow of interrupts hogging the CPU.
In rtems-libbsd we do not directly call the interrupt handler. we
create an event through interrupt trigg
Thank you. I will check the git log. I am also inclined to using nexus
support. I already compiled the driver using nexus support. I fully
intend to add more documentation to the project. I will keep posting
on this thread if I have any further issues.
Thanks,
Ragunath
On Fri, May 15, 2015 at 12
You have two options.
1. You port simplebus to libbsd. I tried this before and its not done in
one day.
2. You get rid of all simplebus dependencies in the driver and use the
libbsd nexus support. This is normally done in a couple of minutes with
the use some hacks to get the FDT provided pa
