Lpc2000

Jaya,

Many thanks for your detailed explanation: things are becoming much 
clearer.

I apreciate that what you're presenting is "work-in-progress" and 
anything I say at this stage may be invalidated by subsequent 
information you provide, but based on the information you've 
provided, I'd have a couple of comments and questions.

The main main comment I'd make is that far from invalidating 
statements made by Philips, the empirical evidence you present 
actually re-inforces what they'e stated. The processor and VIC 
behave exactly as they have been documented; it's not clear how 
anything in the User Manual, App Notes or VIC documentation is in 
any way undermined or invalidated by the tests you've carried out.

Unfortunately, you have also yet to provide information on how these 
spurious interrupts may be prevented (e.g. how do you stop the UART 
operating as it was designed to?), nor are there are any details on 
why simple work-arounds like those presented in 
http://groups.yahoo.com/group/lpc2000/message/14342 are either 
incorrect or invalid.

As a final comment, I think it would be of more general use if you 
added information on why you believe spurious interrupts are such a 
major problem and the specific problems you see with other 
solutions, rathar than continuing to focus on whether it's a Philips 
or ARM issue.

I've added a couple of more detailed comments to your post below.

With best wishes

Brendan

--- In lpc2000@yahoogroups.com, Jayasooriah <jayasooriah@...> wrote:
>
> Hello,
> 
> Arising out of requests from a number of people, I have documented 
the root 
> cause of spurious interrupts on LPC based on my experiments with 
LPC2292 as 
> I see it.  You can find this document (in progress) at:
> 
>    http://www.cse.unsw.edu.au/~jayas/esdk/lpc2/spurious-irq.html
> 
> The root cause of these spurious interrupts does not lie in the 
interaction 
> of the ARM core with VIC as claimed by Philips.  Hence it is 
unlikely that 
> other ARM cores with VIC will suffer the these spurious interrupt 
problems.

It's not clear how any of the empirical evidence you present backs 
this statement: can you elaborate?

> 
> The root cause of spurious interrupts generated when VICINTCLEAR 
is used to 
> disable interrupts is the internal priority logic of the VIC as 
implemented 
> on the LPCs.

What your asking us to believe here is that having gone to the 
trouble and cost of licensing the VIC design from ARM, Phlips for 
some reason chose to change that design, with the effect of 
introducing some form of unexpected behaviour. Possible, I suppose, 
though most would see this is somewhat unlikely.

> 
> The root cause of spurious interrupts generated through 
interaction of RDA 
> and CTI for UART0/1 is the internal logic within these peripheral 
devices.
> 

This simply restates in another form information already provided in 
the User Manual and App note: the state of CTI can change as the VIC 
is responding to the interrupt. Nothing new here.

> I have not got around to documenting hazards arising out of work-
arounds as 
> suggested in AN10414.
> 
> However, given the framework I have described for creating these 
spurious 
> interrupts in a deterministic way, it is not hard for anyone to 
extend the 
> experiments to find out exactly what happens and work out 
strategies of 
> preventing them.
> 

It's useful I'm sure, though it's not clear where your work is going.

> For starters, I would not recommend anyone disable interrupts 
using the 
> VIC.  Use the F and I bits in CPSR instead.  They are there for 
this 
> purpose and they do not generate spurious interrupts.
> 

I'd agree here, though possibly for different reasons. We have coded 
very brief functions to disable and re-enable interrupts using the 
CPSR flags: these work on any ARM system (including those without 
VICs). However, there are cases when you need to disable interrupts 
from one peripheral, rathar than globally. In that case, it's 
usually best to disable them in the peripheral itself, rathar than 
the VIC.

> Kind regards,
> 
> Jaya
>