--- In l..., "brendanmurphy37"
wrote:
>
> By the way, on an asynchronous interface it's perfectly valid for a
> UART not to report any problems at mismatched speeds: if for example
> the line is low when it's expecting a stop bit, it'll just report
> the previous 8 bits as data, whatever they are.
Rubbish. RTFM.
When the stop bit of a received character is a logic 0, a framing
error occurs. An U1LSR read clears this bit. The time of the framing
error detection is dependent on U1FCR0. A framing error is associated
with the character being read from the UART1 RBR FIFO. Upon detection
of a framing error, the Rx will attempt to resynchronize to the data and
assume that the bad stop bit is actually an early start bit.
Re: LPC2000 UART drops characters silently?
Started by ●July 14, 2006
Reply by ●July 15, 20062006-07-15
Reply by ●July 16, 20062006-07-16
jaya:
wow. i've been following this thread off and on for quite some time,
trying to see if there was anything to worry about with regard to
using LPC parts at low baud rates or not (specifically to handle
auto-baud situations like you described). somehow, i never noted that
you were not using an interrupt driven UART handler and that you were
instead polling the LSR register constantly. i don't know if i just
missed this information in one of your earlier emails, but i did note
that several posters asked to "see your code" but that you demurred on
the rather curious grounds that you found that -- in diagnosing
problems with microcontrollers -- looking at the code was really a
last resort. 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 wish i had long ago had the
opportunity to "see your code" and thereby had a chance to get to the
bottom of this problem.
also, Philips may not publish this in their device documentation, and
you might not even find it in the average "how a UART works" blurb
written in the last 10 years that you might find posted on the web,
but most old timers would tell you that your assertion that a missing
2nd stop bit should be declared a "framing error" is mistaken, and
experiments undertaken in this regard ought to demonstrate that the
LPC2xxx processor UARTs are not the only such UART implementation to
follow this pattern. any UART designed with the behavior you describe
would be a poor UART indeed.
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 transmitter could send 1, 2, 100, or any number of stop bits
without causing an error. moreover, the UART receiver is NOT actually
"programmed" by the "# stop bits" control parameter -- all receivers
NEED only 1 stop bit, and don't care how many more than 1 they get.
the real control of stop bit handling is in the UART transmitter,
which is the sole recipient of the "# stop bits" control parameter in
every UART design i have ever seen, going back over 30 years. the
exact number of stop bits (beyond 1) is NOT enforced at the receiver
end -- period. setting the LPC UART to "2 stop bits" and transmitting
data to it with "only" 1 stop bit, should not bother the LPC UART
receiver at all, and should not result in a framing error.
this is quite a separate issue from why (or how) you are losing the
intervening data words. 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. this might be a good time to turn to
your "last resort", and take a look at the code...
-cordeg
--- In l..., "jayasooriah" wrote:
>
> --- In l..., "unity0724" wrote:
> >
> > --- In l..., "jayasooriah"
> > > So I decided to force saturation by setting the host computer to
> > > 8-data and 1-stop bits, and the LPC2292 to 8-data and 2-stop bits.
> > > Both with no parity.
> >
> > Umm..Sorry..it sounds logical but I failed to understand the logic..
> > When LPC UART is set to 8-data 2-stop bits, it expects two stop bits
> after the character before the next one arrives.
>
> When host UART is set to 8-data 1-stop bits, and it sends data quickly
> enough, there will be only 1-stop bit plus delays, which is less than
> 2-stop bit delay.
>
> On receiving the two characters with less than 2-stop bits after the
> first character, the LPC UART should detect this and report framing
error.
>
> It appears UART0 on LPC2292/0510 does not. Instead it discard the
> first character silently.
>
> For the benefit of the others who are seeing such UART problems and
> wondering why it is not reproducible, I found that you are less likely
> to see the problem if your driver is interrupt driven.
>
> It appears that this problem occurs more when the LSR register is
> constantly being polled. Thus it makes sense that when you are
> polling, you are more likely to see this error at low baud rates.
>
> Hope this helps.
>
> Jaya
>
> PS: I also found out how and why the Philips Boot Loader misses
> characters when run at low baud rates -- the Boot Loader tries to
> handle both and end of line sequences, but gets it wrong.
>
wow. i've been following this thread off and on for quite some time,
trying to see if there was anything to worry about with regard to
using LPC parts at low baud rates or not (specifically to handle
auto-baud situations like you described). somehow, i never noted that
you were not using an interrupt driven UART handler and that you were
instead polling the LSR register constantly. i don't know if i just
missed this information in one of your earlier emails, but i did note
that several posters asked to "see your code" but that you demurred on
the rather curious grounds that you found that -- in diagnosing
problems with microcontrollers -- looking at the code was really a
last resort. 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 wish i had long ago had the
opportunity to "see your code" and thereby had a chance to get to the
bottom of this problem.
also, Philips may not publish this in their device documentation, and
you might not even find it in the average "how a UART works" blurb
written in the last 10 years that you might find posted on the web,
but most old timers would tell you that your assertion that a missing
2nd stop bit should be declared a "framing error" is mistaken, and
experiments undertaken in this regard ought to demonstrate that the
LPC2xxx processor UARTs are not the only such UART implementation to
follow this pattern. any UART designed with the behavior you describe
would be a poor UART indeed.
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 transmitter could send 1, 2, 100, or any number of stop bits
without causing an error. moreover, the UART receiver is NOT actually
"programmed" by the "# stop bits" control parameter -- all receivers
NEED only 1 stop bit, and don't care how many more than 1 they get.
the real control of stop bit handling is in the UART transmitter,
which is the sole recipient of the "# stop bits" control parameter in
every UART design i have ever seen, going back over 30 years. the
exact number of stop bits (beyond 1) is NOT enforced at the receiver
end -- period. setting the LPC UART to "2 stop bits" and transmitting
data to it with "only" 1 stop bit, should not bother the LPC UART
receiver at all, and should not result in a framing error.
this is quite a separate issue from why (or how) you are losing the
intervening data words. 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. this might be a good time to turn to
your "last resort", and take a look at the code...
-cordeg
--- In l..., "jayasooriah" wrote:
>
> --- In l..., "unity0724" wrote:
> >
> > --- In l..., "jayasooriah"
> > > So I decided to force saturation by setting the host computer to
> > > 8-data and 1-stop bits, and the LPC2292 to 8-data and 2-stop bits.
> > > Both with no parity.
> >
> > Umm..Sorry..it sounds logical but I failed to understand the logic..
> > When LPC UART is set to 8-data 2-stop bits, it expects two stop bits
> after the character before the next one arrives.
>
> When host UART is set to 8-data 1-stop bits, and it sends data quickly
> enough, there will be only 1-stop bit plus delays, which is less than
> 2-stop bit delay.
>
> On receiving the two characters with less than 2-stop bits after the
> first character, the LPC UART should detect this and report framing
error.
>
> It appears UART0 on LPC2292/0510 does not. Instead it discard the
> first character silently.
>
> For the benefit of the others who are seeing such UART problems and
> wondering why it is not reproducible, I found that you are less likely
> to see the problem if your driver is interrupt driven.
>
> It appears that this problem occurs more when the LSR register is
> constantly being polled. Thus it makes sense that when you are
> polling, you are more likely to see this error at low baud rates.
>
> Hope this helps.
>
> Jaya
>
> PS: I also found out how and why the Philips Boot Loader misses
> characters when run at low baud rates -- the Boot Loader tries to
> handle both and end of line sequences, but gets it wrong.
>
Reply by ●July 16, 20062006-07-16
--- 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.
> 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.
Reply by ●July 16, 20062006-07-16
--- In l..., "garycordelli" wrote:
> this might be a good time to turn to
> your "last resort", and take a look at the code...
Gary, in response to your request for source code, I have put this up
on my page where I describe the problem and solution:
http://www.cse.unsw.edu.au/~jayas/esdk/lpc2/limitations.html
You are welcome to point out any errors in the code, or if there is a
better way to explain the problem better given I put it up as a rush
job. I welcome input from anybody.
It is not hard for anyone to use the information and code I have
provided to see if you get different result on your part.
Of course if you find something wrong in my code, or get a different
result, I would be very interested to know. Otherwise I like to think
the problem has been nailed down to its cause.
Kind regards,
Jaya
> this might be a good time to turn to
> your "last resort", and take a look at the code...
Gary, in response to your request for source code, I have put this up
on my page where I describe the problem and solution:
http://www.cse.unsw.edu.au/~jayas/esdk/lpc2/limitations.html
You are welcome to point out any errors in the code, or if there is a
better way to explain the problem better given I put it up as a rush
job. I welcome input from anybody.
It is not hard for anyone to use the information and code I have
provided to see if you get different result on your part.
Of course if you find something wrong in my code, or get a different
result, I would be very interested to know. Otherwise I like to think
the problem has been nailed down to its cause.
Kind regards,
Jaya
Reply by ●July 16, 20062006-07-16
--- In l..., "jayasooriah"
wrote:
>
> --- In l..., "brendanmurphy37"
> wrote:
> >
> > By the way, on an asynchronous interface it's perfectly valid
for a
> > UART not to report any problems at mismatched speeds: if for
example
> > the line is low when it's expecting a stop bit, it'll just
report
> > the previous 8 bits as data, whatever they are.
>
> Rubbish. RTFM.
>
>
> When the stop bit of a received character is a logic 0, a framing
> error occurs. An U1LSR read clears this bit. The time of the
framing
> error detection is dependent on U1FCR0. A framing error is
associated
> with the character being read from the UART1 RBR FIFO. Upon
detection
> of a framing error, the Rx will attempt to resynchronize to the
data and
> assume that the bad stop bit is actually an early start bit.
>
You're quite right: I should have said "high" rather than "low". If
I had done, I believe the sense of what I said is correct. The point
is that framing errors are not (and cannot be) detected in all
cases: it depends on what data is being sent and the timings
involved.
Sorry for any confusion caused by the error: I guess we can't all be
perfect....
Brendan.
wrote:
>
> --- In l..., "brendanmurphy37"
> wrote:
> >
> > By the way, on an asynchronous interface it's perfectly valid
for a
> > UART not to report any problems at mismatched speeds: if for
example
> > the line is low when it's expecting a stop bit, it'll just
report
> > the previous 8 bits as data, whatever they are.
>
> Rubbish. RTFM.
>
>
> When the stop bit of a received character is a logic 0, a framing
> error occurs. An U1LSR read clears this bit. The time of the
framing
> error detection is dependent on U1FCR0. A framing error is
associated
> with the character being read from the UART1 RBR FIFO. Upon
detection
> of a framing error, the Rx will attempt to resynchronize to the
data and
> assume that the bad stop bit is actually an early start bit.
>
You're quite right: I should have said "high" rather than "low". If
I had done, I believe the sense of what I said is correct. The point
is that framing errors are not (and cannot be) detected in all
cases: it depends on what data is being sent and the timings
involved.
Sorry for any confusion caused by the error: I guess we can't all be
perfect....
Brendan.
Reply by ●July 16, 20062006-07-16
--- In l..., "brendanmurphy37"
wrote:
> You're quite right: I should have said "high" rather than "low". If
> I had done, I believe the sense of what I said is correct.
Try again Murphy. Substitute "low" with "high" read your statement
aloud :)
What information is the your amended statement "the line is high when
it is expecting a stop bit it'll just report the previous 8 bits as
data" alluding us to? Stop bit *is* supposed to be high, is it not?
> The point
> is that framing errors are not (and cannot be) detected in all
> cases: it depends on what data is being sent and the timings
> involved.
Really? What do you think the statement "When the stop bit of a
received character is a logic 0, a framing error occurs" in the user
manual means.
You are indeed funny! Sorry I was annoyed with your previous rebuttal.
Jaya
wrote:
> You're quite right: I should have said "high" rather than "low". If
> I had done, I believe the sense of what I said is correct.
Try again Murphy. Substitute "low" with "high" read your statement
aloud :)
What information is the your amended statement "the line is high when
it is expecting a stop bit it'll just report the previous 8 bits as
data" alluding us to? Stop bit *is* supposed to be high, is it not?
> The point
> is that framing errors are not (and cannot be) detected in all
> cases: it depends on what data is being sent and the timings
> involved.
Really? What do you think the statement "When the stop bit of a
received character is a logic 0, a framing error occurs" in the user
manual means.
You are indeed funny! Sorry I was annoyed with your previous rebuttal.
Jaya
Reply by ●July 16, 20062006-07-16
--- In l..., "jayasooriah"
wrote:
>
> --- In l..., "brendanmurphy37"
> wrote:
> > You're quite right: I should have said "high" rather than "low".
If
> > I had done, I believe the sense of what I said is correct.
>
> Try again Murphy. Substitute "low" with "high" read your statement
> aloud :)
>
> What information is the your amended statement "the line is high
when
> it is expecting a stop bit it'll just report the previous 8 bits as
> data" alluding us to? Stop bit *is* supposed to be high, is it
not?
Exactly! If the line is high when it's expecting a stop bit it
**will** treat it as a stop bit, and not report any framing error.
It cannot tell if the high it is seeing is a valid stop bit, or a
mistimed data (or more likely idle condition) bit from the
transmitter.
>
> > The point
> > is that framing errors are not (and cannot be) detected in all
> > cases: it depends on what data is being sent and the timings
> > involved.
>
> Really? What do you think the statement "When the stop bit of a
> received character is a logic 0, a framing error occurs" in the
user
> manual means.
I guess it means what it says. It doesn't contradict my own
statement (i.e. if it's a 1, no framing error is reported).
>
> You are indeed funny! Sorry I was annoyed with your previous
rebuttal.
I'm glad I ammuse you: I have to say I've frequently been amused by
your own contributions.
Seriously, though: thanks for providing the source of your test
program. As I pointed out before, unless very specific and complete
information is provided to demonstrate a flaw in the device, you
cannot be expect to be treated seriously. Just saying "my system
doesn't work" and "it's a bug in the device" won't get far,
regardless of who you are.
I'm sure someone will have the time to verify or disprove what you
say: I await developments with interest.
Brendan
wrote:
>
> --- In l..., "brendanmurphy37"
> wrote:
> > You're quite right: I should have said "high" rather than "low".
If
> > I had done, I believe the sense of what I said is correct.
>
> Try again Murphy. Substitute "low" with "high" read your statement
> aloud :)
>
> What information is the your amended statement "the line is high
when
> it is expecting a stop bit it'll just report the previous 8 bits as
> data" alluding us to? Stop bit *is* supposed to be high, is it
not?
Exactly! If the line is high when it's expecting a stop bit it
**will** treat it as a stop bit, and not report any framing error.
It cannot tell if the high it is seeing is a valid stop bit, or a
mistimed data (or more likely idle condition) bit from the
transmitter.
>
> > The point
> > is that framing errors are not (and cannot be) detected in all
> > cases: it depends on what data is being sent and the timings
> > involved.
>
> Really? What do you think the statement "When the stop bit of a
> received character is a logic 0, a framing error occurs" in the
user
> manual means.
I guess it means what it says. It doesn't contradict my own
statement (i.e. if it's a 1, no framing error is reported).
>
> You are indeed funny! Sorry I was annoyed with your previous
rebuttal.
I'm glad I ammuse you: I have to say I've frequently been amused by
your own contributions.
Seriously, though: thanks for providing the source of your test
program. As I pointed out before, unless very specific and complete
information is provided to demonstrate a flaw in the device, you
cannot be expect to be treated seriously. Just saying "my system
doesn't work" and "it's a bug in the device" won't get far,
regardless of who you are.
I'm sure someone will have the time to verify or disprove what you
say: I await developments with interest.
Brendan
Reply by ●July 16, 20062006-07-16
--- In l..., "brendanmurphy37"
wrote:
> --- In l..., "jayasooriah"
> wrote:
>
> I'm sure someone will have the time to verify or disprove what you
> say: I await developments with interest.
>
> Brendan
I am sure you would have reported to us all if you were not able to
reproduce my results using my test program tiven how anxious you are
to disprove my findings.
For the record, I have had people read my write up and tell me they
understand what is going on, and have provided useful feedback based
on which I update the presentation. Now anyone including Philips can
verify the problem for themselves.
Jaya
PS: Remember a while ago I asked why is the Boot Loader was doing a
programmed delay loop instead of checking flash status register? And
you made such a big fuss about it? Well I had a look at later version
of the Boot Loader and it appears that they are now actually polling
the flash status register :)
wrote:
> --- In l..., "jayasooriah"
> wrote:
>
> I'm sure someone will have the time to verify or disprove what you
> say: I await developments with interest.
>
> Brendan
I am sure you would have reported to us all if you were not able to
reproduce my results using my test program tiven how anxious you are
to disprove my findings.
For the record, I have had people read my write up and tell me they
understand what is going on, and have provided useful feedback based
on which I update the presentation. Now anyone including Philips can
verify the problem for themselves.
Jaya
PS: Remember a while ago I asked why is the Boot Loader was doing a
programmed delay loop instead of checking flash status register? And
you made such a big fuss about it? Well I had a look at later version
of the Boot Loader and it appears that they are now actually polling
the flash status register :)
Reply by ●July 16, 20062006-07-16
At 05:11 AM 7/16/06 +0000, jayasooriah wrote:
>deterministic experiments are of immense value in working out
>avoidance strategies.
Also in just simply repeatably demonstrating the problem.
>It appears that if you happen to be reading the LSR just as the UART
>detected a framing error, the error is not reported.
That's an interesting thought. Race conditions seem to have been a
particular problem with this family. It also fits with the occasional
stops I've seen in the UART at higher (9600-19200 baud) rates that appeared
only at high load. The fixes applied that seemed to have 'fixed' the
problem were to 1) read the IIR only once per interrupt and 2) enable the
FIFO (I had missed that note in the user manual). I'll have to do a few
tests at lower baud rates when I get a little time.
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."
>deterministic experiments are of immense value in working out
>avoidance strategies.
Also in just simply repeatably demonstrating the problem.
>It appears that if you happen to be reading the LSR just as the UART
>detected a framing error, the error is not reported.
That's an interesting thought. Race conditions seem to have been a
particular problem with this family. It also fits with the occasional
stops I've seen in the UART at higher (9600-19200 baud) rates that appeared
only at high load. The fixes applied that seemed to have 'fixed' the
problem were to 1) read the IIR only once per interrupt and 2) enable the
FIFO (I had missed that note in the user manual). I'll have to do a few
tests at lower baud rates when I get a little time.
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."
Reply by ●July 16, 20062006-07-16
--- In l..., "jayasooriah"
wrote:
>
> --- In l..., "brendanmurphy37"
> wrote:
> > --- In l..., "jayasooriah"
> > wrote:
> >
> > I'm sure someone will have the time to verify or disprove what
you
> > say: I await developments with interest.
> >
> > Brendan
>
> I am sure you would have reported to us all if you were not able to
> reproduce my results using my test program tiven how anxious you
are
> to disprove my findings.
I'm afraid that I spend too much time as it is on this group without
adding to that by doing any specific tests on this. All I know is
that the test suite we use (which includes stress tests on the UARTs
at various bit rates) works with no problems.
Also, I think you misunderstand my intention: I've no interest in
proving or disproving what you say. All I asked for was a reasonable
about of information to back your claim, which if true could have
implications for those using the parts. Right now, I'd have an open
mind on whether or not the problem is with the part or how it's
being used.
>
> For the record, I have had people read my write up and tell me they
> understand what is going on, and have provided useful feedback
based
> on which I update the presentation. Now anyone including Philips
can
> verify the problem for themselves.
>
I wonder why they don't provide that feedback on this (open) forum?
> Jaya
>
> PS: Remember a while ago I asked why is the Boot Loader was doing
a
> programmed delay loop instead of checking flash status register?
And
> you made such a big fuss about it? Well I had a look at later
version
> of the Boot Loader and it appears that they are now actually
polling
> the flash status register :)
Er, no - I've no idea what you're talking about here. I've no
knowledge of or particular interest in the internal workings of
either Philip's or your own boot loader. As far as I recall the only
comments I made about this were (a) I didn't see the need to replace
the existing boot loader and (b) I thought it a very bad strategy to
include something that is unsupported in a commercial product. But
let's not revisit that particular thread.....
Brendan.
wrote:
>
> --- In l..., "brendanmurphy37"
> wrote:
> > --- In l..., "jayasooriah"
> > wrote:
> >
> > I'm sure someone will have the time to verify or disprove what
you
> > say: I await developments with interest.
> >
> > Brendan
>
> I am sure you would have reported to us all if you were not able to
> reproduce my results using my test program tiven how anxious you
are
> to disprove my findings.
I'm afraid that I spend too much time as it is on this group without
adding to that by doing any specific tests on this. All I know is
that the test suite we use (which includes stress tests on the UARTs
at various bit rates) works with no problems.
Also, I think you misunderstand my intention: I've no interest in
proving or disproving what you say. All I asked for was a reasonable
about of information to back your claim, which if true could have
implications for those using the parts. Right now, I'd have an open
mind on whether or not the problem is with the part or how it's
being used.
>
> For the record, I have had people read my write up and tell me they
> understand what is going on, and have provided useful feedback
based
> on which I update the presentation. Now anyone including Philips
can
> verify the problem for themselves.
>
I wonder why they don't provide that feedback on this (open) forum?
> Jaya
>
> PS: Remember a while ago I asked why is the Boot Loader was doing
a
> programmed delay loop instead of checking flash status register?
And
> you made such a big fuss about it? Well I had a look at later
version
> of the Boot Loader and it appears that they are now actually
polling
> the flash status register :)
Er, no - I've no idea what you're talking about here. I've no
knowledge of or particular interest in the internal workings of
either Philip's or your own boot loader. As far as I recall the only
comments I made about this were (a) I didn't see the need to replace
the existing boot loader and (b) I thought it a very bad strategy to
include something that is unsupported in a commercial product. But
let's not revisit that particular thread.....
Brendan.
