Jaya:

sorry, i apparently failed to make my points clear a few times.

first: the reasons i said that i could have stopped reading earlier if
i knew earlier that your code was polling was simply that i wasn't
using the LPC devices with a polling UART, and therefore i simply
wouldn't care if there were problems encountered when using polling as
you were. that's all. you don't need to defend yourself for polling.
it matters not if you chose to poll or if your client wanted you to.
you also don't need to explain that you obviously need to read the
LSR sometime, or you would never know what was going on. i'm just not
surprised to hear that the LPC2xxx might have "race" problems when
reading the LSR "constantly" (as you put it). it would not be the
first time i have experienced a microcontroller UART exhibiting this
problem, and the more rapidly one reads the LSR, the more that small
probability adds up, until it becomes quite likely that you might
"lose" a particular status bit in the ether. in any case, whatever
the reason for your architecture, the point was that i now know you
meant to say that the problem you were seeing was only affecting your
polled code, rather than an interrupt-driven driver, which was all i
cared about when i started reading this thread.

second: while i agree that my words support the obvious fact that long
inter-word gaps can be accepted by a UART receiver, the more important
point was that a UART "frame" is defined as the start bit, a specified
number of data bits, an optional parity bit, and a stop bit. that's
"a frame". extra stop bits are not part of the frame, but are simply
part of that "inter frame gap" to which you referred. you say you
"think it is right" that the LPC expects 2 stop bits "when it is told
to use 2 stop bits". frankly, the reason i took exception to your
framing error notion was not because of what i think is right or wrong
-- UARTs don't particularly care whether i think they are right or
wrong, they simply follow the UART rules. my point was that telling a
UART to "use 2 stop bits" is a command impinging upon the TRANSMITTER
only. no UART receiver that is not flawed by defintion would ever
*require* more than a single stop bit. if you slow down long enough
to think about it -- and you are as "old" as you think -- you would
see why this is inescapable. if the receiver MUST have the same
number of stop bits that the transmitter is sending, then your UART
could never actually insert the "slack" into the bit stream -- that
same slack that is managed automatically by using 1.5 or 2 stop bits
would instead provide no slack at all if the receiver did not declare
a data word received until it had detected the *last* stop bit. it is
the space between the (required) *first* stop bit and the
(unnecessary) *last* stop bit that was used often in the past to
provide data processing time in those days before UARTs were built-in
separate modules with their own rather high-level intelligence. any
UART that does not operate in this fashion is -- demonstrably -- a bad
UART design, and not simply because *i* think so. perhaps this would
make more sense if you simply asked yourself what the point of using
more than one stop bit would be if *both* the transmitter *and* the
receiver were bound by the same requirement? it is just a way of
wasting bandwidth if it works the way you say you expect it to.

now, this has nothing whatever to do with why you are losing *data*
bytes in your situation, but it should explain why you are not getting
framing errors simply because you are not providing the same number of
stop bits in your test-source UART transmitter as you have programmed
your LPC UART transmitter (not receiver) to use. you should certainly
be able to devise a simple experiment to determine if -- under
circumstances where you have found the LPC UART to operate correctly
-- its receiver does, in fact, declare a byte received upon receipt of
the 1st stop bit, or if it waits for the second one (when you have
told the UART to "use 2 stop bits"). it had certainly better be the
former.

finally: the reason for looking at code is not to attack you for not
being an "expert programmer", but for at least two reasons:
a) it is not at all rare, i'm sure you'll agree, for some micros to
have oddities about their architecture which may require what some
might consider "non-standard" coding to work around known issues, and
somewhere out there you might just run into someone who has happened
across such a condition who -- if they saw your code -- might be able
to tell you that you can't do something that you feel you reasonably
should be able to do, and
b) even "expert programmers" can make silly mistakes -- typos they
never notice because they keep reading back what they intended to
write rather than what they actually wrote (a common problem for book
authors, which is why they hire someone else to proof their own work).

i should say that a perfect example of "b)" above is Brendan's recent
comment about a UART receiver mistakenly declaring a valid byte
received if -- after the expected number of data/parity bit times --
it happens to find the Rx line "low" and thereby declares a valid byte
received. now, this was clearly a mis-statement. your response to
Brendan was to declare him essentially an idiot for making a claim so
obviously wrong. i, on the other hand, read this statement within the
context of the rest of his paragraph, and thereby managed to recognize
the point he was obviously trying to make, and simply "auto-corrected"
his use of "low" when he clearly meant "high". see, the paragraph as
a whole was clearly trying to make a point that a UART receiver has no
way of truely knowing if the previous 8 or 9 (onr N) bit times really
constituted a valid byte IF the Rx line is "high" when the UART
receiver is expecting the stop bit to arrive. if the data rate is
twice what it is supposed to be, it is not uncommon for a receiver to
still declare some valid bytes received -- just by luck (bad, in this
case). i did not think he was directly speaking to your particular
situation, but merely making the point that UART receivers are not
foolproof. that's why so many communications protocols layer
higher-level error detection on top of the physical layer framing (and
optional parity) error detection. perhaps Brendan should not have
inserted this comment into your conversation at that precise point,
but it is interesting to note that you immmediately presumed it
demonstrated he didn't know what he was talking about, rather than
that he simply mis-spoke (mis-typed?).

perhaps this is why you are so concerned about providing anyone else a
copy of the code you are using when you encounter a problem? maybe
you are afraid that they will show you the same level of disrespect
that you tend to show others, and will slam you mercilessly for a
simple typo in your code that might be causing your problem --
declaring boldly that it is proof you are incompetent or stupid.
honestly, i don't think either of these labels applies to you, but i
would have to say that for a self-professed "old timer", you seem to
have held on to a lot of fairly juvenile attitudes regarding how to
interact with others on a professional level. frankly, from reading
some of your earlier posts, i thought you were a college student or
recent grad.

in the event, you might well get a few undeserved slams from jerks who
feel they have to denegrate your code in order to inflate their own
ego, but you won't live or die on their nattering. on the other hand,
there might well be someone out there who looks at your code and
notices some simply typo, misplaced bracket, etc. -- or that
recognizes a sequence in your code that is affected by a device
problem for which they have already found a work-around -- that clears
up the issue for you. a fix to a sticky problem, as most "old timers"
would agree, is worth enduring a few digs from the peanut gallery.
and, of course, every "old timer" has surely suffered the indignity of
having that clueless guy from down the hall happen by while you and 3
other "experts" are debugging something and having them notice
immediately that you have used a "+" where you meant to use "-" :-(
it's murphy's law, after all.

in any case, good luck with your LSR problem. i am going to drop off
this thread now, simply because i don't use polling on the LPC UARTs.
i hope that you find a useful solution for your client.

by the way, my definition of an "old timer" is someone who not only
worked with UARTs before they were integrated onto micros, and also
before there were micros, but also before their were specific devices
called "UART"s. :-)

