Interrupt Problems (again).

[Nick Thomas]

> On 02/12/2010 11:55 AM, Gedare Bloom wrote:
> > I haven't been using RTEMS that long, so I don't have much advice for
> > you, but I did have one thought to share.
> >
> > Perhaps something strange is going on with a CPU dependent
> > implementation of _ISR_Is_in_progress. Try this:
> >   >  cd ${RTEMS}/cpukit/score/cpu/powerpc/rtems
> >   >  grep -r CPU_PROVIDES_ISR_IS_IN_PROGRESS *
> >
> > If you get back something that says TRUE, that gives you something
> > else to look for. score relies on _ISR_Nest_level to determine
> whether
> > or not an interrupt is happening, but I suppose a mismatch between
> > _ISR_Nest_level and the result of rtems_interrupt_is_in_progress()
> > could be caused by a port that provides an alternate implementation
> of
> > _ISR_Is_in_progress.
> >
> > AFAIK there aren't any ports that actually use this option in the
> > current release...
> >
> The PowerPC has kept the level in a register and since old RTEMS
> PowerPC had BSP specific interrupt entry and exit code, it could be
> incorrect in a BSP specific way.
> 
> 2003-07-18      Till Straumann <strauman at slac.stanford.edu>
> 
>          PR 288/rtems
>          * rtems/new-exceptions/cpu.h: _ISR_Nest_level is now properly
>          maintained and does not reside in SPRG0.
> 
> I would be suspicious of your .S code that is CPU model or BSP
> specific.
> 

You're going to have to dumb it down a bit for me. I'm out of my depth here.
What I see now is that the _ISR_Nest_level is getting stuck at 1, and this
is preventing my tasks from running.
So, the unit appears to lock up.
But, I can modify the memory where the _ISR_Nest_level resides, and set it
to zero, and the tasks start running again - for a short while, until
another problem causes a crash!

So, what would cause the _ISR_Nest_level variable to be stuck on?


Regards

Nick