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 Start a New Thread

The first thing I'd do is send a "known" byte stream to your ARM.
Have the arm toggle a pin when the stream changes from the expected,
use that to trigger your scope that is also probing your rx line.

Or, try feeding that transmission into your PC, or if it's coming from
your PC, feed it in to a different serial port and rule out the uart
driver on the PC.

Unless you've got some really long interrupts, you shouldn't have any
trouble receiving at 9k6. Have a look on the ARM and see if there are
any overflow flags - I think there are but can't remember for sure.

Just some ideas...
--- In l..., "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
> Start a New Thread

--- In l..., "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.

Regards,

Jaya Start a New Thread

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
--
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net http://cyberiansoftware.com http://openzipit.org
"Windows? No thanks, I have work to do..."
---------------- Start a New Thread

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 Start a New Thread

--- 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 Start a New Thread

--- 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 Start a New Thread

--- 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 Start a New Thread

--- 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 Start a New Thread

--- 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 Start a New Thread