-cordeg
--- In l..., "jayasooriah" wrote:
>
> --- In l..., "garycordelli" wrote:
> > somehow, i never noted that
> > you were not using an interrupt driven UART handler and that you were
> > instead polling the LSR register constantly.
>
> Interrupt driven systems are hard to diagnose, especially when the
> smallest of intrusions changes underlying behavior. Such are embedded
> systems used in real time environment.
>
> I was advised to look into the problem the client had in the
> operational environment. Rather than try debug the client's system, I
> decided to extract the scenario and came up with with code (polled)
> that manifest the problem in a deterministic manner.
>
> Now that the client knows what the underlying mechanism, the client is
> in the best position to work around this, and is able to do this
> without relying on me.
>
> > as it happens, if i knew you were banging on the LSR
> > incessantly, i could have saved myself the trouble of reading this
> > seemingly interminable thread long ago.
>
> I would be inclined to think otherwise. If it can happen it will
> happen, and it probably will when you least expect. Thus
> deterministic experiments are of immense value in working out
> avoidance strategies.
>
> > but most old timers would tell you that your assertion that a missing
> > 2nd stop bit should be declared a "framing error" is mistaken
>
> Not the old timers I talk to. Besides I am an old timer too,
> according to some!
>
> > experiments undertaken in this regard ought to demonstrate that the
> > LPC2xxx processor UARTs are not the only such UART implementation to
> > follow this pattern.
>
> The LPC UART has a number unique features never ever discovered in
> other UARTS, stand alone or embedded.
>
> > UART designed with the behavior you describe
> > would be a poor UART indeed.
>
> I do not make any comment on whether the design is poor or not. I am
> only interested in identifying non-conformant behaviour. If you think
> this makes the UART poor, that is your opinion.
>
> Besides, the LPC expects the second bit to come, and if it does not
> come, it discards the character, but not report a framing error.
>
> This is a verifiable fact.
>
> > the purpose of specifying the number of stop bits is to affect the
> > TRANSMITTER, not the receiver. settings of 1.5 (on some UARTs) or 2
> > stop bits were defined in the old days to provide extra "slack"
> > between serial data words so that the receiving systems could dispense
> > with each received data word without missing the start of the next
> > data word (these were slow days, indeed). the receivers, however,
> > were all designed to accept a data word upon the reception of the
> > first stop bit, and ignored any successive stop bits until they
> > detected the high-to-low transition that represented a new start bit.
>
> The LPC UART does do what you are suggesting it ought to do. I think
> it is right in expecting two stop bits when it is told to use 2 stop
> bits. As I said, the problem is that it seems to detect the framing
> error, but failed to report it.
>
> > the transmitter could send 1, 2, 100, or any number of stop bits
> > without causing an error.
>
> Inter frame gaps can be indefinite in asynchronous communications.
> Minimum inter frame gaps are required and the LPC seems to (rightly)
> expect this. The only problem is that when it does not find what it
> expects, it simply discards the character.
>
> > anyway, now that you have apparently noticed
> > some connection between your handling of the LSR and the problem you
> > are seeing, i trust that you will soon figure out why you are missing
> > those intervening data words.
>
> Interrupt driven or polled, surely you must read the LSR before you
> read RBR. Are you suggesting that interrupt driven code you do not
> have to read LSR.
>
> Note that error bits are cleared only if you read the LSR -- so you
> can lock up if you do not read LSR.
>
> It appears that if you happen to be reading the LSR just as the UART
> detected a framing error, the error is not reported. It can happen
> any time, whether or not you chose to poll.
>
> > this might be a good time to turn to
> > your "last resort", and take a look at the code...
>
> I think you appear overly offended when I say looking at code is the
> last resort.
>
> There are many reasons I look at code only as a last resort. This
> allows me work with clients who are protective or otherwise sensitive
> about exposing their code.
>
> On the other hand, wearing my other hat, I do play the mentor role
> where I code walk through is my starting point.
>
> Given I deal with expert programmers who have been building reliable
> systems for umpteen years, I tend not ask them for their code every
> time they tell me they need assistance to look at a problem.
>
> I look at the problem from a systems perspective. That is the key IMO
> to maintain as an open mind as to the possible causes. Then when the
> suspect cause is identified by experiment, I tell them what I find.
> They fix their code. The problem is resolved.
>
> I tend not to get involved in matters relating to coding errors in
> this forum. When I see see a common pattern to different problem
> reports, then I get interested in the problem. When I nail it down, I
> simply document it as a problem, not a bug or feature, because I do
> not work in the marketing department.
>
> Perhaps you should put your programming skills to discover if the LPC
> UART does report Framing Error, and if so, under what circumstances.
> If you can tell me the scenario, I am happy to verify it myself
> without asking for your code :)
>
> My experiment (that you can run on your system for verification
> purposes) shows that LPC UART on LPC2292 does not report framing
> errors, even they are deliberately introduced. Here in likes the
> departure of LPC's UART from others that I have worked with, both
> embedded and standalone.
>
> Jaya
>
> PS: In relation to your comment on how old my was, well I took
> it from the LPC2292 user manual. If that is not good enough for you,
> sorry I do not think I can do better.
>

Start a New Thread

Jaya:

by the way, just in case it helps you at all, i meant to suggest that
you might want to re-read that LPC2292 User's Manual to differentiate
between what it actually says from what you may have only presumed it
said. it does not seem to state anywhere that receiving 1 stop bit
when it should "expect" 2 is considered to be a framing error. in
fact, on page 147 of the 05/04/2004 version of the manual on Philips'
web site, it merely states that "When the stop bit of a received
character is a logic 0, a framing error occurs." aside from the bad
grammar, you might mote that it says "the stop bit" not "the stop
bit(s)". this is -- or certainly should be -- because only the
*first* stop bit of a *received* character is required. any extra
stop bits -- whether the UART is "told to use" them or not are simply
*optional*. a UART programmed to use 1 stop bit should be able to
receive data from a UART programmed to use 2 stop bits, and vice
versa, because all UART receivers should require only a single stop
bit, while any UART transmitter should send the number of stop bits
they are "told to use".

also, i would add that another comment on that same page demonstrates
that the LPC UART design is -- while perhaps not *really* bad -- not
very *good* either. it says that when it finds the above condition to
exist ("logic 0" when it expects "the stop bit"), it assumes that it
is an "early start bit", and therefore it re-starts reception of a new
data word. they then go on to warn the user that the next character
received might not be good even if there is no framing error on that
character, which of course could be the case by the luck of the
sequence of bits. however, a UART design described thusly makes it
more likely for this next character to be an undetected error, since
they assume this "0" to be a start bit (apparently) without imposing
the necessary "high-to-low" transition upon that "early start bit".
that is, if they are going to re-sync intelligently, they should
accept this erroneous stop bit as an "early start bit" *only* if the
previous bit period was a "high". otherwise, they should assume that
it can't be a true "early start bit" and instead should simply re-sync
putting their finite state machine back in the "looking for a valid
start bit" state, rather than a waiting for first data bit" state.

alas.

again, good luck with this UART.

-cordeg

