--- In l..., "jayasooriah" wrote:
>
> --- In l..., "Danish Ali" wrote:
> >
> > The problem here is that jayasooriah is the one with the
> > closed mind who likes to turn everything into a slinging
> > match whenever his (presumably deliberately) misleading
> > statements are questioned.
> >
> > By misusing the processors in a naive way he seems to
> > encounter problems which do not occur when things are
> > done correctly. And then he claims to be the only expert
> > on fixing those problems.
> >
> > I assume that he is trying to promote himself as a
> > consultant for these processors (either on his own or
> > on behalf of his employer). But his behavior creates
> > a bad impression of both himself and the University
> > of New South Wales.
> >
> > - Danish
>
> Danish,
>
> As off-topic as it is, I think the above is an excellent example of
> personal attack as it is full of (self gratifying and) gratuitous
> insults against the person making the point while making little or not
> contribution to the technical discussion.
>
> Kind regards,
>
> Jaya
>
The post was, and is still, labeled "off topic".
It also simply stated facts that all readers can see for themselves.
If that is percieved as a "personal attack" then there is probably
some problem at the perception end.

Whatever!
--Dave

An Engineer's Guide to the LPC2100 Series

--- In l..., "Danish Ali" wrote:
>
> The problem here is that jayasooriah is the one with the
> closed mind who likes to turn everything into a slinging
> match whenever his (presumably deliberately) misleading
> statements are questioned.
>
> By misusing the processors in a naive way he seems to
> encounter problems which do not occur when things are
> done correctly. And then he claims to be the only expert
> on fixing those problems.
>
> I assume that he is trying to promote himself as a
> consultant for these processors (either on his own or
> on behalf of his employer). But his behavior creates
> a bad impression of both himself and the University
> of New South Wales.
>
> - Danish

Danish,

As off-topic as it is, I think the above is an excellent example of
personal attack as it is full of (self gratifying and) gratuitous
insults against the person making the point while making little or not
contribution to the technical discussion.

Kind regards,

Jaya

--- In l..., "jayasooriah" wrote:
>
> --- In l..., "Brendan Murphy"
> wrote:
>
> > It took long enough the last time to establish that the bahviour
you
> > describe can only be observed on misconfigured lines.
>
> Wrong again!
>
> More specifically, on LPC2292 with 14.7456 MHz crystal, both PLL and
> MAM disabled, VPBDIV set to 1, UART set to 8-data 1-stop and no
> parity, it works at 230400 baud and above, but drops characters at
> 4800 baud and below.
>
> Have you configured your browser correctly -- it seems to be missing
> paragraphs :)
>
> Jaya
>

Jaya,

You're clearly not reading what I'm writing, but repeating your own
point over and over. Enough!

Brendan

The problem here is that jayasooriah is the one with the
closed mind who likes to turn everything into a slinging
match whenever his (presumably deliberately) misleading
statements are questioned.

By misusing the processors in a naive way he seems to
encounter problems which do not occur when things are
done correctly. And then he claims to be the only expert
on fixing those problems.

I assume that he is trying to promote himself as a
consultant for these processors (either on his own or
on behalf of his employer). But his behavior creates
a bad impression of both himself and the University
of New South Wales.

- Danish

--- In l..., "jayasooriah" wrote:
>
> --- In l..., "Brendan Murphy"
> wrote:
>
> > The issue documented by Jaya only manifests itself when the serial
> > ports configuration on each end of the line don't match (i.e. one is
> > configured with one stop bit, the other with two stop bits): one
> > would not expect this setup to work in any case. All that's being
> > observed with the different behaviour at different clocks are
> > different failure modes: there is no issue with different clocks on a
> > correctly configured line (i.e. one where the number of stop bits
> > match). As with any async serial line, the clocks can be out by up to
> > about 5% and still work correctly.
> >
> > Brendan
>
> Brendan is very clever at taking things out of context, and turning
> simple statement of findings into a never ending slinging match.
>
> Thankfully, the rest of us with open minds can read the statement of
> the problem in full in which I have stated:
>
> A relatively simple download using Philips Boot Loader on the above
> system connected to PC through FTDI FM232BM reveals that the Boot
> Loader itself suffers from character loss problem.
>
> Jaya
>

--- In l..., "Brendan Murphy"
wrote:

