[ECOS] How DSR is executed in interrupt ?
ariga masahiro
ariga@link-lab.co.jp
Tue Sep 11 02:44:00 GMT 2007
Hi,
Thank you , Andrew,for your reply.
Andrew wrote--
> Are you sure the ISR is being called multiple times?
Definitely.Forever repeating.
> This masks the interrupt. i.e. it should disable the interrupt
> controller from causing further interrupts from this source. The
> interrupt is usually unmasked in the delivery function once the
> hardware has been reprogrammed to de-assert the interrupt. Since you
> say the DSR is not getting called, i don't see how the interrupt can
> get unmasked and so i don't see how the ISR can be called again.....
You are right I'm confirmed doing masking in ISR.
> This suggests that cyg_drv_interrupt_mask() is not working. It is not
> masking the interrupt. I would take a look at your HAL and check the
> interrupt handling code.
I studied cyg_drv_interrupt_mask() and learned it calls
packages\kernel\v2_0\src\intr\intr.cxx(614):
Cyg_Interrupt::mask_interrupt(cyg_vector vector)
But it's too complicated.
Is there any way (like diag_printf) I could check entering this class
function and working correctly ?
I couldn't break in this function in ICE.
If this function is working properly , it's outside of ISR where unmasking
is executed.
Is it possible ISR returns in VSR and somewhere did unmask and entering
ISR repeatedly ?
Since DSR was never called,I think it's somewhere except DSR.
> As i've said before v2_0 is very old. It could be this has been fixed
> in newer code....
I am desperately trying to revise source using WinCVS,but WinCVS
can't operate properly.I still am trying.
Do I need to revise configtool also ?
Masahiro Ariga
-----------------------------------------------------------------------------------
> On Mon, Sep 10, 2007 at 05:21:21PM +0900, ariga masahiro wrote:
>> Hi,
>>
>> Please help me next question ?
>>
>> I am trying to run LAN91CXX drive on interrupt,
>> and it became to enter ISR routine when IRQ3 Line is asserted.
>>
>> But it looks like IRQ3 Line is ON-State forever and never become
>> OFF-State.
>> ISR is repetedly entered but never enter into DSR routine.
>>
>> ISR/DSR are setted like this in smsc_lan91cxx_init(),
>> // Initialize environment, setup interrupt handler
>> cyg_drv_interrupt_create(cpd->interrupt,
>> 8, // Priority - what goes here?
>> (cyg_addrword_t)sc, // Data item passed to
>> interrupt handler
>> (cyg_ISR_t *)lan91cxx_isr,
>> (cyg_DSR_t *)eth_drv_dsr, // The logical
>> driver
>> DSR
>> &lan91cxx_interrupt_handle,
>> &lan91cxx_interrupt);
>> cyg_drv_interrupt_attach(lan91cxx_interrupt_handle);
>>
>> ISR is like below,
>> static int
>> lan91cxx_isr(cyg_vector_t vector, cyg_addrword_t data
>> /* , HAL_SavedRegisters *regs */ )
>> {
>> struct eth_drv_sc *sc = (struct eth_drv_sc *)data;
>> struct lan91cxx_priv_data *cpd =
>> (struct lan91cxx_priv_data *)sc->driver_private;
>>
>> DEBUG_FUNCTION();
>>
>> INCR_STAT( interrupts );
>>
>> cyg_drv_interrupt_mask(cpd->interrupt);
>> cyg_drv_interrupt_acknowledge(cpd->interrupt);
>> return (CYG_ISR_HANDLED|CYG_ISR_CALL_DSR); // Run the DSR
>> }
>
> Are you sure the ISR is being called multiple times?
>
> This masks the interrupt. i.e. it should disable the interrupt
> controller from causing further interrupts from this source. The
> interrupt is usually unmasked in the delivery function once the
> hardware has been reprogrammed to de-assert the interrupt. Since you
> say the DSR is not getting called, i don't see how the interrupt can
> get unmasked and so i don't see how the ISR can be called again.....
>
> This suggests that cyg_drv_interrupt_mask() is not working. It is not
> masking the interrupt. I would take a look at your HAL and check the
> interrupt handling code.
>
>> I think /packages/io/eth/v2_0/src/net/eth_drv.c file's
>
> As i've said before v2_0 is very old. It could be this has been fixed
> in newer code....
>
> Andrew
>
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
More information about the Ecos-discuss
mailing list