--- In l..., "garycordelli" wrote:
>
> Jaya:
>
> sorry, i apparently failed to make my points clear a few times.
>
> first: the reasons i said that i could have stopped reading earlier if
> i knew earlier that your code was polling was simply that i wasn't
> using the LPC devices with a polling UART, and therefore i simply
> wouldn't care if there were problems encountered when using polling as
> you were. that's all. you don't need to defend yourself for polling.
> it matters not if you chose to poll or if your client wanted you to.
> you also don't need to explain that you obviously need to read the
> LSR sometime, or you would never know what was going on. i'm just not
> surprised to hear that the LPC2xxx might have "race" problems when
> reading the LSR "constantly" (as you put it). it would not be the
> first time i have experienced a microcontroller UART exhibiting this
> problem, and the more rapidly one reads the LSR, the more that small
> probability adds up, until it becomes quite likely that you might
> "lose" a particular status bit in the ether. in any case, whatever
> the reason for your architecture, the point was that i now know you
> meant to say that the problem you were seeing was only affecting your
> polled code, rather than an interrupt-driven driver, which was all i
> cared about when i started reading this thread.
>
> second: while i agree that my words support the obvious fact that long
> inter-word gaps can be accepted by a UART receiver, the more important
> point was that a UART "frame" is defined as the start bit, a specified
> number of data bits, an optional parity bit, and a stop bit. that's
> "a frame". extra stop bits are not part of the frame, but are simply
> part of that "inter frame gap" to which you referred. you say you
> "think it is right" that the LPC expects 2 stop bits "when it is told
> to use 2 stop bits". frankly, the reason i took exception to your
> framing error notion was not because of what i think is right or wrong
> -- UARTs don't particularly care whether i think they are right or
> wrong, they simply follow the UART rules. my point was that telling a
> UART to "use 2 stop bits" is a command impinging upon the TRANSMITTER
> only. no UART receiver that is not flawed by defintion would ever
> *require* more than a single stop bit. if you slow down long enough
> to think about it -- and you are as "old" as you think -- you would
> see why this is inescapable. if the receiver MUST have the same
> number of stop bits that the transmitter is sending, then your UART
> could never actually insert the "slack" into the bit stream -- that
> same slack that is managed automatically by using 1.5 or 2 stop bits
> would instead provide no slack at all if the receiver did not declare
> a data word received until it had detected the *last* stop bit. it is
> the space between the (required) *first* stop bit and the
> (unnecessary) *last* stop bit that was used often in the past to
> provide data processing time in those days before UARTs were built-in
> separate modules with their own rather high-level intelligence. any
> UART that does not operate in this fashion is -- demonstrably -- a bad
> UART design, and not simply because *i* think so. perhaps this would
> make more sense if you simply asked yourself what the point of using
> more than one stop bit would be if *both* the transmitter *and* the
> receiver were bound by the same requirement? it is just a way of
> wasting bandwidth if it works the way you say you expect it to.
>
> now, this has nothing whatever to do with why you are losing *data*
> bytes in your situation, but it should explain why you are not getting
> framing errors simply because you are not providing the same number of
> stop bits in your test-source UART transmitter as you have programmed
> your LPC UART transmitter (not receiver) to use. you should certainly
> be able to devise a simple experiment to determine if -- under
> circumstances where you have found the LPC UART to operate correctly
> -- its receiver does, in fact, declare a byte received upon receipt of
> the 1st stop bit, or if it waits for the second one (when you have
> told the UART to "use 2 stop bits"). it had certainly better be the
> former.
>
> finally: the reason for looking at code is not to attack you for not
> being an "expert programmer", but for at least two reasons:
> a) it is not at all rare, i'm sure you'll agree, for some micros to
> have oddities about their architecture which may require what some
> might consider "non-standard" coding to work around known issues, and
> somewhere out there you might just run into someone who has happened
> across such a condition who -- if they saw your code -- might be able
> to tell you that you can't do something that you feel you reasonably
> should be able to do, and
> b) even "expert programmers" can make silly mistakes -- typos they
> never notice because they keep reading back what they intended to
> write rather than what they actually wrote (a common problem for book
> authors, which is why they hire someone else to proof their own work).
>
> i should say that a perfect example of "b)" above is Brendan's recent
> comment about a UART receiver mistakenly declaring a valid byte
> received if -- after the expected number of data/parity bit times --
> it happens to find the Rx line "low" and thereby declares a valid byte
> received. now, this was clearly a mis-statement. your response to
> Brendan was to declare him essentially an idiot for making a claim so
> obviously wrong. i, on the other hand, read this statement within the
> context of the rest of his paragraph, and thereby managed to recognize
> the point he was obviously trying to make, and simply "auto-corrected"
> his use of "low" when he clearly meant "high". see, the paragraph as
> a whole was clearly trying to make a point that a UART receiver has no
> way of truely knowing if the previous 8 or 9 (onr N) bit times really
> constituted a valid byte IF the Rx line is "high" when the UART
> receiver is expecting the stop bit to arrive. if the data rate is
> twice what it is supposed to be, it is not uncommon for a receiver to
> still declare some valid bytes received -- just by luck (bad, in this
> case). i did not think he was directly speaking to your particular
> situation, but merely making the point that UART receivers are not
> foolproof. that's why so many communications protocols layer
> higher-level error detection on top of the physical layer framing (and
> optional parity) error detection. perhaps Brendan should not have
> inserted this comment into your conversation at that precise point,
> but it is interesting to note that you immmediately presumed it
> demonstrated he didn't know what he was talking about, rather than
> that he simply mis-spoke (mis-typed?).
>
> perhaps this is why you are so concerned about providing anyone else a
> copy of the code you are using when you encounter a problem? maybe
> you are afraid that they will show you the same level of disrespect
> that you tend to show others, and will slam you mercilessly for a
> simple typo in your code that might be causing your problem --
> declaring boldly that it is proof you are incompetent or stupid.
> honestly, i don't think either of these labels applies to you, but i
> would have to say that for a self-professed "old timer", you seem to
> have held on to a lot of fairly juvenile attitudes regarding how to
> interact with others on a professional level. frankly, from reading
> some of your earlier posts, i thought you were a college student or
> recent grad.
>
> in the event, you might well get a few undeserved slams from jerks who
> feel they have to denegrate your code in order to inflate their own
> ego, but you won't live or die on their nattering. on the other hand,
> there might well be someone out there who looks at your code and
> notices some simply typo, misplaced bracket, etc. -- or that
> recognizes a sequence in your code that is affected by a device
> problem for which they have already found a work-around -- that clears
> up the issue for you. a fix to a sticky problem, as most "old timers"
> would agree, is worth enduring a few digs from the peanut gallery.
> and, of course, every "old timer" has surely suffered the indignity of
> having that clueless guy from down the hall happen by while you and 3
> other "experts" are debugging something and having them notice
> immediately that you have used a "+" where you meant to use "-" :-(
> it's murphy's law, after all.
>
> in any case, good luck with your LSR problem. i am going to drop off
> this thread now, simply because i don't use polling on the LPC UARTs.
> i hope that you find a useful solution for your client.
>
> by the way, my definition of an "old timer" is someone who not only
> worked with UARTs before they were integrated onto micros, and also
> before there were micros, but also before their were specific devices
> called "UART"s. :-)
>
> -cordeg
> --- In l..., "jayasooriah" wrote:
> >
> > --- In l..., "garycordelli" wrote:
> > > somehow, i never noted that
> > > you were not using an interrupt driven UART handler and that you
were
> > > instead polling the LSR register constantly.
> >
> > Interrupt driven systems are hard to diagnose, especially when the
> > smallest of intrusions changes underlying behavior. Such are embedded
> > systems used in real time environment.
> >
> > I was advised to look into the problem the client had in the
> > operational environment. Rather than try debug the client's system, I
> > decided to extract the scenario and came up with with code (polled)
> > that manifest the problem in a deterministic manner.
> >
> > Now that the client knows what the underlying mechanism, the client is
> > in the best position to work around this, and is able to do this
> > without relying on me.
> >
> > > as it happens, if i knew you were banging on the LSR
> > > incessantly, i could have saved myself the trouble of reading this
> > > seemingly interminable thread long ago.
> >
> > I would be inclined to think otherwise. If it can happen it will
> > happen, and it probably will when you least expect. Thus
> > deterministic experiments are of immense value in working out
> > avoidance strategies.
> >
> > > but most old timers would tell you that your assertion that a
missing
> > > 2nd stop bit should be declared a "framing error" is mistaken
> >
> > Not the old timers I talk to. Besides I am an old timer too,
> > according to some!
> >
> > > experiments undertaken in this regard ought to demonstrate that the
> > > LPC2xxx processor UARTs are not the only such UART implementation to
> > > follow this pattern.
> >
> > The LPC UART has a number unique features never ever discovered in
> > other UARTS, stand alone or embedded.
> >
> > > UART designed with the behavior you describe
> > > would be a poor UART indeed.
> >
> > I do not make any comment on whether the design is poor or not. I am
> > only interested in identifying non-conformant behaviour. If you think
> > this makes the UART poor, that is your opinion.
> >
> > Besides, the LPC expects the second bit to come, and if it does not
> > come, it discards the character, but not report a framing error.
> >
> > This is a verifiable fact.
> >
> > > the purpose of specifying the number of stop bits is to affect the
> > > TRANSMITTER, not the receiver. settings of 1.5 (on some UARTs) or 2
> > > stop bits were defined in the old days to provide extra "slack"
> > > between serial data words so that the receiving systems could
dispense
> > > with each received data word without missing the start of the next
> > > data word (these were slow days, indeed). the receivers, however,
> > > were all designed to accept a data word upon the reception of the
> > > first stop bit, and ignored any successive stop bits until they
> > > detected the high-to-low transition that represented a new start
bit.
> >
> > The LPC UART does do what you are suggesting it ought to do. I think
> > it is right in expecting two stop bits when it is told to use 2 stop
> > bits. As I said, the problem is that it seems to detect the framing
> > error, but failed to report it.
> >
> > > the transmitter could send 1, 2, 100, or any number of stop bits
> > > without causing an error.
> >
> > Inter frame gaps can be indefinite in asynchronous communications.
> > Minimum inter frame gaps are required and the LPC seems to (rightly)
> > expect this. The only problem is that when it does not find what it
> > expects, it simply discards the character.
> >
> > > anyway, now that you have apparently noticed
> > > some connection between your handling of the LSR and the problem you
> > > are seeing, i trust that you will soon figure out why you are
missing
> > > those intervening data words.
> >
> > Interrupt driven or polled, surely you must read the LSR before you
> > read RBR. Are you suggesting that interrupt driven code you do not
> > have to read LSR.
> >
> > Note that error bits are cleared only if you read the LSR -- so you
> > can lock up if you do not read LSR.
> >
> > It appears that if you happen to be reading the LSR just as the UART
> > detected a framing error, the error is not reported. It can happen
> > any time, whether or not you chose to poll.
> >
> > > this might be a good time to turn to
> > > your "last resort", and take a look at the code...
> >
> > I think you appear overly offended when I say looking at code is the
> > last resort.
> >
> > There are many reasons I look at code only as a last resort. This
> > allows me work with clients who are protective or otherwise sensitive
> > about exposing their code.
> >
> > On the other hand, wearing my other hat, I do play the mentor role
> > where I code walk through is my starting point.
> >
> > Given I deal with expert programmers who have been building reliable
> > systems for umpteen years, I tend not ask them for their code every
> > time they tell me they need assistance to look at a problem.
> >
> > I look at the problem from a systems perspective. That is the key IMO
> > to maintain as an open mind as to the possible causes. Then when the
> > suspect cause is identified by experiment, I tell them what I find.
> > They fix their code. The problem is resolved.
> >
> > I tend not to get involved in matters relating to coding errors in
> > this forum. When I see see a common pattern to different problem
> > reports, then I get interested in the problem. When I nail it down, I
> > simply document it as a problem, not a bug or feature, because I do
> > not work in the marketing department.
> >
> > Perhaps you should put your programming skills to discover if the LPC
> > UART does report Framing Error, and if so, under what circumstances.
> > If you can tell me the scenario, I am happy to verify it myself
> > without asking for your code :)
> >
> > My experiment (that you can run on your system for verification
> > purposes) shows that LPC UART on LPC2292 does not report framing
> > errors, even they are deliberately introduced. Here in likes the
> > departure of LPC's UART from others that I have worked with, both
> > embedded and standalone.
> >
> > Jaya
> >
> > PS: In relation to your comment on how old my was, well I took
> > it from the LPC2292 user manual. If that is not good enough for you,
> > sorry I do not think I can do better.
>

