RE: [ECOS] Enable EDB7xxx interrupts

RE: [ECOS] Enable EDB7xxx interrupts

[Dan Conti]

> > Is EINT1 brought out anywhere on the board? Have you scoped 
> > it? I take it PCCIRRx are registers that control whether or 
> > not the pc card controller trips EINT1 on a card interrupt? 
> > For PCIOSR you indicate that you can switch interrupts 
> > between EINT1 and the fiq, have you tried setting up a 
> > handler on the fiq to see if that is catching any of your 
> > interrupts? Is EINT1 shared on that board? Is it possible 
> > that something else is holding it in limbo? From the cirrus 
> > web page, the cl-ps6700 can only be clocked at 13 or 18mHz, i 
> > take it your bus speed is adjusted appropriately? It might 
> > help if you included your definitions for PCCIRR1, PCPMR, 
> > PCSICR, PCIOSR, and a brief snippet of the output from your 
> > program. Also, out of convention, it's a bit more clear if 
> > you use the pin definitions in hal_edb7xxx.h, such as 
> > SYSCON2_PCMCIA1 instead of 0x020.
> > 
> > In general your interrupt usage looks ok, i would be more 
> > suspicious about the setup of the controller or the hardware 
> > than eCos interrupt management.
> 
> Thanks for the reply
> 
> PCCIRR = PC Card Interrupt Reserved Register
> 	These need to be set to all 1s in order for interrupts to be
> enabled.
> PCIOSR = PC Card Interrupt Output Select
> 	This register selects which interrupts are output to what line.
> Eg EINT1

Can you switch the line on these so they output to a different interrupt
line and listen on that line?

> PCICR = PC Card Interrupt Clear Register

So presumably flipping a bit high in the interrupt clear register clears
a pc card interrupt.

> I've got eCos set to 18Mhz on top of doing it manually in my 
> code.  The
> line with SYSCON3 does this.  But, as I said, eCos is set for 18Mhz
> anyhow.

Ahh i see now.
 
> I'm pretty sure EINT1 is not shared.  If it is, it's eCos sharing it,
> and I don't know if it is or not.

By shared i mean does the board have EINT1 wired to two physical
interfaces, but i'm guessing cirrus probably didn't do that.
 
I dont have a 7211 laying around atm, but if the interrupt lead off it
is exposed i would scope that to make sure it's actually generating an
interrupt.

-Dan

RE: [ECOS] Enable EDB7xxx interrupts

[Trenton D. Adams]

> > > Is EINT1 brought out anywhere on the board? Have you scoped
> > > it? I take it PCCIRRx are registers that control whether or 
> > > not the pc card controller trips EINT1 on a card interrupt? 
> > > For PCIOSR you indicate that you can switch interrupts 
> > > between EINT1 and the fiq, have you tried setting up a 
> > > handler on the fiq to see if that is catching any of your 
> > > interrupts? Is EINT1 shared on that board? Is it possible 
> > > that something else is holding it in limbo? From the cirrus 
> > > web page, the cl-ps6700 can only be clocked at 13 or 18mHz, i 
> > > take it your bus speed is adjusted appropriately? It might 
> > > help if you included your definitions for PCCIRR1, PCPMR, 
> > > PCSICR, PCIOSR, and a brief snippet of the output from your 
> > > program. Also, out of convention, it's a bit more clear if 
> > > you use the pin definitions in hal_edb7xxx.h, such as 
> > > SYSCON2_PCMCIA1 instead of 0x020.
> > > 
> > > In general your interrupt usage looks ok, i would be more
> > > suspicious about the setup of the controller or the hardware 
> > > than eCos interrupt management.
> > 
> > Thanks for the reply
> > 
> > PCCIRR = PC Card Interrupt Reserved Register
> > 	These need to be set to all 1s in order for interrupts 
> to be enabled.
> > PCIOSR = PC Card Interrupt Output Select
> > 	This register selects which interrupts are output to what line.
> > Eg EINT1
> 
> Can you switch the line on these so they output to a 
> different interrupt line and listen on that line?

I just tried EXTFIQ, and it doesn't work either.

> > PCICR = PC Card Interrupt Clear Register
> 
> So presumably flipping a bit high in the interrupt clear 
> register clears a pc card interrupt.

If you mean setting it, yes.

> > I'm pretty sure EINT1 is not shared.  If it is, it's eCos 
> sharing it, 
> > and I don't know if it is or not.
> 
> By shared i mean does the board have EINT1 wired to two 
> physical interfaces, but i'm guessing cirrus probably didn't do that.

From what others on the list have said, there are only two interrupts on
the EP7211 and everything are wired to them.  The Preliminary Data Sheet
says the same thing.  It says there are Seventeen interrupts sources
mapped to the IRQ line, and five sources mapped to the FIQ input.

> I dont have a 7211 laying around atm, but if the interrupt 
> lead off it is exposed i would scope that to make sure it's 
> actually generating an interrupt.

I tested the lines with a multi tester.  All the relevant lines
throughout the board are working.  The only problem is, is that the
CL-PS6700 controller is not pulling the lines low like it should when an
interrupt occurs.  It looks like the chip might be fried, but I'm not
sure yet.  I would think that if the controller is fully active like it
appears to be then there would be no need to do something to enable the
actual output of the interrupt lines, would there?  I mean the
interrupts appear to be working as far as the CL-PS6700 controller
registers are concerned.  If this is the case, wouldn't the be
outputting to the lines?

RE: [ECOS] Enable EDB7xxx interrupts

[Gary Thomas]

