Lpc2000

Thanks for passing this along.  It may be the root of a problem that's been 
bothering me for some time.  There are times when I start to think Philips 
is actually trying to kill this microcontroller.

At 10:00 PM 11/18/04 +0000, you wrote:
>You MUST enable the FIFO (by setting U0FCR:0) - See Description of
>that bit in Table 66 of LPC2106 User Manual.

Good heavens, that's well hidden.  I don't think very many others noticed 
that.  Most of the example uart code doesn't use the FIFOs.  It's certainly 
contradictory to any other 16550 implementation.

I'll have to go back to my paper copy and see if that was in earlier revs 
of the UM.  Sheesh!



>Since other sections of the manual imply that you can run without
>this bit set, I asked Philips about it.  One of the apps engineers
>told me it was OK to run without the FIFO enabled.  Hwever, another
>apps engineer told me that the original intention was to allow
>operation without the FIFO, but they discovered some bugs operating
>in that mode, so they redefined the product to not allow that mode of
>operation.
>
>So, as far as I know, if the FIFO is not enabled - all bets are off.
>
>Robert: Are you also operating without the FIFO when you have your
>problems?

Nope, the program I've got that ran into the problem has the FIFO 
enabled.  Hmm that went through a set of changes I may have added the FIFO 
after changing the IIR read. I'll have to go back and recheck to see if it 
works properly with the FIFO enabled now.


>As to whether the problem operating without the FIFO (which Philips
>has long been aware of) might be caused by a similar race condition
>as the timer interrupt problem - interesting question.  When I
>discussed the FIFO issue with them, the timer problem had not yet
>been discovered.  Now that Philips has an understanding of the timer
>interrupt problem (and has reportedly implemented a fix on some new
>chips in development), their circuit designers should be able to
>easily determine if a similar problem exists here.

Well, one race condition is an oversight.  Two make me wonder if it was 
something they didn't check for properly.  And since both the SPI and timer 
have documented race conditions (and given the apparent long lead time 
between the discovery of an issue and letting us know about it) ....


>In fact, there are a number of other registers which also get written
>to by both the core and peripheral hardware.  Has Philips analyzed
>which of these are subject to the same problem with simultaneoues
>access?
>
>Philips: How about letting us know what's going on!

Very good question.  Having errata come out in dribs and drabs is very 
frustrating.

I'll get to this shortly, I hope,  and I will report back (after restoring 
IIR multiple read with FIFO's enabled and performing a test).


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