New hal port + interrupts + rescheduling + call_pending_dsrs problem

New hal port + interrupts + rescheduling + call_pending_dsrs problem

[Davy Wouters]

Hi all,

I have done a hal port to the Analog Devices Blackfin processor
starting from the latest from cvs version of ecos.
I don't quite understand how the interrupt handling in
default_interrupt_vsr works.

When an interrupt occurs from my uart, i have a interrupt trampoline
which does some vector translation and then calls the
hal_interrupt_default_vsr which calls the isr of my uart rx interrupt.
This isr requests a dsr to run.
I have made the hal_interrupt_default_vsr as instructed ending with
the interrupt_end call from the interrupt object of the kernel.

One of the problems i seem to have is that call_pending_dsrs is called
(from within interrupt_end - scheduler::unlock_inner) while
the processor is still running at the interrupt level of my uart.
(Nested interrupts are disabled, no separate interrupt stack is used)

I assume a return from interrupt should be executed somewhere between
the execution of the isr/post_dsr and the call_pending_dsrs?
Where would this be done, in other words at which point in the hal do
i need to return from my interrupt?

Is it correct that call_pending_dsrs should be executed only when
other interrupts are allowed again, in other words after return from
the interrupt?

Sorry if my questions are a bit confusing, but i don't quite
understand the problems i'm having at this point (Crashes when having
a lot of communication
on my uart rx resulting in ASSERT_FAIL: <6>mutex.cxx[249]cyg_bool
Cyg_Mutex::lock() Locking mutex I already own)

Any suggestions?

Tnx,
Davy Wouters
Atos engineering

Re: New hal port + interrupts + rescheduling + call_pending_dsrs problem

[Andrew Lunn]

> I assume a return from interrupt should be executed somewhere between
> the execution of the isr/post_dsr and the call_pending_dsrs?

Nope. If the scheduler is not locked, the DSR is called in the
interrupt handler context. If the scheduler is locked, the DSR will be
called when the scheduler is unlocked.

> Is it correct that call_pending_dsrs should be executed only when
> other interrupts are allowed again, in other words after return from
> the interrupt?

After returning from the interrupt handler which has been registered
with eCos, but before the actual reti instruction, or what ever is
used to return the processor from interrupt context back into normal
context.
 
> Sorry if my questions are a bit confusing, but i don't quite
> understand the problems i'm having at this point (Crashes when having
> a lot of communication
> on my uart rx resulting in ASSERT_FAIL: <6>mutex.cxx[249]cyg_bool
> Cyg_Mutex::lock() Locking mutex I already own)

Is this crash in thread code? You are not allowed to use mutex, or any
other blocking call in ISR or DSR context. 

      Andrew

Re: New hal port + interrupts + rescheduling + call_pending_dsrs problem

[Davy Wouters]

Hi Andrew,

I guess I got confused because i was thinking too much in the context
of the processor in stead of that of eCos.
The DSR mechanism has nothing to do with processor specific interrupt
handling but more with the eCos kernel internal stuff, correct?
In that case what is the exact role of the DSR in eCos? When to
implement one or not in a device driver?

I'm asking this because I thought that the DSR needed to be executed
after returning from the interrupt (reti or what ever), which is not
the case, in order to allow other interrupts
at this point. I thought that when combining ISR and DSR in one
interrupt handling of the processor, this would take too long and
deteriorate real-time behaviour?

Davy

On Fri, Jun 27, 2008 at 8:24 PM, Andrew Lunn <andrew@lunn.ch> wrote:
>> I assume a return from interrupt should be executed somewhere between
>> the execution of the isr/post_dsr and the call_pending_dsrs?
>
> Nope. If the scheduler is not locked, the DSR is called in the
> interrupt handler context. If the scheduler is locked, the DSR will be
> called when the scheduler is unlocked.
>
>> Is it correct that call_pending_dsrs should be executed only when
>> other interrupts are allowed again, in other words after return from
>> the interrupt?
>
> After returning from the interrupt handler which has been registered
> with eCos, but before the actual reti instruction, or what ever is
> used to return the processor from interrupt context back into normal
> context.
>
>> Sorry if my questions are a bit confusing, but i don't quite
>> understand the problems i'm having at this point (Crashes when having
>> a lot of communication
>> on my uart rx resulting in ASSERT_FAIL: <6>mutex.cxx[249]cyg_bool
>> Cyg_Mutex::lock() Locking mutex I already own)
>
> Is this crash in thread code? You are not allowed to use mutex, or any
> other blocking call in ISR or DSR context.
>
>      Andrew
>

Re: New hal port + interrupts + rescheduling + call_pending_dsrs problem

[Andrew Lunn]

> The DSR mechanism has nothing to do with processor specific interrupt
> handling but more with the eCos kernel internal stuff, correct?
> In that case what is the exact role of the DSR in eCos? When to
> implement one or not in a device driver?

ISR can run any time interrupts are enabled. There is very little you
can actually do in ISR context, just read/write bits in the hardware,
generally you just disable the interrupt source. The ISR handler
cannot do anything with the eCos scheduler.

DSR will only run when the eCos scheduler is in a consistent state,
i.e.  the scheduler is not locked. DSR are allowed to do none blocking
calls, eg signal a semaphore to wake up a thread etc.

> I'm asking this because I thought that the DSR needed to be executed
> after returning from the interrupt (reti or what ever), which is not
> the case, in order to allow other interrupts
> at this point. I thought that when combining ISR and DSR in one
> interrupt handling of the processor, this would take too long and
> deteriorate real-time behaviour?

Your ISR and DSR handlers should not do any activities which take a
long time, since while ISR & DSR are running, threads are not
running. If you do need to do a lot of work it is much better to have
a thread doing it, so the scheduler can pre-empty it for a higher
priority thread. The TCP/IP stack follows this model. The Ethernet
device drivers have a thread doing the actual copy of the packet from
the hardware to the stack and the stack is run in a thread.

    Andrew