On 26-Jun-2001 Trenton D. Adams wrote:
> I tested the lines with a multi tester.  All the relevant lines
> throughout the board are working.  The only problem is, is that the
> CL-PS6700 controller is not pulling the lines low like it should when an
> interrupt occurs.  It looks like the chip might be fried, but I'm not
> sure yet.  I would think that if the controller is fully active like it
> appears to be then there would be no need to do something to enable the
> actual output of the interrupt lines, would there?  I mean the
> interrupts appear to be working as far as the CL-PS6700 controller
> registers are concerned.  If this is the case, wouldn't the be
> outputting to the lines?

Maybe you should ask someone at Cirrus Logic.  This wouldn't be the
first [broken] device on those boards (don't ask about the supposed
serial EEPROMS on my EDB7212 board...)

RE: [ECOS] Enable EDB7xxx interrupts

[Trenton D. Adams]

Ya, I emailed them just before the list.  I'll let you guys know if it's
a problem with the chip or not.

> -----Original Message-----
> From: gary@chez-thomas.org [ mailto:gary@chez-thomas.org ] On 
> Behalf Of Gary Thomas
> Sent: Tuesday, June 26, 2001 11:41 AM
> To: Trenton D. Adams
> Cc: eCos discussion; eCos discussion; Trenton D. Adams; Dan Conti
> Subject: RE: [ECOS] Enable EDB7xxx interrupts
> 
> 
> 
> On 26-Jun-2001 Trenton D. Adams wrote:
> > I tested the lines with a multi tester.  All the relevant lines 
> > throughout the board are working.  The only problem is, is that the 
> > CL-PS6700 controller is not pulling the lines low like it 
> should when 
> > an interrupt occurs.  It looks like the chip might be 
> fried, but I'm 
> > not sure yet.  I would think that if the controller is fully active 
> > like it appears to be then there would be no need to do 
> something to 
> > enable the actual output of the interrupt lines, would 
> there?  I mean 
> > the interrupts appear to be working as far as the CL-PS6700 
> controller 
> > registers are concerned.  If this is the case, wouldn't the be 
> > outputting to the lines?
> 
> Maybe you should ask someone at Cirrus Logic.  This wouldn't 
> be the first [broken] device on those boards (don't ask about 
> the supposed serial EEPROMS on my EDB7212 board...)
> 

RE: [ECOS] Enable EDB7xxx interrupts

[Lewin A.R.W. Edwards]

>Maybe you should ask someone at Cirrus Logic.  This wouldn't be the
>first [broken] device on those boards (don't ask about the supposed
>serial EEPROMS on my EDB7212 board...)

Simple mistake, could have happened to anyone... all 8-pin SOICs are the 
same aren't they? <gdr>

First prototypes we got of our last project had an "xxx0" on them instead 
of "xxx1" on the grounds that "supplier say parts very similar and in same 
package". It was a 208-pin PQFP, very difficult to rework, we threw the 
boards in the trash.


-- Lewin A.R.W. Edwards
Embedded Engineer, Digi-Frame Inc.
Work: http://www.digi-frame.com/
Tel (914) 937-4090 9am-6:30pm M-F ET
Personal: http://www.larwe.com/ http://www.zws.com/

"Far better it is to dare mighty things, to win glorious triumphs, even 
though checkered by failure, than to rank with those poor spirits who 
neither enjoy much nor suffer much, because they live in the gray twilight 
that knows not victory nor defeat."
(Theodore Roosevelt)

RE: [ECOS] Enable EDB7xxx interrupts

[Lewin A.R.W. Edwards]

>I tested the lines with a multi tester.  All the relevant lines

You might not see a pulse on that though.

Try clipping a lead on gnd or +3.3V (whichever edge trips your particular 
interrupt), and manually firing the interrupt by tapping the other end of 
the lead to the trace.

>sure yet.  I would think that if the controller is fully active like it
>appears to be then there would be no need to do something to enable the
>actual output of the interrupt lines, would there?  I mean the

probably an interrupt enable masking register in the controller, I haven't 
programmed that part but I'm using a couple of other PCMCIA interface parts 
that both have internal mask-off for interrupts.



-- Lewin A.R.W. Edwards
Embedded Engineer, Digi-Frame Inc.
Work: http://www.digi-frame.com/
Tel (914) 937-4090 9am-6:30pm M-F ET
Personal: http://www.larwe.com/ http://www.zws.com/

"Far better it is to dare mighty things, to win glorious triumphs, even 
though checkered by failure, than to rank with those poor spirits who 
neither enjoy much nor suffer much, because they live in the gray twilight 
that knows not victory nor defeat."
(Theodore Roosevelt)

RE: [ECOS] Enable EDB7xxx interrupts

[Trenton D. Adams]

> >I tested the lines with a multi tester.  All the relevant lines
> 
> You might not see a pulse on that though.

I never clear the interrupts so I should see it shouldn't I?

> Try clipping a lead on gnd or +3.3V (whichever edge trips 
> your particular 
> interrupt), and manually firing the interrupt by tapping the 
> other end of 
> the lead to the trace.

Thanks for the tip, the interrupts work just fine.  I'm still not
getting anything from the CL-PS6700 controller so I'm inclined to think
that it is in fact fried.  I'm almost positive that my code for enabling
everything in the chip is correct.  I'm waiting for a reply from Cirrus
to find out what they think

> probably an interrupt enable masking register in the 
> controller, I haven't 
> programmed that part but I'm using a couple of other PCMCIA 
> interface parts 
> that both have internal mask-off for interrupts.

