Lpc2000

c.barbaro wrote:

>Hi.
>
>I had no time to enter in depth regarding your problem but when
>I read your phrase: 
>"I cannot explain why the SPIF bit is missed however. That appears to
>be a race condition in the silicon where a co-incidence of reading
>from the SPI status register vs. the AHB writing into the status
>register... ???"
>
>I remembered the errata document for the LPC2138 processor where
>similar problems are documented for both the timer and the uart.
>If you write a register via software at the same time that hardware
>want to write the same register, the hardware write is not performed.
>For timer this occurs when you are clearing a timer match interrupt
>(ex. interrupt on match0) and another match occurs at the same time
>(ex. match1): the match interrupt is never generated.
>For uart this occurs if you read the IIR register, clearing the THRE
>bit and at the same time the transmitter register become empty so that
>hardware want to set the THRE bit: the bit is never set, the interrupt
>is never generated.
>
>The consequence is: if timers and uarts have these problems, why not
>the SPI?
>Have you checked the ERRATA for the LPC2106?
>
>  
>
Yes, and I do think that you are correct.   It may be an inherent design 
failure of the AHB.  The discussion in apnote AN10414 strongly suggests 
to me that there are such flaws in the hardware mechanisms between the 
ARM core and the peripheral bus.

>Anyway, I agree that "there is absolutely no information nor timing
>diagrams detailing the relationship of: the SPIF bit, shift clock, and
>interrupts.  Again, the Philips docs are sadly lacking in detail on
>critical issues (see discussion in this group messages regarding the
>ADC leakage)."
>
>I know of my colleague working with SPI on LPC2138 and finding a lot
>of problems.
>I think that Philips failed create a microcontroller with "robust"
>peripherals to be used in industrial environment.
>Unfortunately (or fortunately??) it is very cheap, and this attract
>the marketing peoples (the programmers will patch the code in one mode
>or another...)
>
>  
>
Well, I don't think that we can really fault Philips for some of this.  
IMO, ARM Inc. itself shares some of this blame.  I see that ARM Inc. is 
the one pushing / offering the AHB peripheral bus.  I suspect that 
Philips collected the LPC2000 series together, Ala Carte, from a menu of 
IP available from ARM.  So, design flaws in the AHB are being 
promulgated into customers' silicon.

The documentation issue is a real black-eye though.  I've been designing 
systems for a long time now and the documentation for the LPC2000 series 
is atrocious!  The documentation is okay for writing software, but the 
hardware documentation is simply terrible!

For example: refer to Philips document UM10120 "LPC213x User Manual".  
Look at Section 12.4.5 "SPI Interrupt register (S0SPINT - 
0xE002 001C)".  The only mention of the relationship of the SPI data 
register shifting to an empty state and the occurance of the interrupt is:

"SPI interrupt flag. Set by the SPI interface to generate an interrupt. 
Cleared by writing a 1 to this bit.
Note: this bit will be set once when SPIE = 1 and at least one of SPIF 
and WCOL bits is 1. However, only when the SPI Interrupt bit is set and 
SPI0 Interrupt is enabled in the VIC, SPI based interrupt can be 
processed by interrupt handling software."

That is it!  No timing diagram or flow chart to explain the process.  
Just a vague statement that the interrupt bit is used to set an 
interrupt condition.  This is a childish explanation, thoroughly lacking 
in any detail.  Any embedded engineer knows what an interrupt does, we 
need to know WHEN you set the interrupt, what is the relationship of the 
SPIF + SPINT?

1) Which comes first, the SPIF or SPINT?

2) At what clock & edge does the SPIF become asserted?

3) At what clock & edge does SPINT get asserted?

Those are questions that hardware + software engineers need to have 
answered.   Not some silly pablum about what an interrupt is.  The 
documentation is okay as far as identifying where the registers are and 
what bits are used for...  The documentation is littered with these 
omissions.

Another example, what is the characteristic input capacitance of the 
clock circuits?  I have an 18pf crystal, how many picofarads will the 
processor pins represent when calculating the additional load 
capacitance for proper crystal operation?  If the range is, say, from 
3pf..13pf then document that so that we are aware that the loading 
capacitance may have to be altered in production due to silicon 
fabrication differences.

Another example, what is the characteristic input resistance of the ADC 
circuit?  Is that resistance a fixed value or does it change 
significantly during conversion (conversion loading)?

Now, my question is, if this is not the definitive document we should be 
looking at for this information: WHERE IS THE "REAL" DOCUMENTATION???

I just get very annoyed at having to spend days trying to 'get it right' 
due to the lack of adequate documentation.  I am not a hobbyist, I do 
this for a living.


TomW

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