2008-07-08 10:39:55     external 8250 send ok but recv none

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

2008-07-08 10:39:55     external 8250 send ok but recv none

Jian Ju (HONG KONG)

Message: 58488   

 

Hi all,

 

I add a 16c2550 chip to the bf537 board. I changed the stamp.c file to allow the driver to mount automatically when the system boot up. The problem is that it can transmit data properly but can't receive any data from PC. I tested it by writing a small program to send 512 data and then expect to receive some data. You might be interested to look into the simple uart test program, which has been attached with this thread. I also tried echo "123456" > /dev/ttyS1, it works but cat /dev/ttyS1, no output.  The followings are some useful infomation that print out from the proc.

 

root:/proc/tty/driver> stty -F /dev/ttyS1 -a

speed 9600 baud; rows 24; columns 80;

intr = <undef>; quit = <undef>; erase = <undef>; kill = <undef>; eof = <undef>;

eol = <undef>; eol2 = <undef>; start = <undef>; stop = <undef>; susp = <undef>;

rprnt = <undef>; werase = <undef>; lnext = <undef>; flush = <undef>;

min = 0; time = 0;

-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts

-ignbrk -brkint ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff

-iuclc -ixany -imaxbel

-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0

ff0

-isig icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop

-echoprt -echoctl -echoke

 

root:/proc/tty/driver> cat serial

serinfo:1.0 driver revision:

0: uart:16550A mmio:0x20100010 irq:55 tx:0 rx:0 CTS|DSR|CD|RI

1: uart:16550A mmio:0x20100020 irq:55 tx:1024 rx:65 CTS|DTR

 

Above is the information after I transmit 512*2 bytes data. On another computer I let it to continuely send 1 byte every 1 second. It seems the data has been captured by blackfin, as can be seen from the 'rx: 65'. But why I can't get anything from the port. I checked the hardware, the serial data (tx/rx) signal is ok and the irq signal is ok.

 

When the system boot up, I found some infomation here, but I don't know the reason for it. The board has no parallel flash, so it's not possible to conflict with the 16550.

 

Serial: 8250/16550 driver $Revision: 3952 $ 2 ports, IRQ sharing enabled

serial8250.0: ttyS0 at MMIO 0x20100010 (irq = 55) is a 16550A

serial8250.0: ttyS1 at MMIO 0x20100020 (irq = 55) is a 16550A

serial8250 serial8250.0: unable to register port at index 2 (IO2 MEM4 IRQ1462328): -28

 

Also I tried /dev/ttyBF1, the results are the same: tx ok, but no rx. Anybody can help?

 

Thanks a lot,

 

JJ

 

 

 

uart.c

TranslateQuoteReplyEditDelete

 

 

2008-07-08 15:40:11     Re: external 8250 send ok but recv none

Robin Getz (UNITED STATES)

Message: 58491   

 

JJ:

 

>Also I tried /dev/ttyBF1, the results are the same: tx ok, but no rx

 

You tried the built in UART, and it doesn't work? If so, let's debug that first.

 

Have you made sure your cable is OK? (short pins 2 and 3 together (at the far end of the cable) with a pen or coin, and anything you type send on kermit should be echoed back).

 

-Robin

QuoteReplyEditDelete

 

 

2008-07-08 22:35:17     Re: external 8250 send ok but recv none

Yi Li (CHINA)

Message: 58495   

 

> serial8250 serial8250.0: unable to register port at index 2 (IO2 MEM4 IRQ1462328): -28

 

Maybe you need to fix this first. Also what is your output of "cat /proc/interrupts"?

QuoteReplyEditDelete

 

 

2008-07-09 10:31:35     Re: external 8250 send ok but recv none

Jian Ju (HONG KONG)

Message: 58555   

 

Hi Robin, YL,

 

Thank you for your pormpt reply. I tried by using a 10ohm resistor to short-circuit pin2-3 of the uart. But the results are very surprising. Firstly, I tried ttyBF0, it can tx and rx data correctly. Then I echo "123456" > /dev/ttyBF1 and then cat /dev/ttyBF1. The results are printing pages of blank on the console. I have to kill it (Ctrl+C). I'm not sure whether it print out "123456" because the screen scroll very fast and then stop.

 

I cat the information of the bfin-uart, here they are:

 

root:/proc/tty/driver> cat bfin-uart

serinfo:1.0 driver revision:

0: uart:BFIN-UART mmio:0xFFC00400 irq:18 tx:26933 rx:132 CTS|DTR|DSR|CD

1: uart:BFIN-UART mmio:0xFFC02000 irq:20 tx:10592 rx:11835 oe:1 CTS|DSR|CD

 

It seems a lot of data has been sent and received, as can tell from the tx/rx irq. But why?

 

<<< Experiment Two >>>

 

I reset the board and connect uart to a PC, and did the same experiment.

 

root:/> echo "123456" > /dev/ttyBF1 (It can be received ok, 8 bytes (+0x0D 0x0A) are sent and received)

 

root:/> cat proc/tty/driver/bfin-uart

serinfo:1.0 driver revision:

0: uart:BFIN-UART mmio:0xFFC00400 irq:18 tx:1330 rx:63 CTS|DTR|DSR|CD

1: uart:BFIN-UART mmio:0xFFC02000 irq:20 tx:8 rx:0 CTS|DSR|CD                         <- tx irq indicated 8 bytes sent out, ok!

 

root:/> cat /dev/ttyBF1    (I run this on the board first, then on the pc side send "abcdefg")

 

The results are no print out on the board, but "abcdefg" are return back to be received by the pc, as if the "abcdefg" are echoed back to pc. It can be confirmed from the following information. As you can see, tx irq increased from 8 to 15.

 

root:/> cat /proc/tty/driver/bfin-uart

serinfo:1.0 driver revision:

0: uart:BFIN-UART mmio:0xFFC00400 irq:18 tx:1591 rx:84 CTS|DTR|DSR|CD

1: uart:BFIN-UART mmio:0xFFC02000 irq:20 tx:15 rx:7 CTS|DSR|CD

 

Regarding the question about the interrupts information of the 16550 chip, not found! But the data can be indeed received by the PC, and /proc/tty/driver/serial gives correctly irq trig times. Is it possible because of the romfs does not allow to register ports?  cat /proc/ioports gives no results. I'll do more work here to find why.

 

root:/> cat /proc/interrupts

  6:     118686   BFIN Timer Tick

18:          0   BFIN_UART_RX

19:        143   BFIN_UART_TX

24:       4251   EMAC_RX

Err:          0

 

I did the experiments on a custom bf537 board. Anyone with a bf537 stamp board, can you please try and tell me the results? Robin, Yi, any idea?

 

Thanks,

 

JJ

TranslateQuoteReplyEditDelete

 

 

2008-07-15 03:51:16     Re: external 8250 send ok but recv none

Mike Frysinger (UNITED STATES)

Message: 58809   

 

we dont have any addon cards to hook up and test with unfortunately ...

 

what kernel version are you working with ?  a user submitted modifications so that things should work with the 2008R1 svn branch (not sure about the 2008R1 release).  you can compare your settings with his (see the H8606 board files).

QuoteReplyEditDelete

 

 

2008-07-15 07:15:22     Re: external 8250 send ok but recv none

Javier Herrero (SPAIN)

Message: 58845   

 

Hello,

 

I've implemented the 8250 patch, and it works OK with svn and with 2008R1 versions, and although I've only tested it in BF532 in our H8606 board with two UART implemented from Opencores in its FPGA, there should not be great differences with the BF537. I don't think that you have a memory conflict because the driver extensively checks the UARTs before declaring them valid, in order to locate which UART model do you have. This seems right since you obtain a valid identification for two 16550A UARTs. Also, transmission is interrupt driven and if it works for you, interrupts should also be OK and should also work in RX.

 

The problem must be related with this error:

 

> serial8250 serial8250.0: unable to register port at index 2 (IO2 MEM4 IRQ1462328): -28

 

I've not seen it during our test, and I don't know what it is triggering it, but surely must be fixed in order to have it working. What is the exact UART chip are you currently using? Perhaps it has some peculiarities not currently implemented in the 8250 driver, and the driver identifies it as a 16550A but there could be some differences.

 

Best regards,

 

Javier

 

 

 

 

QuoteReplyEditDelete

 

 

2008-07-16 11:50:28     回复: Re: external 8250 send ok but recv none

Jian Ju (HONG KONG)

Message: 58961   

 

Javier, thank you for your reply.

 

I default the kernel (2008R1-RC8) settings and re-compiled the kernel, now the error message disappearred. But the symptom is the same as I described previously. The chip I'm using is a ST16C2550 which has dual uarts.

 

Best regards,

 

JJ

Attachments

Outcomes