Yep, already did that, the interrupts won't even happen unless I enable
them by writing ones to all three Interrupt reserved registers.

RE: [ECOS] Enable EDB7xxx interrupts

[Lewin A.R.W. Edwards]

> > >I tested the lines with a multi tester.  All the relevant lines
> >
> > You might not see a pulse on that though.
>
>I never clear the interrupts so I should see it shouldn't I?

Not necessarily (remember that I haven't read the datasheet for the 6700 
though). The INTSR regs inside the 7312 will hold their request state 
regardless of the physical pin state. The PS6700 might be issuing a pulsed 
interrupt request. That will latch a request into INTSRx and whisk the CPU 
into an IRQ or FIQ state, but it won't leave any state on the interrupt 
line itself.

Pop a DSO on the actual pin of the PS6700 (if you have one) and capture the 
timeframe surrounding your interrupt event...

>getting anything from the CL-PS6700 controller so I'm inclined to think
>that it is in fact fried.  I'm almost positive that my code for enabling
>everything in the chip is correct.  I'm waiting for a reply from Cirrus

One issue that bit me fair on the rump with the EDB7209 (actually 7212) is 
that a jumper needs to be moved and/or a resistor clipped in order to get 
interrupts working on the Ethernet controller. There could well be 
something similar on your EDB. Check the schematic and see where those 
interrupt lines run. I think in the case of the EDB7212 (I'm not looking at 
the schematic now... my mind is full of SA1110 PCMCIA problems and I don't 
want to confuse myself!) the same interrupt request line is shared between 
ethernet and parallel port and the default factory setup routes the CPU's 
interrupt line to the parallel port, so no Ethernet interrupts ever.


-- Lewin A.R.W. Edwards
Embedded Engineer, Digi-Frame Inc.
Work: http://www.digi-frame.com/
Tel (914) 937-4090 9am-6:30pm M-F ET
Personal: http://www.larwe.com/ http://www.zws.com/

"Far better it is to dare mighty things, to win glorious triumphs, even 
though checkered by failure, than to rank with those poor spirits who 
neither enjoy much nor suffer much, because they live in the gray twilight 
that knows not victory nor defeat."
(Theodore Roosevelt)

RE: [ECOS] Enable EDB7xxx interrupts

[Trenton D. Adams]

> > > >I tested the lines with a multi tester.  All the relevant lines
> > >
> > > You might not see a pulse on that though.
> >
> >I never clear the interrupts so I should see it shouldn't I?
> 
> Not necessarily (remember that I haven't read the datasheet 
> for the 6700 
> though). The INTSR regs inside the 7312 will hold their request state 
> regardless of the physical pin state. The PS6700 might be 
> issuing a pulsed 
> interrupt request. That will latch a request into INTSRx and 
> whisk the CPU 
> into an IRQ or FIQ state, but it won't leave any state on the 
> interrupt 
> line itself.

I did test the EINT1 interrupt on the CPU as you suggested with the
multi tester by pulling it low, and fired just fine.

> Pop a DSO on the actual pin of the PS6700 (if you have one) 
> and capture the 
> timeframe surrounding your interrupt event...

What's a DSO?  Do you mean a logic analyzer?

> One issue that bit me fair on the rump with the EDB7209 
> (actually 7212) is 
> that a jumper needs to be moved and/or a resistor clipped in 
> order to get 
> interrupts working on the Ethernet controller. There could well be 
> something similar on your EDB. Check the schematic and see 
> where those 
> interrupt lines run. I think in the case of the EDB7212 (I'm 
> not looking at 
> the schematic now... my mind is full of SA1110 PCMCIA 
> problems and I don't 
> want to confuse myself!) the same interrupt request line is 
> shared between 
> ethernet and parallel port and the default factory setup 
> routes the CPU's 
> interrupt line to the parallel port, so no Ethernet interrupts ever.

Yep, already did that, a jumper is required for the FIQ, but not the IRQ
line.  The FIQ jumper has been on the entire time however.

RE: [ECOS] Enable EDB7xxx interrupts

[Lewin A.R.W. Edwards]

>I did test the EINT1 interrupt on the CPU as you suggested with the
>multi tester by pulling it low, and fired just fine.

OK, that means your software is good, but we still haven't narrowed the 
problem down beyond these possibilities:

* PS6700 not configured correctly to generate interrupts
* PS6700 configured correctly and generating interrupts, but those 
interrupts not [electrically] making it to the CPU
* PS6700 fried

If you can talk to the chip at all then it is not impossible but quite 
unlikely that the chip is hosed; it wouldn't be high on my list of 
priorities to investigate. The other Cirrus EDB problem Gary was talking 
about was a pick-n-place error wherein some boards had the wrong part 
fitted instead of the EEPROM required for the CS8900's config info, it 
wasn't a subtle problem at all.

> > Pop a DSO on the actual pin of the PS6700 (if you have one)
> > and capture the
> > timeframe surrounding your interrupt event...
>
>What's a DSO?  Do you mean a logic analyzer?

Digital Storage Oscilloscope.

>Yep, already did that, a jumper is required for the FIQ, but not the IRQ
>line.  The FIQ jumper has been on the entire time however.

If the line is tied to another outputs from a different device, or has an 
overly aggressive pullup/pulldown then the 6700 might not be able to pull 
the CPU's input high/low enough to assert an interrupt request if the other 
device's output is not tristated. When you poked it with your wire, you 
forced the issue.

If possible it could be instructive to isolate the int out pin(s) from the 
6700 and see if they show activity when electrically isolated from the rest 
of the circuit.


