|
You MUST enable the FIFO (by setting U0FCR:0) - See Description of that bit in Table 66 of LPC2106 User Manual. 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? 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. 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! --- In , "Leighton Rowe" <leightonsrowe@y...> wrote: > > > >Should I enable the FIFOs (write 1 to U0FCR) before running the > > >interrupts? I seem to be getting by without this up until this > point. > > > > I don't see why that would eliminate the problem. Worse it might > hide it > > so that it showed up later under less benign conditions. > > > > Good news...I got communication running alot better after enabling > FIFOs (U0FCR = 1) at startup. So far, no Rx & Tx glitches yet. Try > doing the same to see what happens. > > For now the LSR mystery is worth forgetting. > Leighton |
|
|
Questions on the UART Interface
Started by ●November 17, 2004
Reply by ●November 18, 20042004-11-18
Reply by ●November 18, 20042004-11-18
|
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 |
|
|
Reply by ●November 19, 20042004-11-19
|
It seems to me that given the problem with the UART interrupt register, it is more likely than not that the same problem exists with other registers. Rather than "one race condition is an oversight," I would assume similar circuit design would be used in all parts of the chip. In any event, this is something which should be very easy for Philips' circuit designers to answer. As engineers, we can all appreciate that bugs sometimes get through. It's the lack of information, once the bug is discovered, that's frustrating. --- In , Robert Adsett <subscriptions@a...> wrote: > > 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. > |
