rs-232 trouble

P

Paul

Guest
Hi

I've been coding a rs-232 rx/tx module. after some hardwork, it's all
working fine for timeing and everything (rx/tx) -- except one thing--
whenever I reprogram the FPGA, the first byte received always has 0x80
bigger than what was actually sent. everything works fine afterward.
I'm using comDebug.

I don't use flow control, and only RXD,TXD lines.

Any suggestion? Thanks.
 
whenever I reprogram the FPGA, the first byte received always has 0x80
bigger than what was actually sent. everything works fine afterward.
I'm using comDebug.
Click to expand...
What does in mean *the first bite received*? After what? If after power-on
the revise async resets in appropriate process. If all the bytes are ORed
with '1' then you catch the stop bit.
Please remember two things when programming rs232:
- sample bits at the middle of bit slice; and
- pass to receiving next bit at the middle of stop bit.
 
Do you use an "async_rst" signal to reset the FPGA after configuration?

If not, be careful as the registers start at "0" regardless of the input
levels.



Could you share your code so that we can take a look? You can also find some
sample code here http://www.fpga4fun.com/files/async.zip

Jean




"Paul" <paulw@mmail.ath.cx> wrote in message
news:3ba4d769.0401040325.fe13f47@posting.google.com...
Hi

I've been coding a rs-232 rx/tx module. after some hardwork, it's all
working fine for timeing and everything (rx/tx) -- except one thing--
whenever I reprogram the FPGA, the first byte received always has 0x80
bigger than what was actually sent. everything works fine afterward.
I'm using comDebug.

I don't use flow control, and only RXD,TXD lines.

Any suggestion? Thanks.
Click to expand...
 
"Jean Nicolle" <j.nicolle@sbcglobal.net> wrote in message news:<%XZJb.6009$_r6.2064@newssvr29.news.prodigy.com>...
Do you use an "async_rst" signal to reset the FPGA after configuration?

If not, be careful as the registers start at "0" regardless of the input
levels.



Could you share your code so that we can take a look? You can also find some
sample code here http://www.fpga4fun.com/files/async.zip

Jean
Click to expand...
There is no buffer right now, so it cannot receive continuous bytes.
working on that when I got this "first byte" problem figured out.

`define LENGTH (50000000/38400)
module top2(clk,RXD,TXD,led0,led1);
input clk;
input RXD;
output TXD,led0,led1;

reg [1:0] s1;

reg [7:0] char_w;
wire [7:0] char_r;
reg go_r,go_w;
send qq1 (clk,char_w,go_w,ok_w,TXD);
recv qq2 (clk,char_r,go_r,ok_r,RXD);

assign led0=~char_w[6];
assign led1=~char_w[7];

always @(posedge clk) begin
case (s1)
0: begin s1<=s1+1; go_r<=1; go_w<=0; end
1:if (ok_r) begin s1<=s1+1; go_r<=0; char_w<=char_r; end
2: begin s1<=s1+1; go_w<=1; end
3:if (ok_w) begin s1<=s1+1; go_w<=0; end
// default: s1<=s1+1;
endcase
end

endmodule


module send(clk, din, go, ok, TXD);

input clk;
input [7:0] din;
input go;
output ok; reg ok_r;
output TXD; reg TXD_r;
reg [31:0] cnt;
reg [7:0] step;

assign TXD=~TXD_r;
assign ok=ok_r;

reg s1;
always @(posedge clk) begin
case (s1)
0 : begin
cnt<=0;
step<=0;
ok_r<=0;
TXD_r<=0;
s1<=1;
end
1 : if (go != 0)
begin
cnt<=cnt+1;
if (cnt==`LENGTH) begin step<=step+1; cnt<=0; end
if (step==12) begin s1<=0;ok_r<=1; end
else if (step==0) TXD_r<=1;
else if (step>=9) TXD_r<=0;
else if ((step>0)&&(step<9)) TXD_r<=~din[step-1];
end
endcase
end
endmodule

module recv(clk, din, go, ok, RXD);
input clk;
output [7:0] din; reg [7:0] din_r;
input go;
output ok; reg ok_r;
input RXD; reg RXD_r;
reg [31:0] cnt;
reg [7:0] step;

assign ok=ok_r;
assign din=din_r;

reg s1;
reg s2;
always @(posedge clk) begin
RXD_r<=~RXD;
case (s1)
0 : begin
cnt<=0;
step<=0;
ok_r<=0;
s1<=1;
end
1 : if (go != 0)
case (s2)
0 : if (RXD_r == 1) begin s2<=1;din_r<=0; end
1 : begin
cnt<=cnt+1;
if (cnt==`LENGTH) begin step<=step+1; cnt<=0; end
if (step==9) begin s1<=0;s2<=0;ok_r<=1; end
else if (step==0) begin end
else if ((step>0)&&(step<9)&&(cnt==(`LENGTH/16)))
din_r[step-1]<=~RXD_r;
end
endcase
endcase
end
endmodule
 
Hi

did I mention that a Maxim MAX3386E RS232 voltage converter was
between fpga and the connector on my board. maybe it has something to
do with it.

also, after some debugging. I found out a few facts:

1. if I send 0x00 from comDebug, the last 2 MSB's are correctly
received. (from LED lights.) the echoed value received from comDebug
is 0x80.

2. if I send 0x10 from comDebug, the last 2 MSB's are correctly
received. (from LED lights.) the echoed value received from comDebug
is 0x90.

3. if I send 0x20 from comDebug, the last MSB is correctly received.
but the 6th bit was wrong. (from LED lights.) the echoed value
received from comDebug is 0xA0.

4. if I send 0x40 from comDebug, the 6th and 7th got switched. (from
LED lights.) the echoed value received from comDebug is 0xC0.

5. if I send 0x80 , the echoed value received from comDebug is 0x80.
(however, the led indicate I received 0x00.)

so from this I can conclude there is something wrong in both the send
and recv modules -- for the first byte. strangely every byte
afterward is OK.
 
When I was debugging my modules I did it separately. Send a stream out of
UART, make sure it is working prperly. Make sure that receiver is working by
observing debug pins on PLD. Revise quartz rate and divider.

Do you synchronize Rx input? I don't and everything working OK; however,
there are multibit counters depending on the input, thus I think it should.
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top