Start a New Thread

Gary, apologies for top posting ... I want to focus on the findings:

* The test I documented is a validation test. It tests the
functionality of the UART in relation to stop bits.

* The results show that when configured for two stop bit operation and
presented with only one stop bit, the UART fails.

* The mode of failure is such that it "silently" drops characters.

* There is no basis to assume this problem will not occur in interrupt
driven systems.

[On the contrary, the reason I went looking for this problem is after
receiving many reports from others that UART loses characters on
interrupt driven systems, but they not able pin it down.]

If it makes you feel better, I do not disagree with your statement of
how the UART *should* work. The user manual may be not so clear in
relation to the objective specifications. However it is clear when
you consider both what is expressed in the user manual and the
behaviour of the device itself.

My tests show that a) the LPC UART does check for the second stop bit;
and b) it does the wrong thing when it detects an error in the second
stop bit.

The suggestion I am then making is that given the UART does the wrong
thing when it detects a stop bit violation, the same mechanism is the
likely cause for LPC UARTs to drop characters at low baud rates in
relation to one stop bit violation.

[For what it is worth, I have diagnosed and fixed discrete logic UART
designs where the stop bit was incorrectly sampled at the end of the
bit frame, not at the middle, based on incorrectly interpreting EIA
Recommended Standard 232. Thus understand how such things can happen.]

Jaya

