interrupt handling on task scheduling

[Francesco Poletti]

Hi Joel,
thanks for the first answer...Sorry to bother you again...

We discovered that for the arm boards the function
 _CPU_ISR_Disable(level);
 _CPU_ISR_Enable(level);
Doesn't change the previous state of the interrupt instead the 
_CPU_ISR_Set_level(); When is invoked it enables all the interrupt.
Is this behaviour correct? Should we read the porting manual for better
understand it?

The strange fact is that in our case when the idle task is scheduled: sometimes
the _CPU_ISR_Set_level();  is invoked and other times no.
So when this function is runned everything works ok for us, but on the other
hand if noone calls this function the interrupt remain disabled...

Who invoke the _CPU_ISR_Set_level()? Because we were unfortunately able to
understand that...
And more, in which part of the code we can see that the idle task is scheduled
and started?

Really thanks in advance.

Francesco.



> Francesco Poletti wrote:
> > Hy all,
> > We have a porting for the rtems 4.6 working on our simulated arm board.
> > We are developing message passing support for a multiprocessor context with the
> > help of dedicated hardware.
> > We are pointing out some problems in the interrupt handling while the systems is
> > supending a task...
> > Basically we notice that while we run the command rtems_task_suspend(RTEMS_SELF)
> > the OS sometimes performe this sequency of command:
> > _CPU_ISR_Disable(level);
> > _CPU_ISR_Flash();
> > _CPU_ISR_Enable(level)
> > 
> > _CPU_ISR_Disable(level);
> > _CPU_ISR_Enable(level)
> > 
> > _CPU_ISR_Set_level(); //which enforce the system to reable the interrupt on arm
> > processor
> > 
> > We need that the OS reable the interrupt because we supsend the thread waiting
> > for an interrupt and at the same time we have already run
> > _CPU_ISR_Disable(level); for give to the critical section of our API the
> > interrupt safeness... Of course if none reables the interrupt handling before
> > the task suspends then the systems get locked...
> > 
> > The point is that we were not able to understand from where the
> > _CPU_ISR_Set_level()is launched...
> > As far as we noticed it's invoked when the new task is scheduled...is it
possible?
> 
> Interrupt disable levelis part of the per-thread context.  So if a
> thread blocks with interrupts disabled, they are potentially reenabled
> as part of the switch to another thread.  The IDLE thread should have
> interrupts enabled almost all the time (except during switching it
> in and out) so if the application threads all disable interrupts, there
> will be no interrupt processing until the IDLE thread runs.
> 
> I think this matches your described behavior and is expected.  If
> a thread disables interrupts and blocks, then they stay disabled
> until another thread is switched to.
> 
> --joel
> 
> 
> > Thanks in advance, Francesco.
> > 
> > 
> > 
> > 
> 
> 
> -- 
> Joel Sherrill, Ph.D.             Director of Research & Development
> joel at OARcorp.com                 On-Line Applications Research
> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
>     Support Available             (256) 722-9985
> 
>