6502.org

I'm down to my last ounce of patients with this chip, but stubbornness stops me for giving in...

So i'm trying to get the following to work...

USB ----> CP2102 ----(Rx,Tx,DTR)----> 65C51

This is working fine for receiving from the 65C51 (after a skirmish with the Xmit bit issues) but i just cannot get the thing to accept transmit from the CP2102. After a few days staring of datasheets and fruitless experiments i need a few more pairs of eyes...

65C51 Setup

TX -> CP2102 RX
RX -> CP2102 TX
CTS -> GND
DSR -> GND
DCD -> GND
DTR -> CP2012 DTR
RTS -> NC

Level conversion between CP2102 and 65C51 is in place (TXB0104)

External 1.8...Mhz Crystal, which is oscillating (Urgh 1Mohm bias)

Control Register set $1F

Command Register set $0B

The program is doing
Which get's it stuck in a never ending loop waiting for data, as the receive bit is never set. Scope shows clear data getting to the Rx pin. Any suggestions greatly appreciated.

Also, hi i'm new here, hope you all don't mind me jumping in and asking for help

Your code looks fine and from what you gave, the wiring seems right too. Since your scope shows clean data at the 6551 RX pin, it appears the CP2102 is sending.

Does the bit rate on the scope line up with 19,200 baud?

Have you tried a lower baud rate?

Can you put a loop from the 6551 TX directly to the 6551 RX and do a test program to see if it can RX it's own data?

Do the same also with the CP2102 to ensure everything is good there too.

That's all I can come up with off hand.

Good luck!

Daryl

Shouldn't DTR be cross-connected to DSR (or grounded)?

Welcome, chrisabird
Is the wiring new? It may be that, due to a wiring error, the bit you're testing actually isn't the receive bit -- which would explain why it doesn't behave as expected. For example, it may be that one of the data-bus lines going to the 65C51 is shorted high or low, or (more likely) that it's gotten transposed with another data line. Same with the address lines.

You might suppose this is impossible, since the 65C51 seems to transmit OK. But if the transmit test was superficial rather than thorough then a wiring error could go undetected. It takes a special kind of bad luck to get blind-sided by this, but if the binary values match a certain pattern it can happen.

So that's what comes to mind for me. Maybe the receive bit isn't actually isn't!

Good luck with your troubleshooting,
Jeff

DTR on one should be driving DSR on the other. Similarly, RTS on one should be driving CTS on the other.

Thanks all, lots for me to consider, back to the bench with some new angles to try! Report back shortly

Chris

Also, if for some reason you do want to drive a line to ground, please do so through a resistor. If you're tieing CTS to ground directly, which is an output I believe, you could be shorting some circuitry causing malfunction of other parts of the chip. Not having seen a schematic, I'm not sure if this is what you're doing or not, so just throwing this out there as a general tip.

You mean CTS. RTS is an output that is driven to both ground and Vcc. Wiring RTS to ground or (worse yet) to Vcc could be fatal to the device. This is true of all UARTs, not just the 65C51.

As a general note to anyone who is new to UARTs and is contemplating a design, in most cases you would set up something similar to the following if you wanted two UARTs to talk to each other:
The arrows indicate the direction of data flow and the above arrangement is for full hardware handshaking. The DSR <——> DTR connections may not be necessary in many cases.

The absolute minimum working interface is the so-called "3-wire" hookup, which connections are asterisked. Depending on the devices involved, software handshaking might be required with a 3-wire interface. Note that software handshaking can become unreliable above 9600 bps, and is unsuitable for use with raw binary transfers, as <DC1> and <DC3> characters in the data stream will be intercepted by the serial driver at the receiving end and will not passed onward to the application.

I admit I always have trouble with CTS/RTS and which way the flow goes, but on page 9 of my WDC65C51 datasheet (3/7/2006), CTS is shown as an input and RTS is an output. Could it be that the 65C51 does not follow industry standards with it labeling?

Clear to Send (CTSB)
The CTSB input pin controls the transmitter operation. The
enable state is with CTSB low. The transmitter is
automatically disabled if CTSB is high.

Request to Send (RTSB)
The RTSB output pin controls the modem from the
processor. The state of the RTSB pin is determined by the
contents of the Command Register.

My SBC2 had the CTS pin grounded.

Daryl

I think CTS and DSR are inputs, and RTS and DTR are outputs. I'm guessing (hoping) that the inputs are tied low via resistors on USB adapter; and I believe the W65C51 should either tie the two input poins low, or DST/DTR and RTS/CTS with their opposite numbers on the USB adapter side.

CTS is an input (or CTS/, as low enables transmit) on the 6551, and RTS/ is output.
It's easy to get confused by the RS232 terminology because somebody thought it was a good idea to define the interface as 'transmitter' and 'receiver' (DTE and DCE), and use the same signal names. So TX is transmit on a DTE device, and TX is receive on a DCE device.. but if you connect DTE to DTE, which is the case with a 6551 and a terminal, then you would connect TX to RX (and RX to TX), and CTS would be input on both and RTS would be output on both.

6551:
Inputs:
RX (aka RxD)
CTS/
DCD/
DSR/
Outputs:
TX (aka TxD)
RTS/
DTR/

Yes. I got them reversed (which I do now and then).

I had it backwards. Even though I've worked with TIA-232 since the early 1970s, I occasionally get things mixed up.

Yes the wiring is new, i have double checked the wiring and continuity between lines, and all looks fine. To make extra sure I've expanded the transmit test to loop through a range of ASCII chars and all seems to come across fine.

I've tried the loop back test now and annoyingly getting a similar result. I tried just reading the data back in and throw it out onto a VIA. For this I've left DTR unconnected.

I've tried one more experiment, but this may be invalidated if my interpretation of the datasheet is wrong. The block diagram shows there being a separate Transmit Data Register (TDR) and Receive Data Register (RDR), so i have made an assumption that reading from the 65c51 will be pulled from the RDR, while a write will be put into the TDR. With this assumption in mind i changed my sample program to not check for BIT3/RDRF flag of the status register and just read regardless. This is actually showing the data i would expect to be there, but again this could be totally invalidated if it's just reading back the data i'd just written in. Anyone got any thoughts on this? Sample code below...