--- In l..., "garycordelli" wrote:
>
> Jaya:
>
> by the way, just in case it helps you at all, i meant to suggest that
> you might want to re-read that LPC2292 User's Manual to differentiate
> between what it actually says from what you may have only presumed it
> said. it does not seem to state anywhere that receiving 1 stop bit
> when it should "expect" 2 is considered to be a framing error. in
> fact, on page 147 of the 05/04/2004 version of the manual on Philips'
> web site, it merely states that "When the stop bit of a received
> character is a logic 0, a framing error occurs." aside from the bad
> grammar, you might mote that it says "the stop bit" not "the stop
> bit(s)". this is -- or certainly should be -- because only the
> *first* stop bit of a *received* character is required. any extra
> stop bits -- whether the UART is "told to use" them or not are simply
> *optional*. a UART programmed to use 1 stop bit should be able to
> receive data from a UART programmed to use 2 stop bits, and vice
> versa, because all UART receivers should require only a single stop
> bit, while any UART transmitter should send the number of stop bits
> they are "told to use".
>
> also, i would add that another comment on that same page demonstrates
> that the LPC UART design is -- while perhaps not *really* bad -- not
> very *good* either. it says that when it finds the above condition to
> exist ("logic 0" when it expects "the stop bit"), it assumes that it
> is an "early start bit", and therefore it re-starts reception of a new
> data word. they then go on to warn the user that the next character
> received might not be good even if there is no framing error on that
> character, which of course could be the case by the luck of the
> sequence of bits. however, a UART design described thusly makes it
> more likely for this next character to be an undetected error, since
> they assume this "0" to be a start bit (apparently) without imposing
> the necessary "high-to-low" transition upon that "early start bit".
> that is, if they are going to re-sync intelligently, they should
> accept this erroneous stop bit as an "early start bit" *only* if the
> previous bit period was a "high". otherwise, they should assume that
> it can't be a true "early start bit" and instead should simply re-sync
> putting their finite state machine back in the "looking for a valid
> start bit" state, rather than a waiting for first data bit" state.
>
> alas.
>
> again, good luck with this UART.
>
> -cordeg

Start a New Thread

Umm.... Hi, Guys...Could we let this thread R.I.P??
The LPC21xx Uarts working fine at 300 Baud....

a) Questions: What is the probability that the Uart is working fine
at 9600-115200 but failed at Baud 300?? and only difference
is the Uart prescaler register value?? (And now the uart had
been tested working fine at baud300).

b) What is so critical if there is some tiny little differences
with the LPC2K Uart and a standard 16C550?? May be let say
philips samples an additional stop bit where most other Uarts
do not do it.... Is there a IEEE standard for UART state-
machine design?? Look at the brighter side, May be the
LPC21xx chip here gives you extra bit-checking for free...

c) What's the point here to force the LPC2100 Uart configured
at 2-stop-bit to accept 1-stop-bit bitstream??

d) How many applications use low UART bit rate nowadays,
especially <9600??

e) For anybody who is still worried about Uart could fail at
very slow baud rate of 300, you can always "soft-uart" or bit
bang it.... (in compensating that.. Philips LPC21xx gives
you extra speed than other ARM7 uC...) => and conclusion of
there will only be a real problem if the P0.0 and P0.1 I/O pins
fail to toggle/output or for reading/input.

:)
Regards

--- In l..., "jayasooriah"
wrote:
>
> Gary, apologies for top posting ... I want to focus on the
findings:
>
> * The test I documented is a validation test. It tests the
> functionality of the UART in relation to stop bits.
>
> * The results show that when configured for two stop bit operation
and
> presented with only one stop bit, the UART fails.
>
> * The mode of failure is such that it "silently" drops characters.
>
> * There is no basis to assume this problem will not occur in
interrupt
> driven systems.
>
> [On the contrary, the reason I went looking for this problem is
after
> receiving many reports from others that UART loses characters on
> interrupt driven systems, but they not able pin it down.]
>
> If it makes you feel better, I do not disagree with your statement
of
> how the UART *should* work. The user manual may be not so clear in
> relation to the objective specifications. However it is clear when
> you consider both what is expressed in the user manual and the
> behaviour of the device itself.
>
> My tests show that a) the LPC UART does check for the second stop
bit;
> and b) it does the wrong thing when it detects an error in the
second
> stop bit.
>
> The suggestion I am then making is that given the UART does the
wrong
> thing when it detects a stop bit violation, the same mechanism is
the
> likely cause for LPC UARTs to drop characters at low baud rates in
> relation to one stop bit violation.
>
> [For what it is worth, I have diagnosed and fixed discrete logic
UART
> designs where the stop bit was incorrectly sampled at the end of
the
> bit frame, not at the middle, based on incorrectly interpreting EIA
> Recommended Standard 232. Thus understand how such things can
happen.]
>
> Jaya
>
> --- In l..., "garycordelli" wrote:
> >
> > Jaya:
> >
> > by the way, just in case it helps you at all, i meant to suggest
that
> > you might want to re-read that LPC2292 User's Manual to
differentiate
> > between what it actually says from what you may have only
presumed it
> > said. it does not seem to state anywhere that receiving 1 stop
bit
> > when it should "expect" 2 is considered to be a framing error.
in
> > fact, on page 147 of the 05/04/2004 version of the manual on
Philips'
> > web site, it merely states that "When the stop bit of a received
> > character is a logic 0, a framing error occurs." aside from the
bad
> > grammar, you might mote that it says "the stop bit" not "the stop
> > bit(s)". this is -- or certainly should be -- because only the
> > *first* stop bit of a *received* character is required. any
extra
> > stop bits -- whether the UART is "told to use" them or not are
simply
> > *optional*. a UART programmed to use 1 stop bit should be able
to
> > receive data from a UART programmed to use 2 stop bits, and vice
> > versa, because all UART receivers should require only a single
stop
> > bit, while any UART transmitter should send the number of stop
bits
> > they are "told to use".
> >
> > also, i would add that another comment on that same page
demonstrates
> > that the LPC UART design is -- while perhaps not *really* bad --
not
> > very *good* either. it says that when it finds the above
condition to
> > exist ("logic 0" when it expects "the stop bit"), it assumes
that it
> > is an "early start bit", and therefore it re-starts reception of
a new
> > data word. they then go on to warn the user that the next
character
> > received might not be good even if there is no framing error on
that
> > character, which of course could be the case by the luck of the
> > sequence of bits. however, a UART design described thusly makes
it
> > more likely for this next character to be an undetected error,
since
> > they assume this "0" to be a start bit (apparently) without
imposing
> > the necessary "high-to-low" transition upon that "early start
bit".
> > that is, if they are going to re-sync intelligently, they should
> > accept this erroneous stop bit as an "early start bit" *only* if
the
> > previous bit period was a "high". otherwise, they should assume
that
> > it can't be a true "early start bit" and instead should simply
re-sync
> > putting their finite state machine back in the "looking for a
valid
> > start bit" state, rather than a waiting for first data bit"
state.
> >
> > alas.
> >
> > again, good luck with this UART.
> >
> > -cordeg
>

Start a New Thread

