[OT - MPC5200B] strange framing, break problems with uart

[Albrecht Dreß]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20110302/6340cda6/attachment.pgp>