Nick,
Thanks for you reply.
Your right. Not calling the interrupt_end() routine would cause the lock
not to be released. After your comment I started looking closer at my
modification.
My original modification of:
/hal/arm/arch/current/src/vectors.S file at line 951.
cmp v1,#CYGNUM_HAL_INTERRUPT_NONE <-- from this
cmp r0,#CYGNUM_HAL_INTERRUPT_NONE <-- to this
v1 originally contained the interrupt vector. But I mistakenly believed
this was the check of the return value from the ISR. I modified it to look
at r0, the return value from the isr. The return value from the isr will be
0-3 (really 1 or 3). The CYGNUM_HAL_INTERRUPT_NONE is -1! (for some reason
I thought it was +1 looking at the assembly listing)
Bottom line, my modification made sure that interrupt_end() would always be
called, even when v1 == CYGNUM_HAL_INTERRUPT_NONE (spurious interrupt).
I just did a quick test with the original code and verified that when a
spurious interrupt occurs, the interrupt_end() routine is not called and the
lock is not released and my problem occurs.
Calling the interrupt_end() routine with a spurious interrupt did not seem
to break anything. Was there a reason why interrupt_end() should not be
called on spurious interrupts?
Now to figure out why I am getting a spurious interrupt with the simple UART
code listed below?
What should I look for in attempting to eliminate spurious interrupts? Can
they be eliminated?
What modifications to eCos source or my project is in order for dealing with
spurious interrupts correctly?
#define CYGNUM_HAL_INTERRUPT_22 22
#define CYGNUM_HAL_INTERRUPT_21 21
#define CYGNUM_HAL_INTERRUPT_20 20
#define CYG_HAL_PRI_HIGH 0
static cyg_interrupt btuart_interrupt_new_object;
static cyg_handle_t btuart_interrupt_handle;
static cyg_vector_t btuart_interrupt_vector = CYGNUM_HAL_INTERRUPT_21;
static cyg_priority_t btuart_interrupt_priority = CYG_HAL_PRI_HIGH;
unsigned int isr_rx_count = 0;
cyg_uint32 btuart_interrupt_isr(
cyg_vector_t vector,
cyg_addrword_t data)
{
unsigned int iir, lsr, rbr;
iir = PXA255_BTIIR;
// check if RX FIFO interrupt
if((iir & PXA255_IIR_IID_INT_ID_MASK) ==
PXA255_IIR_IID_RX_FIFO_INT_PENDING)
{
lsr = PXA255_BTLSR;
while(lsr & PXA255_LSR_DR_DATA_READY)
{
rbr = PXA255_BTRBR;
isr_rx_count++;
lsr = PXA255_BTLSR;
}
}
cyg_interrupt_acknowledge(vector);
return(CYG_ISR_HANDLED);
}
void serial_port_start(void)
{
// GPIO and UART inits here...
cyg_interrupt_create(
btuart_interrupt_vector,
btuart_interrupt_priority,
0,
&btuart_interrupt_isr,
0,
&btuart_interrupt_handle,
&btuart_interrupt_new_object);
cyg_interrupt_attach(btuart_interrupt_handle);
cyg_interrupt_unmask(btuart_interrupt_vector);
// UART interupt enabled here...
}
Joe Porthouse
Toptech Systems, Inc.
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Nick Garnett
Sent: Monday, April 10, 2006 5:36 AM
To: Sergei Organov
Cc: [EMAIL PROTECTED]
Subject: Re: [ECOS] Re: DSR stops running after heavy interrupts. Bug found?
Sergei Organov <[EMAIL PROTECTED]> writes:
> Andrew Lunn <[EMAIL PROTECTED]> writes:
>
> [...]
>
> > However, from what you are saying it sounds like there needs to be
> > another comparison afterwards. Something like:
> >
> > and r0,r0,#2 // CYG_ISR_CALL_DSR
> > beq 17f
>
> No, bit checking of the ISR return value is performed inside the
> interrupt_end() routine:
>
> if( isr_ret & Cyg_Interrupt::CALL_DSR && intr != NULL )
intr->post_dsr()
Exactly. And there are other housekeeping things that go on in
interrupt_end() which cannot be skipped. The most important of these
is decrementing the scheduler lock.
I don't really see how the original poster's problem is fixed by
trying to skip interrupt_end(), I would only expect doing that to
aggravate the problem. The scheduler lock is acquired early in
interrupt processing -- before the ISR is called and we know whether
there is a DSR to call. interrupt_end() decrements the scheduler lock
and as a side-effect may cause any DSRs to be called.
As Andrew has suggested, I think Joe's best way of working out what is
happening is to switch on instrumentation and see if he can track down
the extra increments of the scheduler lock.
--
Nick Garnett eCos Kernel Architect
http://www.ecoscentric.com The eCos and RedBoot experts
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
