Lpc2000

Hi,

We've just discovered come characteristics of the external interrupt 
lines on the LPC213x parts (probably other parts as well, though not 
on the newer ones like the LPC214x), which I think is worth sharing 
with people here.

Our basic requirement is to have an external signal generate an 
interrupt to signal a once-off event. We configured P0.20 as EINT3 to 
generate an edge-triggered interrupt on a falling edge. This works 
just fine. The problem is that we also want to be able to read the 
state of the pin at any time. 

The first point to note is that you can't read the state of a pin 
when it's configured as an external interrupt: we read it 
consistently as 0, even though it is normally held high. This is 
indicated in a statement in the User Manual, in the section on the 
Pin Connect Block ("Selection of a single function on a port pin 
completely excludes all other functions otherwise available on the 
same pin"), though we only spotted this after we'd spent a while on 
figuring out what was wrong (maybe an additional statement in the 
External Interrupt description would help here?).

Anyway, our work around was to temporarily reconfigure the pin as 
GPIO, read its value, and reconfigure back as EINT3 whenever we 
wanted to read it. This works just fine.

However, it introduced problem number two: depending on the mode of 
the interrupt and the state of the pin, the action of changing it to 
GPIO and back again can itself generate a (spurious) interrupt. That 
is, you can get an interrupt even though there's been no transition 
on the actual pin. We then changed the function to do the read, so 
that it disabled interrupts, switched the pin to GPIO, read the 
value, switched to EINT3, reset the pending interrupt generated and 
re-enabled interrupts. Again, this works, if a bit long-winded.

However, on thinking about it, what would happen if a real state 
transition happened when all this was going on? My strong suspicion 
is that there's potential for a race-condition to exist, even if only 
for a short time.

Because of pressure of time, we've had to rethink how we're handling 
this, and for now, we're not using interrupts for the function any 
more: we now poll the pin, leaving it as a GPIO input. I'm sure there 
is some other work around to this issue (it's probably preferable to 
use level sensitive interrupts in any case).

My main reason for mentioning this here is to make others aware of 
the issue, and hopefully save some time.
Brendan Murphy