> It took long enough the last time to establish that the bahviour you
> describe can only be observed on misconfigured lines.

Wrong again!

More specifically, on LPC2292 with 14.7456 MHz crystal, both PLL and
MAM disabled, VPBDIV set to 1, UART set to 8-data 1-stop and no
parity, it works at 230400 baud and above, but drops characters at
4800 baud and below.

Have you configured your browser correctly -- it seems to be missing
paragraphs :)

Jaya

--- In l..., "jayasooriah" wrote:
>
> --- In l..., "Brendan Murphy"
> wrote:
>
> > The issue documented by Jaya only manifests itself when the
serial
> > ports configuration on each end of the line don't match (i.e. one
is
> > configured with one stop bit, the other with two stop bits): one
> > would not expect this setup to work in any case. All that's being
> > observed with the different behaviour at different clocks are
> > different failure modes: there is no issue with different clocks
on a
> > correctly configured line (i.e. one where the number of stop bits
> > match). As with any async serial line, the clocks can be out by
up to
> > about 5% and still work correctly.
> >
> > Brendan
>
> Brendan is very clever at taking things out of context, and turning
> simple statement of findings into a never ending slinging match.
>

Jaya,

I wasted enough time on this the last time this issue was raised. I
am happy to stand over my statement above, in the absense of any
independent verification of your claims.

It took long enough the last time to establish that the bahviour you
describe can only be observed on misconfigured lines.

If anyone can provide any evidence of the failure mode you describe
where the line is configured correctly (i.e. with matching stop bits)
then it would be worth investigating further. Otherwise the behaviour
you've observed is only of academic interest.

Brendan

--- In l..., "Brendan Murphy"
wrote:

> The issue documented by Jaya only manifests itself when the serial
> ports configuration on each end of the line don't match (i.e. one is
> configured with one stop bit, the other with two stop bits): one
> would not expect this setup to work in any case. All that's being
> observed with the different behaviour at different clocks are
> different failure modes: there is no issue with different clocks on a
> correctly configured line (i.e. one where the number of stop bits
> match). As with any async serial line, the clocks can be out by up to
> about 5% and still work correctly.
>
> Brendan

Brendan is very clever at taking things out of context, and turning
simple statement of findings into a never ending slinging match.

Thankfully, the rest of us with open minds can read the statement of
the problem in full in which I have stated:

A relatively simple download using Philips Boot Loader on the above
system connected to PC through FTDI FM232BM reveals that the Boot
Loader itself suffers from character loss problem.

Jaya

--- In l..., Tom Walsh wrote:

> > Hi Koorosh,
> >
> > I found problems with UART implementation on LPC2292 that manifest as
> > dropping characters silently at certain particular baudrates. The
> > problem went away when I changed the baudrate slightly. For example
> > it shows up at 300 baud, but not at 301 baud.
> >
> > I documented this some time ago here:
> >
> > http://www.cse.unsw.edu.au/%7Ejayas/esdk/lpc2/limitations.html
> >
> > Try changing the baudrate by a little and see if the problem goes
away.
> > That sounds to me like the PLL reference crystal is off slightly.
> Maybe by, using a the wrong crystal. Did you check this against
> a oscillator source?
>
> TomW
>

Hi Tom

If you look at my explanation here:

I wrote a simple test program to show that if the UART is configured
to expect 8 data and 2 stop bits, and the host sends only one stop
bits, and if the baud rate is 299 or 301, the LPC UART works correctly
in that it detects and reports framing errors. However at exactly 300
baud, it silently drops characters, and does not report any errors.

and here:

This same behaviour is also observed at 9600 baud when the deviation
is for 0.5 percent, for example between 9550 and 9650 baud.

To answer your question directly, I think it was Leon who said I
should check crystal frequency first and I did. It was as correct as
one can expect it to be to 6 digit resolution (old but faithful HP
with oven controlled reference) I used.

You will note that UART is not the only peripheral that has this kind
of ("race") problems. PWM is documented as suffering from the similar
problems. If you look at errata in this context, you would think
there is generic problem at the peripheral bus implementation as to
how asynchronous updates of the status registers are synchronised with
to bus reads/writes.

Becuase the problem is hard to replicate (as it manifests itself in a
dead band of only 0.5 percent), it is hard to prove without having a
lot of faith in the test environment. However we have seen enough
reports from various people that leaves no doubt in my mind that the
problem is real.