-- Lewin A.R.W. Edwards
Embedded Engineer, Digi-Frame Inc.
Work: http://www.digi-frame.com/
Tel (914) 937-4090 9am-6:30pm M-F ET
Personal: http://www.larwe.com/ http://www.zws.com/

"Far better it is to dare mighty things, to win glorious triumphs, even 
though checkered by failure, than to rank with those poor spirits who 
neither enjoy much nor suffer much, because they live in the gray twilight 
that knows not victory nor defeat."
(Theodore Roosevelt)

RE: [ECOS] Enable EDB7xxx interrupts

[Trenton D. Adams]

> >I did test the EINT1 interrupt on the CPU as you suggested with the 
> >multi tester by pulling it low, and fired just fine.
> 
> OK, that means your software is good, but we still haven't 
> narrowed the 
> problem down beyond these possibilities:
> 
> * PS6700 not configured correctly to generate interrupts
> * PS6700 configured correctly and generating interrupts, but those 
> interrupts not [electrically] making it to the CPU
> * PS6700 fried

Have you ever seen a device that shows that it's generating an interrupt
by looking at it's internal registers, but the actual interrupt is not
making it to the CPU?

> >Yep, already did that, a jumper is required for the FIQ, but not the 
> >IRQ line.  The FIQ jumper has been on the entire time however.
> 
> If the line is tied to another outputs from a different 
> device, or has an 
> overly aggressive pullup/pulldown then the 6700 might not be 
> able to pull 
> the CPU's input high/low enough to assert an interrupt 
> request if the other 
> device's output is not tristated. When you poked it with your 
> wire, you 
> forced the issue.
> 
> If possible it could be instructive to isolate the int out 
> pin(s) from the 
> 6700 and see if they show activity when electrically isolated 
> from the rest 
> of the circuit.
How would you do this when they are wired into the board?

RE: [ECOS] Enable EDB7xxx interrupts

[Trenton D. Adams]

Ok, I'm really pissed off! LOL

The interrupt mask register for the controller requires the
corresponding bits to be set in order for interrupts to be routed
outside the CPU.  What is the purpose of a mask register if a setting of
the bits doesn't MASK!!!  That's stupid.  The documentation doesn't tell
you this specifically of course.  The documentation for the board tells
you this about the INTMR1.  I did try setting them once before, but my
code must have been wrong at the time, otherwise it would have worked.
I should have tried this anyhow whether I did try it before or not.

Anyhow thanks for everyone's help!!!

> -----Original Message-----
> From: Lewin A.R.W. Edwards [ mailto:larwe@larwe.com ] 
> Sent: Tuesday, June 26, 2001 1:10 PM
> To: Trenton D. Adams; 'eCos discussion'
> Subject: RE: [ECOS] Enable EDB7xxx interrupts
> 
> 
> 
> >I did test the EINT1 interrupt on the CPU as you suggested with the 
> >multi tester by pulling it low, and fired just fine.
> 
> OK, that means your software is good, but we still haven't 
> narrowed the 
> problem down beyond these possibilities:
> 
> * PS6700 not configured correctly to generate interrupts
> * PS6700 configured correctly and generating interrupts, but those 
> interrupts not [electrically] making it to the CPU
> * PS6700 fried
> 
> If you can talk to the chip at all then it is not impossible 
> but quite 
> unlikely that the chip is hosed; it wouldn't be high on my list of 
> priorities to investigate. The other Cirrus EDB problem Gary 
> was talking 
> about was a pick-n-place error wherein some boards had the wrong part 
> fitted instead of the EEPROM required for the CS8900's config 
> info, it 
> wasn't a subtle problem at all.
> 
> > > Pop a DSO on the actual pin of the PS6700 (if you have one) and 
> > > capture the timeframe surrounding your interrupt event...
> >
> >What's a DSO?  Do you mean a logic analyzer?
> 
> Digital Storage Oscilloscope.
> 
> >Yep, already did that, a jumper is required for the FIQ, but not the 
> >IRQ line.  The FIQ jumper has been on the entire time however.
> 
> If the line is tied to another outputs from a different 
> device, or has an 
> overly aggressive pullup/pulldown then the 6700 might not be 
> able to pull 
> the CPU's input high/low enough to assert an interrupt 
> request if the other 
> device's output is not tristated. When you poked it with your 
> wire, you 
> forced the issue.
> 
> If possible it could be instructive to isolate the int out 
> pin(s) from the 
> 6700 and see if they show activity when electrically isolated 
> from the rest 
> of the circuit.
> 
> 
> -- Lewin A.R.W. Edwards
> Embedded Engineer, Digi-Frame Inc.
> Work: http://www.digi-frame.com/
> Tel (914) 937-4090 9am-6:30pm M-F ET
> Personal: http://www.larwe.com/ http://www.zws.com/
> 
> "Far better it is to dare mighty things, to win glorious 
> triumphs, even 
> though checkered by failure, than to rank with those poor spirits who 
> neither enjoy much nor suffer much, because they live in the 
> gray twilight 
> that knows not victory nor defeat."
> (Theodore Roosevelt)
> 
> 

RE: [ECOS] Enable EDB7xxx interrupts

[Trenton D. Adams]

