FYI...
-----Original Message-----
From: Ho, Wen Jei x4297
Sent: Thursday, April 17, 2003 2:09 PM
To: '"Tung, Kenny" <Kenny.Tung@spirentcom.com>@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@spirentcom.com>@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@spirentcom.com>@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 [mailto:who1@rockwellcollins.com]
Sent: Thursday, April 17, 2003 3:08 AM
To: 'Kenny.tung@spirentcom.com'
Subject: RE: [oc] UART16550
Kenny,
Could you comment on this?
Thanks, Wen
-----Original Message-----
From: owner-cores@opencores.org@ROCKWELLCOLLINS On Behalf Of "Harvey, Wilbur" <Wilbur.Harvey@SpirentCom.COM>
Sent: Tuesday, April 15, 2003 6:50 PM
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@spirentcom.com 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@spirentcom.com
-----Original Message-----
From: John Sheahan mailto:jrsheahan@optushome.com.au]
Sent: Tuesday, April 15, 2003 12:18 PM
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@aos-inc.com 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