From: "Albrecht Dreß" <albrecht.dress@arcor.de>
To: Henk Stegeman <henk.stegeman@gmail.com>
Cc: Linux PPC Development <linuxppc-dev@ozlabs.org>
Subject: Re: [OT - MPC5200B] strange framing, break problems with uart
Date: Wed, 02 Mar 2011 21:16:36 +0100 [thread overview]
Message-ID: <1299097003.1795.0@antares> (raw)
In-Reply-To: <AANLkTi=gqFLtM7f01GFVKdSibxz4q5J9LtHrpOcH_1ta@mail.gmail.com> (from henk.stegeman@gmail.com on Tue Mar 1 23:28:47 2011)
[-- Attachment #1: Type: text/plain, Size: 2015 bytes --]
Hi Henk:
Am 01.03.11 23:28 schrieb(en) Henk Stegeman:
> Today I noticed corrupted and missing chunks of data on the 5200 with the 2.6.37 uart driver in 2.6.37.
> I don't have these problems when I use the driver from 2.6.33 (with minor changes to make it fit in 2.6.37).
Hmm, I hope it's not related to my my baud rate divisor selection patch... :-/
> While looking for a reason/solution online I came across your problem report. I hope to investigate my problem further soon, but was also wondering if you found a cause/early solution for your problem yet, just in case they could be related.
Well, my problem occurs when the '5200B is connected to a FTDI usb/serial converter (FT2232D) chip, and when both are configured to use rts/cts hw handshake.
After some discussions with Freescale's and FTDI's support, the reason seems to be that the FTDI chips continues to send zero up to 4 chars *after* the RTSn line has been deactivated by the '5200B (actually, this is the behaviour of many uart's). However, the manual says that the '5200B should report overruns (and not breaks and/or framing errors) in this case. Although I asked several times, the guy at Freescale did not say a word about this, but just blamed FTDI. So, at best their manual is plain wrong... Interestingly, if I switch rts/cts off, I *do* get overrun errors. Strange!
The solution for me seems to write my own driver - as I know (unlike "usual" serial connections) the packet sizes I expect, I can utilise the PSC's fifo and issue an IRQ when it's almost (FIFO size minus 16 chars seems to be bullet-proof after first tests even at 3 MBaud) full. In the ISR I /manually/ deactivate RTSn, a tasklet empties the FIFO and asserts RTSn again. As a positive side effect, it drastically reduces the number of interrupts. Using Bestcomm would probably be better, but I didn't get it working (still get the cpu irq's, and the task doesn't run).
Not sure if this information is helpful for you...
Cheers,
Albrecht.
[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]
next parent reply other threads:[~2011-03-02 20:16 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <AANLkTi=gqFLtM7f01GFVKdSibxz4q5J9LtHrpOcH_1ta@mail.gmail.com>
2011-03-02 20:16 ` Albrecht Dreß [this message]
2011-03-02 21:08 ` [OT - MPC5200B] strange framing, break problems with uart Wolfram Sang
2011-02-03 18:34 Albrecht Dreß
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1299097003.1795.0@antares \
--to=albrecht.dress@arcor.de \
--cc=henk.stegeman@gmail.com \
--cc=linuxppc-dev@ozlabs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).