> > > > 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.
> > It's still not working.  I took everything out as you suggested.
> > 
> > I've attached my program.
> 
> Is EINT1 brought out anywhere on the board? Have you scoped 
> it? I take it PCCIRRx are registers that control whether or 
> not the pc card controller trips EINT1 on a card interrupt? 
> For PCIOSR you indicate that you can switch interrupts 
> between EINT1 and the fiq, have you tried setting up a 
> handler on the fiq to see if that is catching any of your 
> interrupts? Is EINT1 shared on that board? Is it possible 
> that something else is holding it in limbo? From the cirrus 
> web page, the cl-ps6700 can only be clocked at 13 or 18mHz, i 
> take it your bus speed is adjusted appropriately? It might 
> help if you included your definitions for PCCIRR1, PCPMR, 
> PCSICR, PCIOSR, and a brief snippet of the output from your 
> program. Also, out of convention, it's a bit more clear if 
> you use the pin definitions in hal_edb7xxx.h, such as 
> SYSCON2_PCMCIA1 instead of 0x020.
> 
> In general your interrupt usage looks ok, i would be more 
> suspicious about the setup of the controller or the hardware 
> than eCos interrupt management.

Thanks for the reply

PCCIRR = PC Card Interrupt Reserved Register
	These need to be set to all 1s in order for interrupts to be
enabled.
PCIOSR = PC Card Interrupt Output Select
	This register selects which interrupts are output to what line.
Eg EINT1
PCICR = PC Card Interrupt Clear Register

I've got eCos set to 18Mhz on top of doing it manually in my code.  The
line with SYSCON3 does this.  But, as I said, eCos is set for 18Mhz
anyhow.

I'm pretty sure EINT1 is not shared.  If it is, it's eCos sharing it,
and I don't know if it is or not.

As for using the predefined values in edb7xxx header file, it's just a
testing program so I didn't bother.

RE: [ECOS] Enable EDB7xxx interrupts

[Dan Conti]

> > > 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.
> It's still not working.  I took everything out as you suggested.
> 
> I've attached my program.

Is EINT1 brought out anywhere on the board? Have you scoped it? I take
it PCCIRRx are registers that control whether or not the pc card
controller trips EINT1 on a card interrupt?
For PCIOSR you indicate that you can switch interrupts between EINT1 and
the fiq, have you tried setting up a handler on the fiq to see if that
is catching any of your interrupts?
Is EINT1 shared on that board? Is it possible that something else is
holding it in limbo?
From the cirrus web page, the cl-ps6700 can only be clocked at 13 or
18mHz, i take it your bus speed is adjusted appropriately?
It might help if you included your definitions for PCCIRR1, PCPMR,
PCSICR, PCIOSR, and a brief snippet of the output from your program.
Also, out of convention, it's a bit more clear if you use the pin
definitions in hal_edb7xxx.h, such as SYSCON2_PCMCIA1 instead of 0x020.

In general your interrupt usage looks ok, i would be more suspicious
about the setup of the controller or the hardware than eCos interrupt
management.

-Dan

RE: [ECOS] Enable EDB7xxx interrupts

[Trenton D. Adams]

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/
> 

RE: [ECOS] Enable EDB7xxx interrupts

[Trenton D. Adams]