At 01:39 AM 7/17/2006 +0000, unity0724 wrote:
>b) What is so critical if there is some tiny little differences
> with the LPC2K Uart and a standard 16C550??

Since Philips states the UART is supposed to be compatible then the
differences are important since those are where code that would otherwise
be expected to work will fail. These boundaries are very important to know.

>d) How many applications use low UART bit rate nowadays,
> especially <9600??

That's not the point. The point is that the low baud rate is a stress test
of sorts. It really doesn't matter what odd test is used to duplicate a
problem. It shows a weakness that may be hard to duplicate under other
circumstances. That doesn't mean it won't or can't occur under other
circumstances, that's a separate judgement. If changing asynchronous
timing causes a problem to disappear it would IMHO be very foolish indeed
to assume that the problem had actually been solved w/o further investigation.

Robert

http://www.aeolusdevelopment.com/

From the Divided by a Common Language File (Edited to protect the guilty)
ME - "I'd like to get Price and delivery for connector Part # XXXXX"
Dist./Rep - "$X.XX Lead time 37 days"
ME - "Anything we can do about lead time? 37 days seems a bit high."
Dist./Rep - "that is the lead time given because our stock is live.... we
currently have stock."

Start a New Thread

Hi,...OK....Agree...

You guys can always continue on the 2-stop-bit issue. But
that will be stepping into some "gray area" of UART standard
and complex arguments. And it should affect all baud rates
and not just only lower bit rate of 300.

And more arguments for the FE/PE/OE error status, like
- How should the bits behave?
- Should there be 16 entries of FIFO for the error status also??
- When should that be set and cleared?

As far as I'm concerned, =>the Uart is working fine at low baud
rate (that was the original fault reported) until some new proof
shows otherwise...

:)
Regards

--- In l..., Robert Adsett
wrote:
>
> At 01:39 AM 7/17/2006 +0000, unity0724 wrote:
> >b) What is so critical if there is some tiny little differences
> > with the LPC2K Uart and a standard 16C550??
>
> Since Philips states the UART is supposed to be compatible then
the
> differences are important since those are where code that would
otherwise
> be expected to work will fail. These boundaries are very
important to know.
>
> >d) How many applications use low UART bit rate nowadays,
> > especially <9600??
>
> That's not the point. The point is that the low baud rate is a
stress test
> of sorts. It really doesn't matter what odd test is used to
duplicate a
> problem. It shows a weakness that may be hard to duplicate under
other
> circumstances. That doesn't mean it won't or can't occur under
other
> circumstances, that's a separate judgement. If changing
asynchronous
> timing causes a problem to disappear it would IMHO be very foolish
indeed
> to assume that the problem had actually been solved w/o further
investigation.
>
> Robert
>
> http://www.aeolusdevelopment.com/
>
> From the Divided by a Common Language File (Edited to protect the
guilty)
> ME - "I'd like to get Price and delivery for connector Part #
XXXXX"
> Dist./Rep - "$X.XX Lead time 37 days"
> ME - "Anything we can do about lead time? 37 days seems a bit
high."
> Dist./Rep - "that is the lead time given because our stock is
live.... we
> currently have stock."
>

Start a New Thread

You know, if there WAS a real problem with the UART at low rates,
you could always bit-bang... Especially easy at low baud rates.

Ham radio RTTY would be the only thing I would probably use low
baud rate for these days. Actually, I just might do that. I
guess I'll find out how it works then.

boB
K7IQ

--- In l..., "unity0724" wrote:
>
> Umm.... Hi, Guys...Could we let this thread R.I.P??
> The LPC21xx Uarts working fine at 300 Baud....
>
> a) Questions: What is the probability that the Uart is working fine
> at 9600-115200 but failed at Baud 300?? and only difference
> is the Uart prescaler register value?? (And now the uart had
> been tested working fine at baud300).
>
> b) What is so critical if there is some tiny little differences
> with the LPC2K Uart and a standard 16C550?? May be let say
> philips samples an additional stop bit where most other Uarts
> do not do it.... Is there a IEEE standard for UART state-
> machine design?? Look at the brighter side, May be the
> LPC21xx chip here gives you extra bit-checking for free...
>
> c) What's the point here to force the LPC2100 Uart configured
> at 2-stop-bit to accept 1-stop-bit bitstream??
>
> d) How many applications use low UART bit rate nowadays,
> especially <9600??
>
> e) For anybody who is still worried about Uart could fail at
> very slow baud rate of 300, you can always "soft-uart" or bit
> bang it.... (in compensating that.. Philips LPC21xx gives
> you extra speed than other ARM7 uC...) => and conclusion of
> there will only be a real problem if the P0.0 and P0.1 I/O pins
> fail to toggle/output or for reading/input.
>
> :)
> Regards
>
> --- In l..., "jayasooriah"
> wrote:
> >
> > Gary, apologies for top posting ... I want to focus on the
> findings:
> >
> > * The test I documented is a validation test. It tests the
> > functionality of the UART in relation to stop bits.
> >
> > * The results show that when configured for two stop bit
operation
> and
> > presented with only one stop bit, the UART fails.
> >
> > * The mode of failure is such that it "silently" drops characters.
> >
> > * There is no basis to assume this problem will not occur in
> interrupt
> > driven systems.
> >
> > [On the contrary, the reason I went looking for this problem is
> after
> > receiving many reports from others that UART loses characters on
> > interrupt driven systems, but they not able pin it down.]
> >
> > If it makes you feel better, I do not disagree with your
statement
> of
> > how the UART *should* work. The user manual may be not so clear
in
> > relation to the objective specifications. However it is clear
when
> > you consider both what is expressed in the user manual and the
> > behaviour of the device itself.
> >
> > My tests show that a) the LPC UART does check for the second stop
> bit;
> > and b) it does the wrong thing when it detects an error in the
> second
> > stop bit.
> >
> > The suggestion I am then making is that given the UART does the
> wrong
> > thing when it detects a stop bit violation, the same mechanism is
> the
> > likely cause for LPC UARTs to drop characters at low baud rates in
> > relation to one stop bit violation.
> >
> > [For what it is worth, I have diagnosed and fixed discrete logic
> UART
> > designs where the stop bit was incorrectly sampled at the end of
> the
> > bit frame, not at the middle, based on incorrectly interpreting
EIA
> > Recommended Standard 232. Thus understand how such things can
> happen.]
> >
> > Jaya
> >
> > --- In l..., "garycordelli" wrote:
> > >
> > > Jaya:
> > >
> > > by the way, just in case it helps you at all, i meant to
suggest
> that
> > > you might want to re-read that LPC2292 User's Manual to
> differentiate
> > > between what it actually says from what you may have only
> presumed it
> > > said. it does not seem to state anywhere that receiving 1 stop
> bit
> > > when it should "expect" 2 is considered to be a framing error.
> in
> > > fact, on page 147 of the 05/04/2004 version of the manual on
> Philips'
> > > web site, it merely states that "When the stop bit of a received
> > > character is a logic 0, a framing error occurs." aside from
the
> bad
> > > grammar, you might mote that it says "the stop bit" not "the
stop
> > > bit(s)". this is -- or certainly should be -- because only the
> > > *first* stop bit of a *received* character is required. any
> extra
> > > stop bits -- whether the UART is "told to use" them or not are
> simply
> > > *optional*. a UART programmed to use 1 stop bit should be able
> to
> > > receive data from a UART programmed to use 2 stop bits, and vice
> > > versa, because all UART receivers should require only a single
> stop
> > > bit, while any UART transmitter should send the number of stop
> bits
> > > they are "told to use".
> > >
> > > also, i would add that another comment on that same page
> demonstrates
> > > that the LPC UART design is -- while perhaps not *really* bad --