Regards,

Jaya

--- In l..., Jan Fristedt wrote:
> > > I found problems with UART implementation on LPC2292 that
manifest
> > > as dropping characters silently at certain particular
baudrates. The
> > > problem went away when I changed the baudrate slightly. For
example
> > > it shows up at 300 baud, but not at 301 baud.
> > >
> > > I documented this some time ago here:
> > >
> > > http://www.cse. unsw.edu. au/~jayas/ esdk/lpc2/ limitations.
html
> > >
> > >
> > > Try changing the baudrate by a little and see if the problem
goes
> > > away.
> > >
> >
> > That sounds to me like the PLL reference crystal is off slightly.
> > Maybe by, using a the wrong crystal. Did you check this against a
> > oscillator source?
> >
> > TomW
> >
> > Maybe I'm completely off but I had a similar problem with UART
> interrupts in the LPC2106.
>
> After searching the net I found a recommendation that since the
> interface between the UART and the interrupt controller is broken
it's
> better to use a timer interrupt to poll the UART.
> I tried this and my problem disappeared.
>
> I have to admit that I don't know if the problem really was in the
> silicon or if it was just me not understanding how to use it :*)
>
> /Janne
>

The problem is almost certainly in the software: it's perfectly
possible to write a driver that used the normal UART interrupts that
works correctly. There are the usual quirks with dealing with any
16550 type UART, and a couple of documented issues (see the errata
for the relevant parts), but apart from that they work just fine.

I'd assume that there are plenty of examples of UART driver code for
the parts that are readily available at this stage. Depending on
licensing, these could either be used directly or used as a guide to
getting a working driver (maybe someone could recommend a specific
one?).

The issue documented by Jaya only manifests itself when the serial
ports configuration on each end of the line don't match (i.e. one is
configured with one stop bit, the other with two stop bits): one
would not expect this setup to work in any case. All that's being
observed with the different behaviour at different clocks are
different failure modes: there is no issue with different clocks on a
correctly configured line (i.e. one where the number of stop bits
match). As with any async serial line, the clocks can be out by up to
about 5% and still work correctly.

Brendan

On Mon, 30 Apr 2007 03:01:26 -0400
Tom Walsh wrote:

> jayasooriah wrote:
> >
> > --- In lpc2000@yahoogroups .com ,
> > "kooroshhajiani" wrote:
> > >
> > > Hello every one,
> > >
> > > I'm having a peculiar issue with uart Rx unterrupt.
> > > I'm running at 9600bps and keep recieving streams of bytes sent
> > > to me via an RS232 port, so far so good however for every 240
> > > bytes(char)I miss 4 bytes or so every time and this is like
> > > clockwork.I thought maybe some other higher priority interrupt
> > > preempts this one so I killed all the other ones. then I
> > > configured my Rx interrupt to use the fifo feature of the UART (8
> > > BYTE DEPTH), It does not work. I keep loosing 4 bytes for every
> > > 240 bytes that I'm receiving. At one point I thought may be the
> > > transmitter is failing in sending those missing bytes so I
> > > switched to a different one, It was not that.I don't know what to
> > > do next.I appriciate all the suggestions.
> > >
> > > Regards,
> > > Koorosh
> > >
> >
> > Hi Koorosh,
> >
> > I found problems with UART implementation on LPC2292 that manifest
> > as dropping characters silently at certain particular baudrates. The
> > problem went away when I changed the baudrate slightly. For example
> > it shows up at 300 baud, but not at 301 baud.
> >
> > I documented this some time ago here:
> >
> > http://www.cse. unsw.edu. au/~jayas/ esdk/lpc2/ limitations. html
> >
> >
> > Try changing the baudrate by a little and see if the problem goes
> > away.
> > That sounds to me like the PLL reference crystal is off slightly.
> Maybe by, using a the wrong crystal. Did you check this against a
> oscillator source?
>
> TomW

Maybe I'm completely off but I had a similar problem with UART
interrupts in the LPC2106.

After searching the net I found a recommendation that since the
interface between the UART and the interrupt controller is broken it's
better to use a timer interrupt to poll the UART.
I tried this and my problem disappeared.

I have to admit that I don't know if the problem really was in the
silicon or if it was just me not understanding how to use it :*)

/Janne