[#4436] BF527-EZKIT unable to receive large files over UART in DMA mode

Document created by Aaronwu Employee on Aug 29, 2013
Version 1Show Document
  • View in full screen mode

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


High     Assignee:

Sonic Zhang


Closed     Fixed In Release:


Found In Release:

N/A     Release: trunk 5323


N/A     Board:



BF527     Silicon Revision:


Is this bug repeatable?:

Yes     Resolution:


Uboot version or rev.:

    Toolchain version or rev.:

App binary format:


Summary: BF527-EZKIT unable to receive large files over UART in DMA mode



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




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





--- Sonic Zhang                                              2008-09-25 02:30:54



--- 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?





--- Robin Getz                                               2008-09-25 10:19:26





That is why we use svn. You can check things yourself.



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



  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


drivers/serial/bfin_5xx.c:385: error: expected identifier or ‘(’ before


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


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




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



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.




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


     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


     /* 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



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



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



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?




--- Adam Cook                                                2008-10-15 11:30:10


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?




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












File Name     File Type     File Size     Posted By

No Files Were Found