> not
> > > very *good* either. it says that when it finds the above
> condition to
> > > exist ("logic 0" when it expects "the stop bit"), it assumes
> that it
> > > is an "early start bit", and therefore it re-starts reception
of
> a new
> > > data word. they then go on to warn the user that the next
> character
> > > received might not be good even if there is no framing error on
> that
> > > character, which of course could be the case by the luck of the
> > > sequence of bits. however, a UART design described thusly
makes
> it
> > > more likely for this next character to be an undetected error,
> since
> > > they assume this "0" to be a start bit (apparently) without
> imposing
> > > the necessary "high-to-low" transition upon that "early start
> bit".
> > > that is, if they are going to re-sync intelligently, they should
> > > accept this erroneous stop bit as an "early start bit" *only*
if
> the
> > > previous bit period was a "high". otherwise, they should
assume
> that
> > > it can't be a true "early start bit" and instead should simply
> re-sync
> > > putting their finite state machine back in the "looking for a
> valid
> > > start bit" state, rather than a waiting for first data bit"
> state.
> > >
> > > alas.
> > >
> > > again, good luck with this UART.
> > >
> > > -cordeg
>

Start a New Thread

unity0724 wrote:
> Hi,...OK....Agree...
>
> You guys can always continue on the 2-stop-bit issue. But
> that will be stepping into some "gray area" of UART standard
> and complex arguments. And it should affect all baud rates
> and not just only lower bit rate of 300.
>
> And more arguments for the FE/PE/OE error status, like
> - How should the bits behave?
> - Should there be 16 entries of FIFO for the error status also??
> - When should that be set and cleared?
>
> As far as I'm concerned, =>the Uart is working fine at low baud
> rate (that was the original fault reported) until some new proof
> shows otherwise...
I haven't really had time to check it all but there could definitely be
some problems at low baud rates that we wouldn't notice at higher ones.
This is due to the fact that the uart's internal transmit/receive/status
timing is driven from the baudrate clock. Typical uart datasheets spec
delays in baudrate clock cycles (16x baudrate) which is way way way
longer than cpu cycles. But all this needs to be tested which I will do
as soon as I get a round tuit.

I think the problem would be noticed more if you polled the uart as the
ints are driven from status register updates.

Here's a nasty cut&paste from a datasheet, notice the timing units:

TSSI
Delay From Stop To Set Interrupt
1
1
Bclk

TRRI
Delay From IOR# To Reset Interrupt
45
40
ns

TSI
Delay From Stop To Interrupt
45
40
ns

TINT
Delay From Initial INT Reset To Transmit Start
8
24
8
24
Bclk

TWRI
Delay From IOW# To Reset Interrupt
45
40
ns

TSSR
Delay From Stop To Set RXRDY#
1
1
Bclk

TRR
Delay From IOR# To Reset RXRDY#
45
40
ns

TWT
Delay From IOW# To Set TXRDY#
45
40
ns

TSRT
Delay From Center of Start To Reset TXRDY#
8
8
Bclk
*Peter* Start a New Thread

--- In l..., Peter Jakacki wrote:
>
> unity0724 wrote:
> > Hi,...OK....Agree...
> >
> > You guys can always continue on the 2-stop-bit issue. But
> > that will be stepping into some "gray area" of UART standard
> > and complex arguments. And it should affect all baud rates
> > and not just only lower bit rate of 300.
> >
> > And more arguments for the FE/PE/OE error status, like
> > - How should the bits behave?
> > - Should there be 16 entries of FIFO for the error status also??
> > - When should that be set and cleared?
> >
> > As far as I'm concerned, =>the Uart is working fine at low baud
> > rate (that was the original fault reported) until some new proof
> > shows otherwise...
>
>
> I haven't really had time to check it all but there could
definitely be
> some problems at low baud rates that we wouldn't notice at higher
ones.
> This is due to the fact that the uart's internal
transmit/receive/status
> timing is driven from the baudrate clock. Typical uart datasheets
spec
> delays in baudrate clock cycles (16x baudrate) which is way way way
> longer than cpu cycles. But all this needs to be tested which I
will do
> as soon as I get a round tuit.
>
> I think the problem would be noticed more if you polled the uart as
the
> ints are driven from status register updates.
>

As I was somewhat concerned there may be a real problem with this,
I've done some testing as follows. I'm posting the results here to
provide more information on how (I've observed) the parts behave.

My test system is LPC2134 based, running off a 20 MHz crystal with
PLL active and clocking at 60 MHz. As a test system, I used a PC with
standard serial port, and a test program we use for testing systems.
This includes the ability to send blocks of data. I verified (using a
scope on the line) that in this mode, the data are sent with
no "gaps": the stop bit length corresponds exactly to that expected
(e.g. 3.33 ms for 300 bps with 1 stop bit, 1.66 ms for 1200 bps with
two stop bits etc.), with no gap before the following character's
start bit.

First test system used our own internal automated stress tests
against a system with our standard UART drivers, with the test system
reconfigured to test mostly at low bit rates (300 9600bps). All
communication uses 1-stop bit. Left overnight (it operates fairly
continuously, sending and verifying data, changing bit rates and
repeating), there were no errors.

Second test system was the same test tool (used in "non-automated"
mode), using Jaya's test program (which clearly uses 2-stop bits) on
the target device. Results are as follows:

- line speed made no difference (I tried 300 bps through to 115.2
kbps)

- if the PC end was configured with 1 stop bit and the data sent in
bursts (i.e. no gaps), there were errors in reception; this was
observed at several bit rates

- errors were missing or incorrect characters.

Third test system was a new test program, similar to Jaya's in that
it used polled I/O, but written to ensure I knew and could control
the UART register settings. I also used a different read function, as
there are code paths in Jaya's version that didn't return each and
every character and I wanted to remove the complication of
processing. I also wanted to have a log of each character and its
status. Results for this are:

- line speed makes no difference (I tried 300 bps through to 115.2
kbps)

- if the configurations of the UARTs on both ends of the line
matched, there were no errors

- if the PC end was configured with 1 stop bit and the LPC2xxx with 2
stop bits and the data sent in bursts (i.e. no gaps), there were
errors in reception

- the errors varied, depending on the data being sent and the number
of characters in the burst; there's not much consistency, but in a
burst of say 20 characters, there might be two or three frame errors
reported, data received that was invalid (i.e. 0xf3 rather than "w"
or whatever), and missing characters that were never reported.

My conclusions:

- there is no issue that I have seen with line speed, and until
someone can produce a test setup that shows it, I'd be very surprised
if there is one

- if the configuration of the UARTs match (i.e. both ends are 8-N-1
or both 8-N-2) I have yet to see any errors, regardless of how much
you fill the line

- the LPC2xxx clearly needs 2-stop bits in the receive direction when
configured with 2-stop bits; I don't know how normal this is for
UARTs, but on the other hand it's what I'd always assumed (maybe
incorrectly, as it turns out)

- if you have mismatched configurations (e.g. 8-N-1 on the LPC2xxx
and 8-N-2 on the other system) and you send data with no gaps, you
will most likely get errors

- the errors seen vary from wrong data with framing error; wrong data
with no framing error; to missing data

To me, this is all fairly predictable: if you have mismatched
configurations on a communication link, you get errors. Not all
errors are detected: again, not surprising. That's why level 2
protocols exist.

I've done no comparative testing with other systems and UARTs (I've
spent enough time already on this), so I've no idea how good or bad
the LPC2xxx is relative to their performance.

