Yahoo Groups archive

Lpc2000

Index last updated: 2026-04-28 23:31 UTC

Message

Re: CONFIRMED: WARNING: problem reading state of external interrupt lines.

2006-03-22 by brendanmurphy37

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
>

Attachments

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.