[-- Attachment #1: Type: text/plain, Size: 1457 bytes --]

> > >
> > > 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.
It's still not working.  I took everything out as you suggested.

I've attached my program.

[-- Attachment #2: pccontroller.c --]
[-- Type: text/x-c, Size: 6250 bytes --]

/* 
 * Written 1999-03-19 by Jonathan Larmour, Cygnus Solutions
 * This file is in the public domain and may be used for any purpose
 */

/* CONFIGURATION CHECKS */

#include <pkgconf/system.h>     /* which packages are enabled/disabled */
#ifdef CYGPKG_KERNEL
# include <pkgconf/kernel.h>
#endif
#ifdef CYGPKG_LIBC
# include <pkgconf/libc.h>
#endif
#ifdef CYGPKG_IO_SERIAL
# include <pkgconf/io_serial.h>
#endif

#ifndef CYGFUN_KERNEL_API_C
# error Kernel API must be enabled to build this example
#endif

#ifndef CYGPKG_LIBC_STDIO
# error C library standard I/O must be enabled to build this example
#endif

#ifndef CYGPKG_IO_SERIAL_HALDIAG
# error I/O HALDIAG pseudo-device driver must be enabled to build this example
#endif

/* INCLUDES */

#include <stdio.h>                      /* printf */
#include <math.h>
#include <stdlib.h>
#include <string.h>                     /* strlen */
#include <cyg/kernel/kapi.h>            /* All the kernel specific stuff */
#include <cyg/io/io.h>                  /* I/O functions */
#include <cyg/hal/hal_arch.h>           /* CYGNUM_HAL_STACK_SIZE_TYPICAL */
#include <cyg/hal/hal_edb7xxx.h>
#include <cyg/infra/diag.h>


/* now declare (and allocate space for) some kernel objects,
   like the two threads we will use */
cyg_thread thread_s[2];		/* space for two thread objects */

char stack[2][4096];		/* space for two 4K stacks */

/* now the handles for the threads */
cyg_handle_t slotWatch, start;

/* and now variables for the procedure which is the thread */
cyg_thread_entry_t WatchSlot;
cyg_thread_entry_t Start;

cyg_ISR_t InterruptHandler;
cyg_interrupt intr;
cyg_handle_t hIntr;


int mymain (void);

/* and now a mutex to protect calls to the C library */
cyg_mutex_t cliblock;

/* we install our own startup routine which sets up threads */
void cyg_user_start(void)
{

    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);

	cyg_mutex_init(&cliblock);

	cyg_thread_create(4, WatchSlot, (cyg_addrword_t) 0,
		"Slot Watch", (void *) stack[0], 4096,
		&slotWatch, &thread_s[0]);
	cyg_thread_create(4, Start, (cyg_addrword_t) 0,
		"Start", (void *) stack[1], 4096,
		&start, &thread_s[1]);
	
	printf ("Starting Threads!\n");
	cyg_thread_resume(start);
	cyg_thread_resume(slotWatch);
	
	
	//    *(volatile char *)0x80000043 = 0x04;
	
	
	//cyg_scheduler_start ();
}

void WatchSlot (cyg_addrword_t data)
{
	
   for (;;)
   {
       cyg_mutex_lock (&cliblock);
	   cyg_thread_delay(200);
	   printf (
           "\n\nCD2 | CD1 | BVD2 | BVD1\n"
           " %s     %s     %s      %s\n"
           "ISR = %0#x\n"
           "IILR = %0#x\n"
           "INTSR1 = %0#x\n"
           "INTMR1 = %0#x\n"
           "PC Card Slot is %s.\n",
           *(unsigned *)PCISR & EV_PCM_CD2 ? "1":"0",
           *(unsigned *)PCISR & EV_PCM_CD1 ? "1":"0",
           *(unsigned *)PCISR & EV_PCM_BVD2 ? "1":"0",
           *(unsigned *)PCISR & EV_PCM_BVD1 ? "1":"0",
           *(unsigned *)PCISR,
           *(unsigned *)PCCIILR,
           *(unsigned *)INTSR1,
           *(unsigned *)INTMR1,
           ((*(unsigned *)PCCIILR & EDB7XXX_CF_DETECT_MASK) != 
            EDB7XXX_CF_PRESENT) ? "Empty" : "Occupied");

       if (*(unsigned *)PCISR)
           cyg_thread_delay (200);

       *(unsigned *)PCICR = 0xFFFFFFFF;
       
       cyg_mutex_unlock (&cliblock);
   }
}


void Start (cyg_addrword_t data)
{

    char tempString[1024];

    *(unsigned short*)SYSCON3   &= ~0x06;     // 18 MHz
    *(unsigned char*)PEDDR      |= 0x02;      // +5V on
    *(unsigned char*)PEDR       |= 0x02;      // +5V on
    *(unsigned short*)PMPCON    |= 0x0002;    // +12V DC-DC converter on
    *(unsigned *)SYSCON1        |= 0x00040000;// EXPCLK on
    *(unsigned short*)SYSCON2   |= 0x0020;    // PCMCIA Slot 1 on

    *(unsigned*)PCSICR &= ~0x0020; // Disable byte swapping
    *(unsigned*)PCPMR |= 0x0c00 | PCPMR_AUTO_IDLE;    // weak pull-up

    // Enable CL-PS6700 interrupts
    *(unsigned*)PCCIRR1 = 0xFFFFFFFF;
    *(unsigned*)PCCIRR2 = 0xFFFFFFFF;
    *(unsigned*)PCCIRR3 = 0xFFFFFFFF;


    // Setup Interrupt output information
    *(unsigned*)PCIOSR = 0x7FF3;     // Card Detect on EINT1.  All others FIQ

    *(unsigned*)PCICR = 0xFFFFFFFF;
//    *(unsigned short*)INTMR1 |= INTSR1_EINT1 | INTSR1_EINT2 | INTSR1_EINT3 | INTSR1_EXTFIQ;
//    *(unsigned*)PCCICR |= 0x0400;  // Card enable

    sprintf (tempString, 
        "Diagnostics Program Started...\n"
        "Port B = %0#x\n"
        "Power Management Register = %0#x\n"
        "Card Power Control Register = %0#x\n"
        "System Interface Config Register = %0#x\n"
        "DMA Control Register = %0#x\n"
        "Device Information Register = %0#x\n"
        "Card Interface Configuration Register = %0#x\n"
        "Card Interface Timing Register 0A = %0#x\n"
        "Card Interface Timing Register 0B = %0#x\n"
        "Card Interface Timing Register 1A = %0#x\n"
        "Card Interface Timing Register 1B = %0#x\n"
        "PC Card Interrupt Status Register = %0#x\n"
        "PC Card Interrupt Mask Register = %0#x\n"
        "PC Card Interrupt Clear Register = %0#x\n"
        "PC Card Interrupt Output Select Register = %0#x\n"
        "PC Card Interrupt Input Level Register = %0#x\n"
        "PC Card Slot is %s\n",
        *(unsigned char*)PBDR,
        *(unsigned *)PCPMR,
        *(unsigned *)PCPCR,
        *(unsigned *)PCSICR,
        *(unsigned *)PCDMACR,
        *(unsigned *)PCDIR,
        *(unsigned *)PCCICR,
        *(unsigned *)PCCIT0AR,
        *(unsigned *)PCCIT0BR,
        *(unsigned *)PCCIT1AR,
        *(unsigned *)PCCIT1BR,
        *(unsigned *)PCISR,
        *(unsigned *)PCIMR,
        *(unsigned *)PCICR,
        *(unsigned *)PCIOSR,
        *(unsigned *)PCCIILR,
        (*(unsigned *)PCCIILR & EDB7XXX_CF_DETECT_MASK) ? "Empty" : "Occupied");
    printf(tempString);

}

cyg_uint32 InterruptHandler (cyg_vector_t vector, cyg_addrword_t data)
{
    cyg_interrupt_acknowledge (CYGNUM_HAL_INTERRUPT_EINT1);
    diag_printf ("Interrupt Occured\n");
    return (CYG_ISR_HANDLED);
}

int main (void)
{
    return 0;
}

Re: [ECOS] Enable EDB7xxx interrupts

[Jonathan Larmour]

"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/

RE: [ECOS] Enable EDB7xxx interrupts

[Trenton D. Adams]

> 
> 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 ();
    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);

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?