I would be interested to hear of anyone else's test results though.

Hopefully these results will be of some benefit: all they've done for
me is confirm what I either already knew, or assumed to be the case.

By the way, if anyone wants the test code, let me know.

Brendan.





Start a New Thread

Thanks for sharing your results with us Brendan. Looks like we have
had another time wasting false alarm. I don't imagine you will
receive an apology or acknowledgment from Jaya, who appears to regard
anyone who does not engage in reckless opininated criticism of
Philips as having the habits of animals.

There was another false alarm over the UARTs and 'spurious
interrupts'.

A certain amount of care, attention to detail and lack of arrogance
towards Philips for enhancing their peripherals with useful
functionality would help.

>From what I can remember about the UART, it simply cannot be treated
with the same reckless abandon as with other microcontrollers.

John Heenan
--- In l..., "brendanmurphy37"
wrote:
>
> --- In l..., Peter Jakacki wrote:
> >
> > unity0724 wrote:
> > > Hi,...OK....Agree...
> > >
> > > You guys can always continue on the 2-stop-bit issue. But
> > > that will be stepping into some "gray area" of UART standard
> > > and complex arguments. And it should affect all baud rates
> > > and not just only lower bit rate of 300.
> > >
> > > And more arguments for the FE/PE/OE error status, like
> > > - How should the bits behave?
> > > - Should there be 16 entries of FIFO for the error status also??
> > > - When should that be set and cleared?
> > >
> > > As far as I'm concerned, =>the Uart is working fine at low baud
> > > rate (that was the original fault reported) until some new
proof
> > > shows otherwise...
> >
> >
> > I haven't really had time to check it all but there could
> definitely be
> > some problems at low baud rates that we wouldn't notice at higher
> ones.
> > This is due to the fact that the uart's internal
> transmit/receive/status
> > timing is driven from the baudrate clock. Typical uart datasheets
> spec
> > delays in baudrate clock cycles (16x baudrate) which is way way
way
> > longer than cpu cycles. But all this needs to be tested which I
> will do
> > as soon as I get a round tuit.
> >
> > I think the problem would be noticed more if you polled the uart
as
> the
> > ints are driven from status register updates.
> >
>
> As I was somewhat concerned there may be a real problem with this,
> I've done some testing as follows. I'm posting the results here to
> provide more information on how (I've observed) the parts behave.
>
> My test system is LPC2134 based, running off a 20 MHz crystal with
> PLL active and clocking at 60 MHz. As a test system, I used a PC
with
> standard serial port, and a test program we use for testing
systems.
> This includes the ability to send blocks of data. I verified (using
a
> scope on the line) that in this mode, the data are sent with
> no "gaps": the stop bit length corresponds exactly to that expected
> (e.g. 3.33 ms for 300 bps with 1 stop bit, 1.66 ms for 1200 bps
with
> two stop bits etc.), with no gap before the following character's
> start bit.
>
> First test system used our own internal automated stress tests
> against a system with our standard UART drivers, with the test
system
> reconfigured to test mostly at low bit rates (300 9600bps). All
> communication uses 1-stop bit. Left overnight (it operates fairly
> continuously, sending and verifying data, changing bit rates and
> repeating), there were no errors.
>
> Second test system was the same test tool (used in "non-automated"
> mode), using Jaya's test program (which clearly uses 2-stop bits)
on
> the target device. Results are as follows:
>
> - line speed made no difference (I tried 300 bps through to 115.2
> kbps)
>
> - if the PC end was configured with 1 stop bit and the data sent in
> bursts (i.e. no gaps), there were errors in reception; this was
> observed at several bit rates
>
> - errors were missing or incorrect characters.
>
> Third test system was a new test program, similar to Jaya's in that
> it used polled I/O, but written to ensure I knew and could control
> the UART register settings. I also used a different read function,
as
> there are code paths in Jaya's version that didn't return each and
> every character and I wanted to remove the complication of

> processing. I also wanted to have a log of each character and its
> status. Results for this are:
>
> - line speed makes no difference (I tried 300 bps through to 115.2
> kbps)
>
> - if the configurations of the UARTs on both ends of the line
> matched, there were no errors
>
> - if the PC end was configured with 1 stop bit and the LPC2xxx with
2
> stop bits and the data sent in bursts (i.e. no gaps), there were
> errors in reception
>
> - the errors varied, depending on the data being sent and the
number
> of characters in the burst; there's not much consistency, but in a
> burst of say 20 characters, there might be two or three frame
errors
> reported, data received that was invalid (i.e. 0xf3 rather than "w"
> or whatever), and missing characters that were never reported.
>
> My conclusions:
>
> - there is no issue that I have seen with line speed, and until
> someone can produce a test setup that shows it, I'd be very
surprised
> if there is one
>
> - if the configuration of the UARTs match (i.e. both ends are 8-N-1
> or both 8-N-2) I have yet to see any errors, regardless of how much
> you fill the line
>
> - the LPC2xxx clearly needs 2-stop bits in the receive direction
when
> configured with 2-stop bits; I don't know how normal this is for
> UARTs, but on the other hand it's what I'd always assumed (maybe
> incorrectly, as it turns out)
>
> - if you have mismatched configurations (e.g. 8-N-1 on the LPC2xxx
> and 8-N-2 on the other system) and you send data with no gaps, you
> will most likely get errors
>
> - the errors seen vary from wrong data with framing error; wrong
data
> with no framing error; to missing data
>
> To me, this is all fairly predictable: if you have mismatched
> configurations on a communication link, you get errors. Not all
> errors are detected: again, not surprising. That's why level 2
> protocols exist.
>
> I've done no comparative testing with other systems and UARTs (I've
> spent enough time already on this), so I've no idea how good or bad
> the LPC2xxx is relative to their performance.
>
> I would be interested to hear of anyone else's test results though.
>
> Hopefully these results will be of some benefit: all they've done
for
> me is confirm what I either already knew, or assumed to be the
case.
>
> By the way, if anyone wants the test code, let me know.
>
> Brendan.
>





Start a New Thread