Message

Reply | Reply all

Date Prev | Date Next | Thread Prev | Thread Next Date Index | Thread Index

From: "Ho, Wen Jei x4297" <who1@r...>
Date: Fri, 18 Apr 2003 07:33:38 -0700
Subject: FW: [oc] UART16550

FYI...

-----Original Message-----
From: Ho, Wen Jei x4297
Sent: Thursday, April 17, 2003 2:09 PM
To: '"Tung, Kenny" <Kenny.Tung@s...">Kenny.Tung@s...>@ROCKWELLCOLLINS'
Subject: RE: [oc] UART16550

Kenny,

Never mind. It is in there.

// Revision 1.28  2002/07/22 23:02:23  gorban

// Bug Fixes:

//  * Possible loss of sync and bad reception of stop bit on slow baud rates fixed.

//   Problem reported by Kenny.Tung.

//  * Bad (or lack of ) loopback handling fixed. Reported by Cherry Withers.

Wen

-----Original Message-----
From: Ho, Wen Jei x4297
Sent: Thursday, April 17, 2003 2:04 PM
To: '"Tung, Kenny" <Kenny.Tung@s...">Kenny.Tung@s...>@ROCKWELLCOLLINS'
Subject: RE: [oc] UART16550

Kenny,

The one I have is Revision 1.29 (see attached file).

I can't find sr_last state. Could you take a look to see

if your fix has been imbedded or not?

Thanks, Wen

 << File: uart_receiver.v >>

-----Original Message-----
From: "Tung, Kenny" <Kenny.Tung@s...">Kenny.Tung@s...>@ROCKWELLCOLLINS
Sent: Thursday, April 17, 2003 12:52 PM
To: Ho, Wen Jei x4297
Subject: RE: [oc] UART16550




Here's  what I sent to the guys at opencore.  I'm surprise they didn't fix the code  by now:

 

[copied email]

Hi, my name is Kenny Tung. I've been using the 16550uart core that I've found  on the opencore.org website. When I implemented the design on a chip and did a  comm test (sending data from a PC to the core). I found that the core have  problems operating on slow baudrates. The problem appears as you get below 57.6K  and progressively gets worse the slower you go. At 300 baud, the message becomes  completely corrupted. It seems the core is having a problem finding the stop  bit. If we were to set the transmitter (from a PC) to 2 stop bits instead of 1,  then the problem goes away. We were able to get around this problem by making a  change to the following line in the file uart_receiver.v

from:

sr_last : begin

if (rcounter16_eq_1 & srx_pad_i | break_error)

rstate <= #1 sr_idle;

rcounter16 <= #1 rcounter16_minus_1;

rf_push <= #1 1'b0;

end

to:

sr_last : begin

if (srx_pad_i | break_error)

rstate <= #1 sr_idle;

rcounter16 <= #1 rcounter16_minus_1;

rf_push <= #1 1'b0;

end

I'm not sure why it is necessary to wait until rcounter16_eq_1 before going  back to idle except perhaps its use to detect the break_error. As I understand  it, rcounter16_eq_1 is true when it is near the very end of the bit. However, it  is very likely that by the time 9 bits are received (1 start + 8 data), the  serial signals would have shifted in a way that sampling the bit at that late of  a time would cause it to read the next bit. In fact, this is exactly what we  see, the statemachine missing the stop bit because it had read the next start  bit. This also explains why at very high speeds (>57.6K) the core will work  because it is likely that the bytes are not being send back to back because of  some other bottleneck. By not sending bytes back to back, it has the same effect  as adding another stop bit between words, which is another way we can work  around this problem.

I'm not sure if this has been reported before or not. In the uart_receiver.v  file, the last revision is 1.27 dated 2001/12/30. Perhaps it had been reported  before and fixed and I don't have the latest files. In any case, I would like to  hear from you regarding this problem and weather or not the work around I made  to the code will break something else. Thanks for your time.

[end of copy email]

-----Original Message-----

From: Ho, Wen Jei x4297  who1@r...]">[mailto:who1@r...]

Sent: Thursday, April 17, 2003  3:08 AM

To: 'Kenny.tung@s...'

Subject: RE: [oc]  UART16550

Kenny,

Could you comment on  this?

Thanks, Wen

-----Original  Message-----

From:  owner-cores@o...@ROCKWELLCOLLINS">owner-cores@o...@ROCKWELLCOLLINS On Behalf Of "Harvey, Wilbur"  <Wilbur.Harvey@S...">Wilbur.Harvey@S...>

Sent: Tuesday, April 15, 2003  6:50 PM

To: cores@o...">cores@o...

Subject: RE: [oc]  UART16550

We used that core in  one of my projects, they ran into some problems and had

to fix the core.  Your problem sounds familiar. I don't know if they posted

the changes  back.

Try contacting  Kenny.tung@s...">Kenny.tung@s... he is the guy who did the work

here.

Wilbur Harvey -  Engineer

Spirent  Communications Inc., www.adtech-inc.com

First Hawaiian  Center, 999 Bishop St.. Suite 1700

Honolulu, HI  96813

Tel: +1 (808) 440  3494, +1 (808) 440 3363 (Direct)

Mobile: +1 (808) 221  0395

email:  wilbur.harvey@s...">wilbur.harvey@s...

-----Original  Message-----

From: John Sheahan  jrsheahan@o...">mailto:jrsheahan@o...]

Sent: Tuesday, April  15, 2003 12:18 PM

To:  cores@o...">cores@o...

Subject: Re: [oc]  UART16550

try changing labview  to use 2 stop bits if possible. This may help

verify the exact  problem.

certainly the uart  should start looking for a start bit just after

the midpoint of the  first stop bit, (to allow for baud rate mismatch)

when running in  single stop bit mode.

john

On Tue, Apr 15, 2003  at 03:25:14PM -0100, tate@a...">tate@a... wrote:

> Hello  all,

>

> I've just  compeleted my first UART16550 core instantiation and have run

> into a  problem.  I'm setup to run at 57.6k and the core performs

> perfectly for  individual characters received.  However,  if I chain  to

> bytes back to  back (from a labview application running on win98) I

> sometimes loose  the second byte.

>

> Reviewing the  source code I notice the receiver statemachine goes to

> a "stop" state  that detects the stop bit and then counts down...  This

> count down  causes me to miss the next startbit of the second byte...

>

> Has anyone else  seen this problem?

>

>  Thanks,

>  Steve

> --

> To unsubscribe  from cores mailing list please visithttp://www.opencores.org/mailinglists.shtml

--

To unsubscribe from  cores mailing list please visithttp://www.opencores.org/mailinglists.shtml

--

To unsubscribe from  cores mailing list please visit http://www.opencores.org/mailinglists.shtml