RE: [ECOS] Enable EDB7xxx interrupts

[Trenton D. Adams]

> 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.
> 
> The whole idea of having the OS handle this stuff is so that common 
> mechanisms work, at least in a similar fashion, across 
> different platforms. Because of that, you can't really expect 
> to just poll registers to see what's happening.

Ya, I understand the fact that I should be using the eCos functions.  I
just figured I might not HAVE to.  But, it makes total sense now.

Thanks Gary. 

RE: [ECOS] Enable EDB7xxx interrupts

[Gary Thomas]

On 25-Jun-2001 Trenton D. Adams wrote:
>> -----Original Message-----
>> From: gary@chez-thomas.org [ mailto:gary@chez-thomas.org ] On 
>> Behalf Of Gary Thomas
>> Sent: Monday, June 25, 2001 11:28 AM
>> To: Trenton D. Adams
>> Cc: eCos discussion; eCos discussion; Lewin A.R.W. Edwards
>> Subject: RE: [ECOS] Enable EDB7xxx interrupts
>> 
>> 
>> * these enables are supposed to be set/cleared as appropriate
>>   by the hal_enable_interrupt() and hal_disable_interrupt() routines.
>>   You should not need to manipulate them directly.
>> 
>> * are you sure that you have interrupts enabled in general?  This
>>   happens [implicitly] when you start the scheduler, but not before.
> 
> I'm just made a diagnostics program that looks at the interrupt
> registers to see what happens when I insert/remove the card from the
> PCMCIA slot.  It does it forever in a thread. I enabled the EINT1
> interrupt by setting bit 5 in the INTMR1.  The interrupts work fine
> inside the CL-PS6700, and the bits in the ISR are set for that
> controller.  However, I would expect bit 5 in the INTSR1 of the EP7211
> to be set as well after that interrupt occurs.  Unless of course the HAL
> clears this for some reason.

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.

The whole idea of having the OS handle this stuff is so that common 
mechanisms work, at least in a similar fashion, across different platforms.
Because of that, you can't really expect to just poll registers to see
what's happening.

RE: [ECOS] Enable EDB7xxx interrupts

[Trenton D. Adams]

> -----Original Message-----
> From: gary@chez-thomas.org [ mailto:gary@chez-thomas.org ] On 
> Behalf Of Gary Thomas
> Sent: Monday, June 25, 2001 11:28 AM
> To: Trenton D. Adams
> Cc: eCos discussion; eCos discussion; Lewin A.R.W. Edwards
> Subject: RE: [ECOS] Enable EDB7xxx interrupts
> 
> 
> * these enables are supposed to be set/cleared as appropriate
>   by the hal_enable_interrupt() and hal_disable_interrupt() routines.
>   You should not need to manipulate them directly.
> 
> * are you sure that you have interrupts enabled in general?  This
>   happens [implicitly] when you start the scheduler, but not before.

I'm just made a diagnostics program that looks at the interrupt
registers to see what happens when I insert/remove the card from the
PCMCIA slot.  It does it forever in a thread. I enabled the EINT1
interrupt by setting bit 5 in the INTMR1.  The interrupts work fine
inside the CL-PS6700, and the bits in the ISR are set for that
controller.  However, I would expect bit 5 in the INTSR1 of the EP7211
to be set as well after that interrupt occurs.  Unless of course the HAL
clears this for some reason.

RE: [ECOS] Enable EDB7xxx interrupts

[Gary Thomas]

* these enables are supposed to be set/cleared as appropriate
  by the hal_enable_interrupt() and hal_disable_interrupt() routines.
  You should not need to manipulate them directly.

* are you sure that you have interrupts enabled in general?  This
  happens [implicitly] when you start the scheduler, but not before.

On 25-Jun-2001 Trenton D. Adams wrote:
> Oops, I forgot to mention that I've set bit 5 in the INTMR1.
> 
>> -----Original Message-----
>> From: Lewin A.R.W. Edwards [ mailto:larwe@larwe.com ] 
>> Sent: Monday, June 25, 2001 10:40 AM
>> To: Trenton D. Adams; 'eCos discussion'
>> Subject: Re: [ECOS] Enable EDB7xxx interrupts
>> 
>> 
>> 
>> >I'm testing interrupts with the CL-PS6700 PCMCIA controller 
>> and I need 
>> >to know something about the EDB7xxx interrupts.  Is there 
>> something I 
>> >have to do enable interrupts on the EDB7xxx?  I'm asking 
>> because I can 
>> >get the interrupts on the CL-PS6700 to activate, but the 
>> corresponding 
>> >bits for EINT1 or EXTFIQ in INTSR1 are not activated with it.
>> 
>> Check the interrupt mask registers.
>> 
>> 
>> -- Lewin A.R.W. Edwards
>> Embedded Engineer, Digi-Frame Inc.
>> Work: http://www.digi-frame.com/
>> Tel (914) 937-4090 9am-6:30pm M-F ET
>> Personal: http://www.larwe.com/ http://www.zws.com/
>> 
>> "Far better it is to dare mighty things, to win glorious 
>> triumphs, even 
>> though checkered by failure, than to rank with those poor spirits who 
>> neither enjoy much nor suffer much, because they live in the 
>> gray twilight 
>> that knows not victory nor defeat."
>> (Theodore Roosevelt)
>> 
>> 

