Pinouts (again) for DB25 RS232 (633)


New member
Standard question it seems: pinouts for the 633! Alas I've tried many options but can't seem to establish communication with the 633. All help appreciated:

I am connecting my 633 to a DB25 RS232 port. Right now I have a break-out box (BoB) to try and get this right.

The 2x5 header `out-of-the-box' is in normal configuration and thus the 633 (DTE) and via a 2x5 header-to-DB25 ribbon cable I should have this mapping:

2x5 Header = DB25
Pin3 TX = Pin3
Pin5 RX = Pin2
Pin9 GND = Pin7

Since my computer is effectively DTE (right?) I need to null-modem it, swap DB25 Pin2 and Pin3 in the BoB and I should be good-to-go? Unfortunately no. I've tried numerous pinout combinations and I've loopback-tested the DB25 serial port.

Can you offer any suggestions? What could I be doing wrong?

Let me summarize:

633 Header -> DB25 ribbon cable -> BoB -> Computer DB25 serial port
Pin3 -> Pin3 -> Switch to Pin2 -> Pin2
Pin5 -> Pin2 -> Switch to Pin3 -> Pin3
Pin9 -> Pin7 -> Closed -> Pin7

Again all help appreciated!
Looking for additional LCD resources? Check out our LCD blog for the latest developments in LCD technology.
Last edited:


New member
Update that I can receive packets from the 633's keys, but I can't get a led light in the BoB for sending command packets to the 633.

Again, all thoughts & help greatly appreciated.

CF Tech

I am not sure what the problem could be. The only signals the CFA-633 needs is Rx, Tx, and Ground. Here is a quick diagram:

The other issues could be baud rate or CRC problems.


USB LCD Displays - Graphic and Character LCDs with a Keypad


New member
I thought about that too. I am actually am using the Linux test633 code without modification, I can't even get the screen to clear or a link light on the break-out box. Is this possibly a defective 633? Pin3 and Pin5 (and gnd) are definitely what I'm assuming; and I think correctly because I'm receiving the key packets through the test633 program?

CF Tech

Did you recompile the test program? I think someone once mentioned that byte order breaks the CRC code in some of the samples.

Do you have a Windows box that you could do a quick test on with 633_WinTest to make sure the module is OK?


New member
Yes, I did recompile the Linux program. I have also tried this on another Windows box with the same results. I can get the data packets in the packet debugger, but the Status: in the main screen always says Looking for module...

I will say that I do get a MARK (-) on the DB25/RS232D Pin2 (633TX). I am very much wondering if my BoB is bad at this point, and it's my only null modem crossover...


New member
I'm pretty much at the end here of things to try. I did flip the IDC10 connector upside-down and got the following:

Pin3 RD SPACE (IDC#3 / Corresponding Pin8)
Pin5 CTS MARK (IDC10#6 / Corresponding 5)
Pin6 DSR SPACE (IDC10#2 Corresponding 9)

Read the bold. I assume there are other uses for these RS232 pins on the 633 because that Pin8 does not match the regular or alternate pinouts. So I then try DB25#22 crossing into Host Pin#2, alas no joy.

CF Support

The only thing that gives me pause here is the following:

I am very much wondering if my BoB is bad at this point, and it's my only null modem crossover...
You should be using a straight-through type cable.

Any thoughts?


New member
You should be using a straight-through type cable.
The 633 will go via an RJ45/CAT5 cable. Right now I am trying to get this working via a DB25 serial port. I have a ribbon IDC10-to-DB25 cable. Using this cable direct to the DB25 on the computer yields no results, thus the breakout box where based upon the testing it clearly appears I must cross TD&RD in null-modem fashion (so doing allows me to read key press packets).

Testing continuity on the IDC10 vs DB25 pins appears to have this relationship:

IDC10 DB25
1 8
2 6
3 3
4 4
5 2
6 5
7 20
8 22
9 7
10 NC

Alas, apparently neither I nor the software can send packets to the 633. I must be missing something very simple...


New member
An update. I now have a IDC10-DB9F cable and everything is working on the windows test system!!!

It is not however on the Linux serial server which has all the DB25s, apparently there may be some kernel- or driver-level control signals which need to be set in order to send data, and that I'm investigating, but apparently there is significantly more consistency with Crystalfontz than there is with my other serial hardware vendors! The 633 appears to be working good now.

I just need to ask crystalfontz to come up with a packaged IDC10-DB25F cable for old-school RS232D :)