[ECOS] Enable EDB7xxx interrupts

Trenton D. Adams tadams@extremeeng.com
Mon Jun 25 15:42:00 GMT 2001


I decided to see if my driver catches the interrupt properly.

I make a call to cf_init ().  The PCMCIA controller is setup
successfully, except for one small pecularity which I might ask about
later.

Now, my program has a thread in an infinite loop dealying 200ms each
time.  It displays register status, etc.  The INTMR1 bit 5 is set after
a call to cf_init () because of the call to cyg_drv_interrupt_create ()
in the cf_hwr_init () of my driver implementation.  Now, what I want to
know, is why the interrupt isn't firing properly.

Here's a clip of code from cf_hwr_init () that sets up the interrupt.
        cyg_drv_interrupt_create(EDB7XXX_CF_DETECT,
            99,                     // Priority - what goes here?
            (cyg_addrword_t) slot,  //  Data item passed to interrupt
handler
            (cyg_ISR_t *)cf_detect_isr,
            (cyg_DSR_t *)cf_detect_dsr,
            &cf_detect_interrupt_handle,
            &cf_detect_interrupt);
        cyg_drv_interrupt_attach(cf_detect_interrupt_handle);
        
        //  Unsupported I think!
        //        cyg_drv_interrupt_configure(EDB7XXX_CF_DETECT, true,
true);  // Detect either edge
        
        
        cyg_drv_interrupt_acknowledge(EDB7XXX_CF_DETECT);
        *(unsigned *)PCICR = EDB7XXX_CF_DETECT_MASK; // only CD1 and CD2
        cyg_drv_interrupt_unmask(EDB7XXX_CF_DETECT);

Here's my ISR.
static int
cf_detect_isr(cyg_vector_t vector, cyg_addrword_t data,
HAL_SavedRegisters *regs)
{
    *(unsigned char*)0x80000043=0x02; // D1 light off
    diag_printf ("Hello!\n");
    cyg_interrupt_mask(EDB7XXX_CF_DETECT);	// Mask until DSR
handles IRQ
    return (CYG_ISR_HANDLED|CYG_ISR_CALL_DSR);  // Run the DSR
}


I don't get a "Hello!" on the diagnostic serial port, nor does the
diagnostic light turn off.

I know that my PCMCIA interrupt fires because that thread that's in an
infinit loop tells me so.  Also, the interrupt for the PCMCIA controller
never gets cleared which it would if the interrupt was to reach my DSR.

> -----Original Message-----
> From: jlarmour@cambridge.redhat.com 
> [ mailto:jlarmour@cambridge.redhat.com ] On Behalf Of Jonathan Larmour
> Sent: Monday, June 25, 2001 1:28 PM
> To: Trenton D. Adams
> Cc: 'Gary Thomas'; 'Lewin A.R.W. Edwards'; 'eCos discussion'
> Subject: Re: [ECOS] Enable EDB7xxx interrupts
> 
> 
> "Trenton D. Adams" wrote:
> > 
> > >
> > > Did you use the create_interrupt() mechanism to attach to this 
> > > interrupt? If not, the system will see it, treat it as 
> spurious and 
> > > simply clear and ignore it.
> > 
> > I do the following in cyg_user_start ()
> >     cyg_interrupt_enable ();
> 
> No need to do this. In fact probably best not to. It'll be 
> done later when the scheduler starts.
> 
> >     cyg_interrupt_create (CYGNUM_HAL_INTERRUPT_EINT1, 99, 0,
> >         InterruptHandler, 0, &hIntr, &intr);
> >     cyg_interrupt_attach (hIntr);
> >     cyg_interrupt_acknowledge(CYGNUM_HAL_INTERRUPT_EINT1);
> >     cyg_interrupt_unmask(CYGNUM_HAL_INTERRUPT_EINT1);
> > 
> > Inside InterruptHandler () I do the following
> >     cyg_interrupt_mask (CYGNUM_HAL_INTERRUPT_EINT1);
> >     cyg_interrupt_acknowledge (CYGNUM_HAL_INTERRUPT_EINT1);
> >     printf ("Interrupt Occured");
> >     cyg_interrupt_unmask (CYGNUM_HAL_INTERRUPT_EINT1);
> 
> You shouldn't need to mask or unmask it because global 
> interrupts are disabled in ISRs.
> 
> > Then I have a thread that continuously prints out the PCMCIA 
> > controller interrupt information.
> > 
> > Anyhow, the printf () in the interrupt handler never occurs.  What 
> > could be wrong?
> 
> A missing \n? For an interrupt handler it is _lots_ better to 
> use diag_printf from <cyg/infra/diag.h>. printf is not interrupt safe.
> 
> Jifl
> -- 
> Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 
> (1223) 271062 Maybe this world is another planet's Hell 
> -Aldous Huxley || Opinions==mine Come to the Red Hat 
> TechWorld open source conference in Brussels!
> Keynotes, techie talks and exhibitions    
> http://www.redhat-techworld.com/
> 



More information about the Ecos-discuss mailing list