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

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

[Albrecht Dreß]

[-- 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 --]

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

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 602 bytes --]

> 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).

Russell described this behaviour nicely here:

http://www.spinics.net/lists/linux-serial/msg02136.html

From that point of view, FTDI is not to blame.

Regards,

   Wolfram

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

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

[Albrecht Dreß]

[-- Attachment #1: Type: text/plain, Size: 1210 bytes --]

Hi all,

sorry for a slightly off-topic question, but I hope someone here on the list may be able to help me...

I have a strange problem with the psc uart of the mpc5200b, running 2.6.32.26 (still), with my baud rate divisor selection patch [1].

The uart runs at 115.2 kBaud with rtc/cts handshake to send bigger chunks of data to the '5200.  I noticed "missing" data in the input stream, and inspected the uart status using the TIOCGICOUNT ioctl which tells me that a bunch of framing and break errors occurred.  I "tapped" the RxD line and connected it via a level shifter to a standard 16450-style uart in a (much faster) Linux PC, and *that* one receives the *complete* stream *without any* break or framing errors!

I also looked at the waveforms with an oscilloscope, and they look pretty fine.  The port configuration should also be ok, re-checked with a bdi3000 jtag debugger - it's PSC3, set to '1100', with PSC3_0 .. PSC3_3 being used here.

This leads me to the assumption that either the hardware handshake or the Linux driver or both are broken...  any insight would be highly appreciated!

Cheers,
Albrecht.


[1] <http://patchwork.ozlabs.org/patch/48884/>; included in 2.6.37

[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]