--- 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.
Re: LPC2000 UART drops characters silently?
Started by ●July 14, 2006
Reply by ●July 19, 20062006-07-19
Reply by ●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".
My findings are well documented at:
http://www.cse.unsw.edu.au/~jayas/esdk/lpc2/limitations.html
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!
>
> 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".
My findings are well documented at:
http://www.cse.unsw.edu.au/~jayas/esdk/lpc2/limitations.html
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 ●July 19, 20062006-07-19
--- In l..., "jayasooriah" wrote:
> My findings are well documented at:
>
> http://www.cse.unsw.edu.au/~jayas/esdk/lpc2/limitations.html
>
> Has anyone shown results or conclusions therein incorrect?
>
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
> My findings are well documented at:
>
> http://www.cse.unsw.edu.au/~jayas/esdk/lpc2/limitations.html
>
> Has anyone shown results or conclusions therein incorrect?
>
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 ●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).
Just a thought. Best regards, Scott.
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).
Just a thought. Best regards, Scott.
Reply by ●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
> 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 ●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)
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 ●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
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 ●July 19, 20062006-07-19
[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".
My findings are well documented at:
http://www.cse.unsw.edu.au/~jayas/esdk/lpc2/limitations.html
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!
--- 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".
My findings are well documented at:
http://www.cse.unsw.edu.au/~jayas/esdk/lpc2/limitations.html
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 ●July 20, 20062006-07-20
--- In l..., "jayasooriah" wrote:
> 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.
I must crack on I have real products to Design.
> 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.
I must crack on I have real products to Design.