RE: [ECOS] Enable EDB7xxx interrupts

[Trenton D. Adams]

Would eCos be hooking those interrupts for some weird reason?  In fact,
doesn't eCos hook them every time?  After all, from what I understand,
EINT1 and EXTFIQ are the only two interrupts for the EP7211 CPU.  So,
when an interrupt occurs, doesn't the system clear those lines?

> -----Original Message-----
> From: Lewin A.R.W. Edwards [ mailto:larwe@larwe.com ] 
> Sent: Monday, June 25, 2001 10:45 AM
> To: Trenton D. Adams; 'eCos discussion'
> Subject: RE: [ECOS] Enable EDB7xxx interrupts
> 
> 
> 
> >Oops, I forgot to mention that I've set bit 5 in the INTMR1.
> 
> Do you get an IRQ or FIQ when you force the 6700 to issue an 
> interrupt? If 
> you do, but it just doesn't have the right INTSR bits, then 
> maybe someone 
> else is servicing that interrupt and clearing the bit before 
> you're looking 
> at it.
> 
> 
> -- Lewin A.R.W. Edwards
> Embedded Engineer, Digi-Frame Inc.
> Work: http://www.digi-frame.com/
> Tel (914) 937-4090 9am-6:30pm M-F ET
> Personal: http://www.larwe.com/ http://www.zws.com/
> 
> "Far better it is to dare mighty things, to win glorious 
> triumphs, even 
> though checkered by failure, than to rank with those poor spirits who 
> neither enjoy much nor suffer much, because they live in the 
> gray twilight 
> that knows not victory nor defeat."
> (Theodore Roosevelt)
> 
> 

RE: [ECOS] Enable EDB7xxx interrupts

[Lewin A.R.W. Edwards]

>Oops, I forgot to mention that I've set bit 5 in the INTMR1.

Do you get an IRQ or FIQ when you force the 6700 to issue an interrupt? If 
you do, but it just doesn't have the right INTSR bits, then maybe someone 
else is servicing that interrupt and clearing the bit before you're looking 
at it.


-- Lewin A.R.W. Edwards
Embedded Engineer, Digi-Frame Inc.
Work: http://www.digi-frame.com/
Tel (914) 937-4090 9am-6:30pm M-F ET
Personal: http://www.larwe.com/ http://www.zws.com/

"Far better it is to dare mighty things, to win glorious triumphs, even 
though checkered by failure, than to rank with those poor spirits who 
neither enjoy much nor suffer much, because they live in the gray twilight 
that knows not victory nor defeat."
(Theodore Roosevelt)

RE: [ECOS] Enable EDB7xxx interrupts

[Trenton D. Adams]

Oops, I forgot to mention that I've set bit 5 in the INTMR1.

> -----Original Message-----
> From: Lewin A.R.W. Edwards [ mailto:larwe@larwe.com ] 
> Sent: Monday, June 25, 2001 10:40 AM
> To: Trenton D. Adams; 'eCos discussion'
> Subject: Re: [ECOS] Enable EDB7xxx interrupts
> 
> 
> 
> >I'm testing interrupts with the CL-PS6700 PCMCIA controller 
> and I need 
> >to know something about the EDB7xxx interrupts.  Is there 
> something I 
> >have to do enable interrupts on the EDB7xxx?  I'm asking 
> because I can 
> >get the interrupts on the CL-PS6700 to activate, but the 
> corresponding 
> >bits for EINT1 or EXTFIQ in INTSR1 are not activated with it.
> 
> Check the interrupt mask registers.
> 
> 
> -- Lewin A.R.W. Edwards
> Embedded Engineer, Digi-Frame Inc.
> Work: http://www.digi-frame.com/
> Tel (914) 937-4090 9am-6:30pm M-F ET
> Personal: http://www.larwe.com/ http://www.zws.com/
> 
> "Far better it is to dare mighty things, to win glorious 
> triumphs, even 
> though checkered by failure, than to rank with those poor spirits who 
> neither enjoy much nor suffer much, because they live in the 
> gray twilight 
> that knows not victory nor defeat."
> (Theodore Roosevelt)
> 
> 

Re: [ECOS] Enable EDB7xxx interrupts

[Lewin A.R.W. Edwards]

>I'm testing interrupts with the CL-PS6700 PCMCIA controller and I need
>to know something about the EDB7xxx interrupts.  Is there something I
>have to do enable interrupts on the EDB7xxx?  I'm asking because I can
>get the interrupts on the CL-PS6700 to activate, but the corresponding
>bits for EINT1 or EXTFIQ in INTSR1 are not activated with it.

Check the interrupt mask registers.


-- Lewin A.R.W. Edwards
Embedded Engineer, Digi-Frame Inc.
Work: http://www.digi-frame.com/
Tel (914) 937-4090 9am-6:30pm M-F ET
Personal: http://www.larwe.com/ http://www.zws.com/

"Far better it is to dare mighty things, to win glorious triumphs, even 
though checkered by failure, than to rank with those poor spirits who 
neither enjoy much nor suffer much, because they live in the gray twilight 
that knows not victory nor defeat."
(Theodore Roosevelt)

[ECOS] Enable EDB7xxx interrupts

[Trenton D. Adams]

I'm testing interrupts with the CL-PS6700 PCMCIA controller and I need
to know something about the EDB7xxx interrupts.  Is there something I
have to do enable interrupts on the EDB7xxx?  I'm asking because I can
get the interrupts on the CL-PS6700 to activate, but the corresponding
bits for EINT1 or EXTFIQ in INTSR1 are not activated with it.