[prev in list] [next in list] [prev in thread] [next in thread]
List: uclinux-dev
Subject: [uClinux-dev] M5249C3: Data Corruption on Serial Ports
From: Paul Romero <paulr () rcom-software ! com>
Date: 2007-01-30 3:23:33
Message-ID: 45BEBA35.68FA766B () rcom-software ! com
[Download RAW message or body]
Dear User Group:
This message describes the corruption that occurs when
ttyS0 is configured for 19200 baud, and ttyS1 is configured for
115200 baud and connected to an Enfora SAGL 1218 GPRS/RF
modem. It has two parts. The first part covers what I see as the most
likely causes based on previous investigation. The second part
clarifies
the details of the hardware configuration, driver buffers, etc.
Also, note that UC Linux 2.4.x kernel is being used and
the version 2.24.47--pretty much "out of the box".
Keep in mind that--previously--severe oscillations
of some RS-232 junction signals have been observed on UART1/ttyS1
when it connected to the modem.
These are the phenomena I think are most likely to be
responsible for the problem, and their potential causes.
UART1/ttyS1: Connects M5249C3 and Modem.
* Overrun by data arriving from the modem.
POTENTIAL CAUSES: RTS flow control is not deasserted when
the UART receive FIFO is full, RTS is not properly propagated
to the modem, the modem responds to RTS desertion too slowly.
A bug in the Linux driver. Perhaps the driver does not remove
data from the FIFO fast enough or somehow interferes with
correct RTS flow control operation.
Note that "interrupt latency" combined with slow detection
of RTS de-assertion by the modem is a likely cause
according to Greg Ungerer.
* Data is corrupted during transfer between the UART and driver buffer.
POTENTIAL CAUSES: Hardware or a driver bug. A non-atomic transfer
of data between the UART FIFO and driver buffer is interrupted.
(i.e. Operation is interrupted in the midst of a byte transfer.)
* Data in the UART is corrupted.
POTENTIAL CAUSES: Hardware bug. Data is corrupted during
transfer from the shift register to the FIFO, or between
the FIFO holding registers. The operation of the shift
register is interrupted while bits are being assembled
into a byte.
UART0/ttys0: Connects M5249C3 and the PC--running Hyperterminal.
* Overrun by data written by the M5249C3.
POTENTIAL CAUSES: The driver continues writing data to the
UART when the FIFO is full. The UART generates a receive
interrupt, or does not correctly set the status bit, when
the FIFO is full. It seems unlikely interrupts are a factor but
there is some chance the driver doesn't detect the FIFO
is full soon enough.
* Data is corrupted during transfer between the driver buffer and UART.
POTENTIAL CAUSES: A non-atomic byte transfer between the driver
buffer and the FIFO is interrupted in the midst of the transfer.
Hardware or driver bug. Interrupts from another device--particularly
UART1--could play a role.
* Data in the UART is corrupted.
POTENTIAL CAUSES: Something disrupts the transfer of
data between the FIFO and shift register. The operation
of transferring bits out of the shift register is interrupted.
A hardware bug is the most likely explanation and interrupts
could play a role in this case.
The following 4 sections briefly--and I hope accurately--
describe the factors I believe are relevant to the problem.
1 - DATA FLOW: The flow of data between the PC, M5249C3, and Modem.
(i.e. Modem is the Enfora SAGL 1218 RF/GPRS modem.)
2 - UART & DRIVER STRUCTURE: UART architecture, operation,
and Linux driver interface.
3 - SERIAL PORT CONFIGURATION: How the serial ports are configured
and connected.
4 - TYPICAL EXAMPLES: Examples of good and corrupt data exchanges.
1) DATA FLOW
------------
1.1) Bytes manually entered in Hyperterminal--
running on the PC--are sent to the M5249C3--via UART0/ttyS0.
(i.e. Strings such as "AT<CR>" and "AT+CSQ<CR>".)
1.2) The M5249C3 sends the bytes to the Modem--via UART1/ttyS1.
1.3) The Modem sends bytes to the M5249C3--via UART1/ttyS1.
(i.e. Both echoed and self generated bytes.)
1.4) The M5249C3 sends bytes to to the PC--which are displayed
by Hyperterminal--via UART0/ttyS0.
2) UART & DRIVER STRUCTURE
--------------------------
Transmit: 1 Byte FIFO--consisting of a holding register, and
a 1 Byte Shift register used to transmit a bit stream.
Data stored in the ->xmit_buf--a buffer of 4096 bytes--
is transferred to the FIFO when a transmit interrupt
occurs as long as the FIFO is empty. (i.e. We assume
4096 bytes is also the size of a Linux kernel page.)
Note that the ->xmit_buf is a dynamically allocated
buffer. Also, for UART1, CTS flow control is programmed in UMR2
such that characters are not sent unless CTS is asserted.
Receive:
1 Byte Shift register used to receive a bit stream,
and a 3 Byte FIFO--consisting of 3 holding registers.
Valid data is transferred from the FIFO to the flip.char_buf[]
buffer--size 1024 bytes--when a receive interrupt occurs
as long as the FIFO has at least one character and the
flip.char_buf[] has less than 512 characters. Note, the
status bits corresponding to each byte are stored in the
flip.flag_buf[] which is 1024 bytes. Also, for UART1, RTS
flow control is programmed in UMR1 such that RTS is
automatically asserted when the UART FIFO is not full.
3) SERIAL PORT CONFIGURATION
----------------------------
Console: ttyS0 - UART0: Interrupt Priority 1 Level 6.
Speed 19200 baud. M5249C3 is connected to a PC serial port,
and the PC is running Hyperterminal or an equivalent application.
8 Bits, No Parity, 1 Stop Bit, No Flow Control.
Stdin--from PC to M5249C3--is in non-blocking mode.
Stdout--from M5249C3--is in default blocking mode.
Modem: ttyS1 - UART1: Interrupt Priority 2 Level 6.
Speed 115200 baud. M5249C3 is connected to
an Enfora 1218 SAGL GPRS/RF modem.
8 Bits, No Parity, 1 Stop Bit, RTS/CTS Flow Control.
Bi-directional non-blocking raw mode.
4) TYPICAL EXAMPLES
--------------------
Notes: <CR><LF> not explicitly shown in the examples.
Also, these examples are not exactly the same as
the captured data samples. Instead, they are
just meant to illustrate what happens.
4.1) Good AT command and response.
PC M5249C3 MODEM
AT ==>
<== AT
<== OK
4.2) Bad AT command and response.
PC M5249C3 MODEM
AT ==>
<== @T
<== OO
4.3) Good AT+CSQ command and response.
PC M5249C3 MODEM
AT+CSQ ==>
<== AT+CSQ
<== +CSQ: 12,99
4.4) Bad AT+CSQ command and response.
PC M5249C3 MODEM
AT+CSQ ==>
<== AT+C%.Q
<== &*!.#x$*,99
Best Regards,
Paul R.
--
Paul Romero
RCOM Communications Software
Phone/Fax: (510)339-2628
E-Mail: paulr@rcom-software.com
_______________________________________________
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic