[#4436] BF527-EZKIT unable to receive large files over UART in DMA mode
Submitted By: Mike Frysinger
Open Date
2008-09-22 19:36:26 Close Date
2008-09-29 18:13:48
Priority:
High Assignee:
Sonic Zhang
Status:
Closed Fixed In Release:
N/A
Found In Release:
N/A Release:
2.6.26.5 trunk 5323
Category:
N/A Board:
EZKIT Lite
Processor:
BF527 Silicon Revision:
0.0
Is this bug repeatable?:
Yes Resolution:
Fixed
Uboot version or rev.:
Toolchain version or rev.:
App binary format:
N/A
Summary: BF527-EZKIT unable to receive large files over UART in DMA mode
Details:
using current trunk and default configuration, sending kallsyms to the board over the UART console drops some bytes
to reproduce:
- build default image (make AnalogDevices/BF527-EZKIT_default)
- boot default image
- rcp the /proc/kallsyms file off the board and onto host
- run `cat > kallsyms` on the serial console
- close serial console
- run `cat kallsyms > /dev/ttyS0` on the host (obviously change /dev/ttyS0 to whatever your linux development machine uses)
- run `diff` on the board between /kallsyms and /proc/kallsyms
- notice some large chunks in the middle were lost
Follow-ups
--- Robin Getz 2008-09-23 10:48:11
bumping up the priority.
--- Greg Semeraro 2008-09-24 08:38:26
One additional data point...I have see Rx data lost at data rates as low as 9600
baud in both DMA and PIO mode. I have seen this on a 526 v0.1 silicon and 527
v0.1 and v0.2 silicon. I am sending only small amounts of data (approximately
50 characters at a time) and the lost character is always the first in the
string.
Greg
--- Sonic Zhang 2008-09-25 02:30:54
Fixed
--- Greg Semeraro 2008-09-25 07:31:54
Can you please provide details regarding the source code files that were changed
so that I can integrate them into my system?
Thanks,
Greg
--- Robin Getz 2008-09-25 10:19:26
Greg:
No.
That is why we use svn. You can check things yourself.
docs.blackfin.uclinux.org/doku.php?id=version_control_systems
look at the svn log command.
The only thing Sonic forgot to say, was where things were fixed. It should have
been "Fixed on trunk and 2008R1 and 2007R1 branches".
--- Robin Getz 2008-09-25 10:38:42
However, it looks like Sonic misapplied the fix to the branch - so this is still
broken.
CC drivers/serial/bfin_5xx.o
drivers/serial/bfin_5xx.c: In function ‘bfin_serial_start_tx’:
drivers/serial/bfin_5xx.c:98: warning: unused variable ‘flags’
drivers/serial/bfin_5xx.c: At top level:
drivers/serial/bfin_5xx.c:385: error: expected identifier or ‘(’ before
‘do’
drivers/serial/bfin_5xx.c:385: error: expected identifier or ‘(’ before
‘while’
drivers/serial/bfin_5xx.c: In function ‘bfin_serial_dma_tx_chars’:
drivers/serial/bfin_5xx.c:432: error: ‘flags’ undeclared (first use in this
function)
drivers/serial/bfin_5xx.c:432: error: (Each undeclared identifier is reported
only once
drivers/serial/bfin_5xx.c:432: error: for each function it appears in.)
make[2]: *** [drivers/serial/bfin_5xx.o] Error 1
Sonic?
--- Greg Semeraro 2008-09-25 10:44:25
Right. If he doesn't say where in subversion he made the changes it is a needle
in the haystack. He he posts "Fixed in...." responses there is no
problem but posting "Fixed" doesn't help anyone.
--- Mike Frysinger 2008-09-25 14:48:25
it isnt a needle at all. if there's a bug in the serial driver, then the
changes will be in the serial driver. or you just look at the svn log for the
tree and it'll be in the last few revs.
--- Sonic Zhang 2008-09-26 00:29:05
Patch built against trunk not fit 2008R1 and 2007R1. Should be corrected now.
--- Mike Frysinger 2008-09-29 19:13:48
just tested trunk and it works for me now, thanks
--- Greg Semeraro 2008-09-30 07:35:50
I have tested this on a 526 and I am still seeing dropped Rx characters in DMA
mode. The characteristics have changed in two ways: 1) the failures are less
frequent and 2) the first character is no longer the character that is lost, now
it is the 2nd and some of the next 10-15 characters. I have tested this in my
baseline, 2008R1, at 9600 baud and 57600 baud. When I configure the UART ports
for PIO mode I do not see dropped characters.
--- Robin Getz 2008-09-30 13:50:05
Greg:
We need a test case - saying how it doesn't work, doesn't help replicate a
failure. We can transfer data in both directions (at the same time) and not see
a failure in PIO or DMA modes.
-Robin
--- Greg Semeraro 2008-10-07 16:22:18
My test setup is as follows: BF-526 connected to an MSP430 where the 526 sends
commands to and receives responses from the MSP430 over the serial link. The
processors are about 1.5 inches apart on the same PWB. Only Tx and Rx are
connected between the processors (logic signals only, there are no RS232 drivers
between the processors); they share a common ground plane and there is no flow
control (i.e., RTS / CTS are not used - we don't have the pins and don't believe
that we should need RTS/CTS). The most appropriate test setup that I can think
of for you to be able to replicate would be using a PC and the EZKIT with only
Tx, Rx and ground connected between the machines. I have the 526 and the MSP430
configured for 57600 baud 8N1 using PIO (hard configuration, no auto-bauding).
Simultaneous to the serial data I have an 802.11 wireless NIC on the USB port of
the 526. I see the dropped characters only when the USB NIC is connected (in
PIO mode, in DMA mode I see the dropped serial characters even if the USB NIC is
not connected). The USB NIC sees beacons at 100msec intervals; the USB NIC also
sees data traffic in both directions (much more going than coming). The
failures occur when both devices are active; I have not been able to correlate
USB traffic with the failure but given the amount of traffic on each interface I
have to believe that there is simultaneous traffic more often than I am seeing
the dropped characters. I'm not sure how much more specific I can be but if
there is some additional information that would be useful I would be happy to
provide any additional information that I have, just let me know.
Greg
--- Greg Semeraro 2008-10-08 12:01:44
One other thing....the serial port is being used in raw mode as follows:
/* Initialize the data structure that will be used to configure the port */
memset(&NewTermios, 0, sizeof(NewTermios));
/* Set the port configuration parameter values:
CLOCAL = local connection, no modem contol
CREAD = enable receiving characters */
NewTermios.c_cflag = CLOCAL | CREAD | BaudRate | Protocol;
/* Set the input-specific flags:
IGNPAR = ignore bytes with parity errors and breaks (Blackfin issue with
break) */
NewTermios.c_iflag = IGNPAR | IGNBRK;
/* Set the output-specific flags: None, raw output */
NewTermios.c_oflag = 0;
/* Set the input mode: non-canonical, no echo, no signals */
NewTermios.c_lflag = 0;
/* Initialize all of the control characters, default values are given in the
comments but are really not needed. In non-canonical mode the only ones
that
matter are VTIME and VMIN since input processing is not being done. */
NewTermios.c_cc[VINTR] = 0; /* Ctrl-c */
NewTermios.c_cc[VQUIT] = 0; /* Ctrl-\ */
NewTermios.c_cc[VERASE] = 0; /* del */
NewTermios.c_cc[VKILL] = 0; /* @ */
NewTermios.c_cc[VEOF] = 0; /* Ctrl-d */
NewTermios.c_cc[VTIME] = 0; /* inter-character timer unused */
NewTermios.c_cc[VMIN] = 1; /* blocking read until 1 character arrives
*/
NewTermios.c_cc[VSWTC] = 0; /* '\0' */
NewTermios.c_cc[VSTART] = 0; /* Ctrl-q */
NewTermios.c_cc[VSTOP] = 0; /* Ctrl-s */
NewTermios.c_cc[VSUSP] = 0; /* Ctrl-z */
NewTermios.c_cc[VEOL] = 0; /* '\0' */
NewTermios.c_cc[VREPRINT] = 0; /* Ctrl-r */
NewTermios.c_cc[VDISCARD] = 0; /* Ctrl-u */
NewTermios.c_cc[VWERASE] = 0; /* Ctrl-w */
NewTermios.c_cc[VLNEXT] = 0; /* Ctrl-v */
NewTermios.c_cc[VEOL2] = 0; /* '\0' */
/* Clear any data out of the port that might be left over from before */
if (0 != tcflush(*FileDescriptor, TCIFLUSH))
{
perror("SerialPort_Initialize() Unable to flush serial port!");
/* NOTE: Early return (sorry) */
return -1;
} /* if() */
/* Activate the new port settings */
if (0 != tcsetattr(*FileDescriptor, TCSANOW, &NewTermios))
{
perror("SerialPort_Initialize() Unable to set new serial port
settings!");
/* NOTE: Early return (sorry) */
return -1;
} /* if() */
--- Robin Getz 2008-10-08 13:41:04
That is what we have:
BF527 <-> PC. No flow control - Data going in both directions and no lost
characters.
This seems to replicate your test case.
Can you recreate anything on an EZkit?
--- Greg Semeraro 2008-10-08 13:59:06
I have not tried to replicate with the EZKIT, that is non trivial to setup. Are
you using raw or cooked mode? I posted our initialization code above.
--- Robin Getz 2008-10-09 13:54:39
The test case we looked at was described in the original bug description
(above).
Plus - raw or cooked mode does not effect anything in the driver. That is
handled at a different (architecture independent) layer in the kernel.
The whole idea on getting a reproducible test case is not that you replicate
your exact setup on an EZkit - it is that you approximate it with a similar
workload (not doing the same thing - just the load needs to be the same).
--- Sonic Zhang 2008-10-13 05:46:24
Could you try the serial driver in latest branch again? Last commit may solve
your problem.
--- Greg Semeraro 2008-10-14 08:35:56
Tried it - 57600 8N1. In PIO mode I have not seen a problem since I changed the
UART interrupt levels to be higher than USB (Thanks Jorge). In DMA mode I still
see the first character dropped; It doesn't happen often (last test ran
successfully for over 5 hours) but it eventually drops a character.
--- Robin Getz 2008-10-14 20:08:29
Greg:
When you say "drop" do you mean :
- Rx - Blackfin doesn't receive a char the other side sent?
- Tx - the other side doesn't receive a char your userspace app sent?
-Robin
--- Adam Cook 2008-10-15 11:30:10
Greg,
Also, have you tried the specific test outlined here on the EZ-Kit with your
USB stick connected? Or maybe if you modify the test for a much longer file we
would be able to reproduce the failure on our side?
Adam
--- Sonic Zhang 2008-10-17 02:08:47
This bug is finally root caused.
2d dma is used in serial driver. The dma register curr_x_count and curr_y_count
can't be read as an atomic operation. curr_y_count is read before curr_x_count.
When curr_x_count is read, curr_y_count may move to next line. But, the position
calculated still indicate a byte in the original line and may be smaller than
the buffer tail in the same line. This cause garbages are received from buffer
tail loop to the wrong position in the ring.
New solution is to ignore this case in dma rx handler. Applied to 2008R1 branch
and trunk.
Files
Changes
Commits
Dependencies
Duplicates
Associations
Tags
File Name File Type File Size Posted By
No Files Were Found