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

--- In lpc2000@yahoogroups.com, "brendanmurphy37" 
<brendan.murphy@i...> wrote:
>
> 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).

Or route the signal to a GPIO pin in addition to the EINT pin.

Or use a timer capture pin, and let it generate a capture interrupt 
on both rising and falling edges of the pin, and keep track of the 
pin value in the interrupt handler. (And be aware of the TIMER.1 
errata.)
  
Karl Olsen

Good suggestions.

Routing to a 2nd pin is probably safest. Problem is we're short on 
pins and also would prefer not to re-spin the board at this late 
stage of our development.

On the 2nd suggetsion, I'd be curious to know if the capture pins 
behave the same as the EINT pins (i.e. you can't read their state 
when configured as a capture pin). My guess (and it's only a guess) 
is that it's likely they would.

Best option is probably to use one of the later devices: aparently on 
these the IOPIN register always reflects the actual pin state.

Brendan

--- In lpc2000@yahoogroups.com, "Karl Olsen" <kro@p...> wrote:
>
> --- In lpc2000@yahoogroups.com, "brendanmurphy37" 
> <brendan.murphy@i...> wrote:
> >
> > 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).

> 
> Or route the signal to a GPIO pin in addition to the EINT pin.
> 
> Or use a timer capture pin, and let it generate a capture interrupt 
> on both rising and falling edges of the pin, and keep track of the 
> pin value in the interrupt handler. (And be aware of the TIMER.1 
> errata.)
>   
> Karl Olsen
>

Hello Brendan Murphy,

On our LPC2138-based design, we noticed too that you cannot use a pin
as EINT and GPIO at the same time, and we used the same work-around:
reconfigure the pin to GPIO after detecting the interrupt.

So far, only one board (out of approximately 20) gave the "spurious
interrupt" that you described, and on this board, the spurious
interrupt goes away when we bend the board (very) slightly. Our
hypothesis was that there is a problem in the PCB, and that perhaps
some ground or power wire is floating.

In your message, you mention that the spurious interrupt occurs
"depending on the mode of the interrupt and the state of the pin". I
am interested in the conditions that the interrupt does and does not
appear.

If your hypothesis (that this spurious interrupt is a feature/property
of the LPC2000 series) is correct, then I will have to consider
implementing a work-around in the firmware. But if our hypothesis
(that this is due to a broken PCB or a design error in the PCB) is
correct, you may want to review your PCB.

Kind regards,
Thiadmer Riemersma

Thiadmer,

Thanks for the suggestion. However, we've determined that it's 
definitely a "feature" of the LPC213x. The reason I phrased it as I 
did was that we didn't investigate all possible variations. However, 
the following definitely produces a "spurious" interrupt:

- place a high value on the P0.20 pin (and don't change it)
- configure EINT3 on P0.20 to generate an interrupt on a rising edge
- change the pin from EINT3 to GPIO
- read the pin value
- change it back to EINT3
- result: unexpected interrupt

There are many possible work-arounds for this: a simple and obvious 
one is just to take the interrupt (knowing it's spurious).

The points I was warning against are that:

- you can't read a pin value on the LPC213x without changing it to 
GPIO

- it can give an unexpected interrupt (unexpected in this case as no 
rising edge has happened on the pin and yet you get an interrupt)

As I said, we haven't investigated all possible combinations (e.g. 
rising/falling edge; edge/level; high/low value on i/p pin). There 
may or may not be other combinations where you see this.

It sounds like you have a separate problem with your PCB. 

Regards
Brendan

--- In lpc2000@yahoogroups.com, "Thiadmer Riemersma (ITB 
CompuPhase)" <go@c...> wrote:
>
> Hello Brendan Murphy,
> 
> On our LPC2138-based design, we noticed too that you cannot use a 
pin
> as EINT and GPIO at the same time, and we used the same work-
around:
> reconfigure the pin to GPIO after detecting the interrupt.
> 
> So far, only one board (out of approximately 20) gave the "spurious
> interrupt" that you described, and on this board, the spurious
> interrupt goes away when we bend the board (very) slightly. Our
> hypothesis was that there is a problem in the PCB, and that perhaps
> some ground or power wire is floating.
> 
> In your message, you mention that the spurious interrupt occurs
> "depending on the mode of the interrupt and the state of the pin". 
I
> am interested in the conditions that the interrupt does and does 
not
> appear.
> 
> If your hypothesis (that this spurious interrupt is a 
feature/property

> of the LPC2000 series) is correct, then I will have to consider
> implementing a work-around in the firmware. But if our hypothesis
> (that this is due to a broken PCB or a design error in the PCB) is
> correct, you may want to review your PCB.
> 
> Kind regards,
> Thiadmer Riemersma
>

Hello Brendan,

> It sounds like you have a separate problem with your PCB. 

We DO have a problem with one particular board (we have tested only 20
so far, but this fault is only present on one of these).

However, we doubt that this is an unrelated problem. To explain it, I
need a little detour.

In normal operation, the board gets an interrupt every 25 ms
(roughly). This is an interrupt on the rising flank of a "data
request" line of an external chip. On an interrupt, the ISR toggles an
semaphore so that a high priority task will run. This high priority
task must push data over a serial link until the external chip drops
the data request line.

There is no way of knowing beforehand how many bytes to push,
monitoring the data request line is the only option. Which is why the
task toggles the pin from EINT0 to GPIO. When it is done pushing the
data, it toggles it back.

What we experienced on the one faulthy board were watchdog resets. We
traced this back to the high priority task running continously (the
watchdog is "tickled" by a lower priority task). We traced that back
to the ISR getting a flank interrupt even though the data request line
was low. This was our spurious interrupt. Our hypothesis is that
toggling GPIO to EINT0 caused this interrupt.

So your forum message rang a bell.

That said,... 

1) such a failure could hardly be missed on the other 19 boards that
we tested: watchdog resets are quite noticible;

2) when we exerted pressure on the board (bending the PCB slightly)
the board functioned normally: the spurious interrupts went away (and
no other disfunctionality was detected).

We will still keep an eye on this "spurious interrupt" issue. For
instance, I am implementing a test in the firmware that checks
specifically for this issue. But for the moment, we are unconvinced
that spurious interrupts (under these conditions) are "by design" for
the LPC2000 series.

Kind regards,
Thiadmer

Hello everyone,

On 8 december 2005, Brendan Murphy posted a report where switching a
pin from GPIO to EINT (external interrupt) caused an edge-triggered
interrupt (message http://groups.yahoo.com/group/lpc2000/message/11212).

I replied to that message saying that we encountered precisely that
error on a single PCB out of 20 that we tested. Our hypothesis was
that the particular PCB had some kind of defect. This hypothesis was
based on the fact that the spurious interrupts _disappeared_ when
slightly bending the PCB.

We recently encountered a second board with exactly the same problem.
Here, too, pressure on the board influenced the occurrence of spurious
interrupts. Also similar was that the "pressure point" was on the
processor. In a related test, we heated the processor. This also
influenced the occurrence of the spurious interrupts.

We replaced the processor on the board (an LPC2138) by another one. No
more spurious interrupts occurred.

We are wondering whether this issue may perhaps be caused by the
processors not being handled correctly during manufacturing (perhaps
there was no baking before reflow soldering).

We have also tried to implement simple work-arounds, such as disabling
the external interrupt in the VIC before switching the pin from GPIO
to EINT, or clearing the interrupt in the VIC immediately after the
switch. Both these attempts failed.

I am reporting this to retract my earlier statement that the probable
cause is in the PCB or in the PCB design. In addition, I am curious
whether anyone can think of a work-around or fix for this issue.

Kind regards,
Thiadmer Riemersma

Thiadmer,

It's a bit difficult to offer any kind of specific advice, based on 
what you say.

The problem I described is quite deterministic: that is, if you 
configure the device in a certain way, it always responds in exactly 
the same way to the same sequence of actions. 

From what you say, your problem seems to be intermittent, which is of 
course the worst kind of problem to deal with.

It certainly sounds suspicious that it may be hardware related by the 
symptoms you describe. However, it doesn't prove it. As a general 
strategy, I'd advise trying to get the system to behave consistently, 
and then look at differences from a system that works (consistently) 
and one that doesn't. You could try for example reducing the software 
as much as possible (e.g. a total of 20 or 30 lines of code), and see 
can you get it to work consistently, regardless of the board it's 
running on). It was this approach that enabled us to identify the 
issue I reported.

