> I tend to frown on "show me your code" kind of
requests. When I
> diagnose problems, I look at code only as the very last resort.
>
> I would study the symptoms carefully and form an opinion as to likely
> causes. I would then ask the questions that are relevant these
> suspect causes.
>
> I tend to stay away from fishing expeditions as it is known in this field.
...
> Kind regards,
>
> Jaya
>
This statement is crazy.
If you cannot be sure this "problem" you are seeing is not the result
of the software you are running, then frankly you have no idea if
there is a problem with the chip or not.
If it is not the software then try repeating the problem with no
software in the chip! Then I will be convinced.
An Engineer would never make the statement you make above.
I am using LPC chips and I have good evidence that many of your
interpretations of your "findings" are just plain wrong.
[Apologies if this is a repeat post -- first post appears lost.]
--- In l..., "John Heenan" wrote: >
> 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
Hello John. I see you are back and bashing again :)
Perhaps you would like to explain why you expect an "apology".
Has anyone shown the results or conclusions therein incorrect?
BTW, as the saying goes, blind testing doesn't prove anything more
than that if close your eyes, you will see nothing wrong!
Jaya
PS: Would be good if you could update us on any progress you have
with your "sensible" request for boot loader feature that enables
anyone to lock up their parts in a deterministic way!
Reply by "ian.scanlon"●July 19, 20062006-07-19
--- In l..., "ian.scanlon"
wrote: >
> --- In l..., "brendanmurphy37"
> wrote:
> >
> > --- In l..., "jsm09a"
> > yahoo.e35f5f@> wrote:
> >
> > > My compliments on your patience ;) One aspect that I haven't seen > > > addressed is possible dependence on differences
in realized baud > > rates.
> > >
> > > In these tests, the source and destination will be sync'd to
> > different
> > > system clocks which may differ by an appreciable margin. I
> wonder
> > if
> > > the conflicting results could be explained by differences in
> system
> > > clock rates.
> > >
> > > Given that there appears to be a problem with the LPC2XXX when it > > is
> > > expecting two stop bits and receives only one, I wonder if a
> > similar
> > > problem might occur if the LPC2XXX was actually running at 275
> baud
> > > while the sender was running at a full 300 baud (resulting in a
> > > "shorter" stop bit than expected).
> > >
> > > Just a thought. Best regards, Scott.
> > >
> >
> > You're right of course - if the two clocks are out by an
> appreciable
> > amount, there is the possibility of timing errors.
> >
> > In a lot of cases, one or other (or both) sides are in fact out,
> > particularly if an even base clock rate like 10 Mhz or so is used
> > and the UART can only work of integer divisions of the base clock
> > (i.e. not all rates will divide evenly, and the nearest integer
> > value can be maybe 1 or 2% out).
> >
> > Asynchronous communication is designed to be tolerant of these
> > differences: the clocks are effectively re-synched on each byte
> > sent/received (usually on the falling edge of the start bit if my
> > memory serves). Therefore the timing errors can only accumulate
> over
> > the length of one byte (say 10 bits or so). It's a fairly
> > straightforward calculation to show how much they can deviate
> before
> > problems are likely to start occurring. It is a significant amount > > though: from memory the figure is somewhere around
5% or so (I
> could
> > be way off on this figure). In other words, so long as your UART
> > clock is within 5% of the true value, you should be OK.
> >
> > Brendan
> >
>
> Hi Brendan,
>
> I think you are correct in your baud rate tolerance ~5%. I recall (on > some micros) the bit stream is over sampled and then
examined at a
> intermediate position within the following bits. I recall a Motorola > app note on this, I will poke around for it.
>
> I appreciate the time you took to investigate this, not sure why
> there is still dispute with your finding when there is no other data. >
> Regards,
> Ian
> (fellow Usual Suspect)
> This describes the sampling technique and is clear that the UARTs are
designed to tolerate variation in clock rates.
>From Philips App note AN10333:
-Quote-
One method most UARTs now employ to allow larger frequency deviation
of the baud rates is to over-sample the incoming data at 16 times the
baud rate to determine the near center of the start bit. Once this is
done, the next bit is sampled 16 clocks later. At 16over-sampling
of the incoming data, the UART typically allows about 5 % of
deviation (assume a byte consists of one start bit, 8 data bits, and
one stop bit) from its programmed baud rate value without causing any
receiving error due to the baud rate differentiation between the two
UARTs.
-End Quote-
AN10333: SC16CXXXB baud rate deviation tolerance,Rev. 02 6 December
2004
If someone would be kind enough to send Jaya some instructions for
using an oscilloscope, maybe Jaya could test his own timing, forward
the measurements, and we can see if it fits within the +/-5% range.
Most commercial crystals will have a max frequency tolerance of +/-
100ppm at 25C. This is 0.01%, and clearly would have no effect on
UART stability. Even if you can pull it way out of range with strange
cap values, I think you would still be less than 0.1%, not even close
to the +/-5%.
I expect we may get a conspiracy theory from Jaya next.
Maybe "Philips deliberately introduced flaws into the UART IP to
distract us from the ET programmers responsible for the
mysterious 'T' command in the boot loader"
Ian
Reply by "ian.scanlon"●July 19, 20062006-07-19
--- In l..., "brendanmurphy37"
wrote: >
> --- In l..., "jsm09a"
> yahoo.e35f5f@> wrote:
>
> > My compliments on your patience ;) One aspect that I haven't seen
> > addressed is possible dependence on differences in realized baud
> rates.
> >
> > In these tests, the source and destination will be sync'd to
> different
> > system clocks which may differ by an appreciable margin. I wonder > if
> > the conflicting results could be explained by differences in system > > clock rates.
> >
> > Given that there appears to be a problem with the LPC2XXX when it
> is
> > expecting two stop bits and receives only one, I wonder if a
> similar
> > problem might occur if the LPC2XXX was actually running at 275 baud > > while the sender was running at a full 300 baud
(resulting in a
> > "shorter" stop bit than expected).
> >
> > Just a thought. Best regards, Scott.
> > You're right of course - if the two clocks are out by an appreciable > amount, there is the possibility of timing errors.
>
> In a lot of cases, one or other (or both) sides are in fact out,
> particularly if an even base clock rate like 10 Mhz or so is used
> and the UART can only work of integer divisions of the base clock
> (i.e. not all rates will divide evenly, and the nearest integer
> value can be maybe 1 or 2% out).
>
> Asynchronous communication is designed to be tolerant of these
> differences: the clocks are effectively re-synched on each byte
> sent/received (usually on the falling edge of the start bit if my
> memory serves). Therefore the timing errors can only accumulate over > the length of one byte (say 10 bits or so). It's
a fairly
> straightforward calculation to show how much they can deviate before > problems are likely to start occurring. It is a
significant amount
> though: from memory the figure is somewhere around 5% or so (I could > be way off on this figure). In other words, so long
as your UART
> clock is within 5% of the true value, you should be OK.
>
> Brendan
>
Hi Brendan,
I think you are correct in your baud rate tolerance ~5%. I recall (on
some micros) the bit stream is over sampled and then examined at a
intermediate position within the following bits. I recall a Motorola
app note on this, I will poke around for it.
I appreciate the time you took to investigate this, not sure why
there is still dispute with your finding when there is no other data.
Regards,
Ian
(fellow Usual Suspect)
Reply by brendanmurphy37●July 19, 20062006-07-19
--- In l..., "jsm09a"
yahoo.e35f5f@...> wrote:
> My compliments on your patience ;) One aspect that I
haven't seen
> addressed is possible dependence on differences in realized baud rates. >
> In these tests, the source and destination will be sync'd to different > system clocks which may differ by an appreciable
margin. I wonder if > the conflicting results could be explained by
differences in system
> clock rates.
>
> Given that there appears to be a problem with the LPC2XXX when it is > expecting two stop bits and receives only one, I
wonder if a similar > problem might occur if the LPC2XXX was actually
running at 275 baud
> while the sender was running at a full 300 baud (resulting in a
> "shorter" stop bit than expected).
>
> Just a thought. Best regards, Scott.
>
You're right of course - if the two clocks are out by an appreciable
amount, there is the possibility of timing errors.
In a lot of cases, one or other (or both) sides are in fact out,
particularly if an even base clock rate like 10 Mhz or so is used
and the UART can only work of integer divisions of the base clock
(i.e. not all rates will divide evenly, and the nearest integer
value can be maybe 1 or 2% out).
Asynchronous communication is designed to be tolerant of these
differences: the clocks are effectively re-synched on each byte
sent/received (usually on the falling edge of the start bit if my
memory serves). Therefore the timing errors can only accumulate over
the length of one byte (say 10 bits or so). It's a fairly
straightforward calculation to show how much they can deviate before
problems are likely to start occurring. It is a significant amount
though: from memory the figure is somewhere around 5% or so (I could
be way off on this figure). In other words, so long as your UART
clock is within 5% of the true value, you should be OK.
Brendan
Reply by jsm09a●July 19, 20062006-07-19
--- In l..., "brendanmurphy37"
wrote:
> I've no doubt the results of your testing are
valid. However, nobody
> has been able to reproduce your "but drops characters at 19200 baud
> and below" failure mode.
Brendan,
My compliments on your patience ;) One aspect that I haven't seen
addressed is possible dependence on differences in realized baud rates.
In these tests, the source and destination will be sync'd to different
system clocks which may differ by an appreciable margin. I wonder if
the conflicting results could be explained by differences in system
clock rates.
Given that there appears to be a problem with the LPC2XXX when it is
expecting two stop bits and receives only one, I wonder if a similar
problem might occur if the LPC2XXX was actually running at 275 baud
while the sender was running at a full 300 baud (resulting in a
"shorter" stop bit than expected).
I've no doubt the results of your testing are valid. However, nobody
has been able to reproduce your "but drops characters at 19200 baud
and below" failure mode.
I've done extensive testing on the LPC2134: see the results I posted.
This testing included using your own test program. I've also had
private feedback from someone doing similar testing on the LPC2129
and LPC2294. All with the same result: no low bit rate problem.
I'd recommend you review your test setup. Are you sure your UART
register settings are correct? Are you sure the configuration of stop
bits is the same on both ends on the line? If so, there's a bit of a
mystery as to why the problem you see cannot be reproduced. Until it
can, I'd say that the most that can be said about your results and
conclusions is that they are unproven theories.
Brendan
Reply by jayasooriah●July 19, 20062006-07-19
--- In l..., "John Heenan" wrote: >
> 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
Hello John. I see you are back and bashing again :)
Perhaps you would like to explain why you expect an "apology".
Has anyone shown results or conclusions therein incorrect?
BTW, as the saying goes, blind testing does prove anything more than
that if close your eyes you will see your assumptions true!
Jaya
PS: Would be good if you could update on any progress you have with
your "sensible" request for boot loader feature that enables anyone to
lock up their parts in a deterministic way!
Reply by brendanmurphy37●July 19, 20062006-07-19
--- In l..., "John Heenan" wrote: >
> 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
>
Thanks for your acknowledgement - at least someone read the report!
I wouldn't be too hard on Jaya. I for one have learned two things:
1. LPC21xx UART seems to require 2 stop bits on the receive side.
Although this is what I'd always assumed, apparently this isn't
always the case with UARTs. I'd agree that the alternative (of
being "one-stop-bit tolerant" on the receive side) would be a better
approach. I've no idea how common this is though in UART designs.
Some more information would be useful here.
2. On misconfigured lines, not all errors seem to be reported: i.e.
in a burst of data you don't necessarily get the expected number of
good/bad/error data and status reports. Again, I don't find this
particularly surprising. In fact our standard UART driver (in common
with most I suspect) silently drops anything with an associated
error, relying instead on whatever protocol running over the line (if
any) to recover the lost data.
Both of these are useful findings to users and (I would imagine)
Philips.
I can't see any evidence that the original report of problems at low
speeds exists. I notice that the thread moved from this to a
discussion on stop bits, so maybe that turned out to be something
else? I guess there's a chance it could be present on some flavours
of the device rather than them all: all I know is that I haven't seen
any evidence for it in all the testing I've done.
By the way, I do agree with you on the tone of how issues like this
are presented and discussed. Apart from anything, the information
will get a much wider audience (including one from Philips) if it is
presented in a calm manner, with supporting evidence and without
hurling accusations about deeply flawed devices and abuse at anyone
who dares to suggest alternative explanations or has a different view.
Brendan.
Reply by John Heenan●July 19, 20062006-07-19
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.
>