By the way, I assume you've discounted simple issues such as 
intermittant contacts at the processor pins? Applying pressure or 
heat is a good way of turning an intermittant contact (that may well 
be generating interrupts as the pin's state changes) into a good one, 
where the pin is held to its correct state by whatever it's connected 
to. A good way of testing this is to run the relevant software on a 
known good board (e.g. a bought-in, commercially available board).

I know this is of limited help, and probably nothing more than you've 
already done: it would be interesting to get feedback on how you 
progress.

Regards
Brendan

--- In lpc2000@yahoogroups.com, "Thiadmer Riemersma (ITB CompuPhase)" 
<go@...> wrote:
>
> Hello everyone,
> 
> On 8 december 2005, Brendan Murphy posted a report where switching a
> pin from GPIO to EINT (external interrupt) caused an edge-triggered
> interrupt (message 
http://groups.yahoo.com/group/lpc2000/message/11212).
> 
> I replied to that message saying that we encountered precisely that
> error on a single PCB out of 20 that we tested. Our hypothesis was
> that the particular PCB had some kind of defect. This hypothesis was
> based on the fact that the spurious interrupts _disappeared_ when
> slightly bending the PCB.
> 
> We recently encountered a second board with exactly the same 
problem.
> Here, too, pressure on the board influenced the occurrence of 
spurious
> interrupts. Also similar was that the "pressure point" was on the
> processor. In a related test, we heated the processor. This also
> influenced the occurrence of the spurious interrupts.
> 
> We replaced the processor on the board (an LPC2138) by another one. 
No
> more spurious interrupts occurred.
> 
> We are wondering whether this issue may perhaps be caused by the
> processors not being handled correctly during manufacturing (perhaps
> there was no baking before reflow soldering).
> 
> We have also tried to implement simple work-arounds, such as 
disabling
> the external interrupt in the VIC before switching the pin from GPIO
> to EINT, or clearing the interrupt in the VIC immediately after the
> switch. Both these attempts failed.
> 
> I am reporting this to retract my earlier statement that the 
probable

> cause is in the PCB or in the PCB design. In addition, I am curious
> whether anyone can think of a work-around or fix for this issue.
> 
> Kind regards,
> Thiadmer Riemersma
>

----- Original Message ----- 

From: "Thiadmer Riemersma (ITB CompuPhase)" <go@...>
To: <lpc2000@yahoogroups.com>
Sent: Wednesday, March 22, 2006 9:45 AM
Subject: [lpc2000] CONFIRMED: WARNING: problem reading state of external 
interrupt lines.


> Hello everyone,
>
> On 8 december 2005, Brendan Murphy posted a report where switching a
> pin from GPIO to EINT (external interrupt) caused an edge-triggered
> interrupt (message http://groups.yahoo.com/group/lpc2000/message/11212).
>
> I replied to that message saying that we encountered precisely that
> error on a single PCB out of 20 that we tested. Our hypothesis was
> that the particular PCB had some kind of defect. This hypothesis was
> based on the fact that the spurious interrupts _disappeared_ when
> slightly bending the PCB.
>
> We recently encountered a second board with exactly the same problem.
> Here, too, pressure on the board influenced the occurrence of spurious
> interrupts. Also similar was that the "pressure point" was on the
> processor. In a related test, we heated the processor. This also
> influenced the occurrence of the spurious interrupts.
>
> We replaced the processor on the board (an LPC2138) by another one. No
> more spurious interrupts occurred.
>
> We are wondering whether this issue may perhaps be caused by the
> processors not being handled correctly during manufacturing (perhaps
> there was no baking before reflow soldering).
>
> We have also tried to implement simple work-arounds, such as disabling
> the external interrupt in the VIC before switching the pin from GPIO
> to EINT, or clearing the interrupt in the VIC immediately after the
> switch. Both these attempts failed.
>
> I am reporting this to retract my earlier statement that the probable
> cause is in the PCB or in the PCB design. In addition, I am curious
> whether anyone can think of a work-around or fix for this issue.

Moisture getting into the package could have caused the problem, if the 
chips were removed from the protective packaging and left for some time 
before assembly. Baking before reflow soldering is only required if the 
precautions have not been observed.

High-reliability systems are often 'burned-in' - run for some time at a high 
temperature - which shows up faults like that.

Leon

Thiadmer Riemersma (ITB CompuPhase) wrote:

>Hello everyone,
>
>On 8 december 2005, Brendan Murphy posted a report where switching a
>pin from GPIO to EINT (external interrupt) caused an edge-triggered
>interrupt (message http://groups.yahoo.com/group/lpc2000/message/11212).
>
>I replied to that message saying that we encountered precisely that
>error on a single PCB out of 20 that we tested. Our hypothesis was
>that the particular PCB had some kind of defect. This hypothesis was
>based on the fact that the spurious interrupts _disappeared_ when
>slightly bending the PCB.
>
>We recently encountered a second board with exactly the same problem.
>Here, too, pressure on the board influenced the occurrence of spurious
>interrupts. Also similar was that the "pressure point" was on the
>processor. In a related test, we heated the processor. This also
>influenced the occurrence of the spurious interrupts.
>
>We replaced the processor on the board (an LPC2138) by another one. No
>more spurious interrupts occurred.
>
>We are wondering whether this issue may perhaps be caused by the
>processors not being handled correctly during manufacturing (perhaps
>there was no baking before reflow soldering).
>
>  
>
Well, it is tough to assume that everything else was okay.  In another 
posting I made this morning was about how clean the finished board was 
and your comment that replacing the chip brings it to mind.  I had a 
manufacturer call me in to try to find a problem with a group of boards 
that they could not get working.  These had been assembled in Asia and 
the majority of the lot worked, all but these few boards.

Looking at these boards under a 20X microscope, I discovered solder 
debris which had not been properly cleaned from the board.  There were 
tiny groups of solder balls + unmelted paste around many of the pins.  
The cleaning process had removed the majority of the debris around the 
pins but failed to adequately remove it from "underneath".  The debris 
was tucked up on the "inside" of the pins where it was difficult to see.

Several of the boards worked when I just reheated the pins with a 
soldering iron and reflowed the debris.

TomW

-- 
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net, http://cyberiansoftware.com
"Windows? No thanks, I have work to do..."
----------------------------------------------------

Hello Brandon,

Thank you for your message. Indeed there is a lot information still
lacking in what I described.

Before replacing the LPC2138, we resoldered the leads of the old
processors (all of them). The pin connections were also visually
inspected (with a 10x magnifier).

I do not recall whether the spurious interrupt was "deterministic" on
the second board (the one that is now repaired). However, on our first
board where this occurred, the issue "appeared" deterministic. In
fact, on the first board we discovered the problem because we
experienced task starvation. This, in turn, was caused by an interrupt
being generated immediately after switching a GPIO pin 0.16 to EINT0.
We are switching the pin between GPIO and EINT for the same reason
(basically) as the one described in your original message.

I said that it "appeared" deterministic, because adding pressure on
this board made the spurious interrupts less frequent or made them
disappear alltogether. However, without external pressure, the low
priority task could remain starved for a very, very long time.

Since then, I have adapted my firmware to detect this particular
spurious interrupt issue, and cause a reset with a diagnostic message
if it appears (even only once). For the second board, I do therefore
not know if the spurious interrupt was deterministically appearing
after each switch from GPIO to EINT, or just (say) 5 out of 10 times.

Kind regards,
Thiadmer

Hello Leon,

We designed the board and did a few prototypes in-house, but series
manufacturing was done by a specialized company. So I do not really
know whether precautions were observed.

> High-reliability systems are often 'burned-in' - run for some time at
> a high temperature - which shows up faults like that.

Funnily, this particular problem went away at high temperature.

Kind regards,
Thiadmer

--- In lpc2000@yahoogroups.com, "Thiadmer Riemersma (ITB CompuPhase)"
<go@...> wrote:
>
> Hello Leon,
> 
> We designed the board and did a few prototypes in-house, but series
> manufacturing was done by a specialized company. So I do not really
> know whether precautions were observed.
> 
> > High-reliability systems are often 'burned-in' - run for some time at
> > a high temperature - which shows up faults like that.
> 
> Funnily, this particular problem went away at high temperature.
> 
> Kind regards,
> Thiadmer
>

Whenever I have run across a situation where touching the circuit
could make a change, it was because I had left pins floating.  I would
start with the schematic and look for pins that float.

Richard

Hello Tom,

On both boards, we resoldered all pins of the existing LPC2138 before
we took the step of replacing an LPC2138 on one of the boards.

The curious (or suspicious) thing is:
- both boards have precisely the same problem
- so far, no board failed in some other way
- the problem is almost identical to the one in message 11212

But, yes, you are right. I have been jumping to conclusions.

Kind regards,
Thiadmer Riemersma

Hello Richard,

A floating pin (whether "by design" or by a bad soldering) was our
first thought too. Note that so far we have tested more than 30 boards
and so far only 2 cause these spurious interrupts.

Kind regards,
Thiadmer Riemersma

At 08:53 AM 3/23/06 +0000, Thiadmer Riemersma (ITB CompuPhase) wrote:
>A floating pin (whether "by design" or by a bad soldering) was our
>first thought too. Note that so far we have tested more than 30 boards
>and so far only 2 cause these spurious interrupts.

Something to consider is cracked capacitors.  Stress on the board (perhaps 
from bad panel separation procedures) can crack ceramic surface mount 
devices particularly if they are close to the stress origin.  I ran into a 
bunch of these once and the key to finding them initially was to breathe on 
them.  The extra humidity was all the was needed to trigger the observed 
behaviour on most.  The cracks tended not to be visible to the naked eye 
but when the different layers of the caps shorted bad things 
happened.  That's a subtle enough effect to be overlooked unless you 
specifically hunt for it.

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,   be 
they legal, genetic, or physical.  If you don't believe me, try to chew a 
radio signal. "  -- Kelvin Throop, III
http://www.aeolusdevelopment.com/

Hello Robert,

> Something to consider is cracked capacitors.

Thanks for the tip.

Another hypothesis that I want to investigate is whether we may be
operating the LPC2138 under "off spec" conditions. Most chips will
still run (slightly) off spec, but some won't.

This would explain why resoldering all of the pins of the LPC2138 did
not help, but replacing it by another made the spurious interrupts go
away.

It is just a hypothesis.

Kind regards,
Thiadmer