• We recently switched our forum platform. If you experience any issues please email support@crystalfontz.com

CFA533 not working in place of CFA633

bryede

New member
I have a simple application in which I set the display and read the buttons in a loop. When I connect a CFA633 it runs perfectly. When I connect my new CFA533, the handshaking seems to be full of errors. I haven't yet tracked down what part of my code is barfing, but something is different in the responses I'm receiving.

Both are using RS-232 level signaling and I'm not using any fans. Is there any communications difference I need to know about?
Looking for additional LCD resources? Check out our LCD blog for the latest developments in LCD technology.
 

bryede

New member
They should work the same. We tested the CFA-533 with 633_WinTest. Can you give 633_WinTest a try?

http://www.crystalfontz.com/product/633WinTest.html
I haven't made up a PC cable (my app is running on a microcontroller and MAX202 level converter), but I noticed something odd when I changed the baud rate:

@ 18,519
CFA-633 doesn't work
CFA-533 doesn't work

@ 19,200
CFA-633 works
CFA-533 sorta works (some errors)

@ 20,000
CFA-633 works
CFA-533 works

@ 20,833
CFA-633 doesn't work
CFA-533 works

@ 21,739
CFA-633 doesn't work
CFA-533 doesn't work

Could there be a baud rate issue with the 533? I have about 20 CFA-533's here and it seems to be consistent.
 
Last edited:
USB LCD Displays - Graphic and Character LCDs with a Keypad

CF Tech

Administrator
The baud rate is derived from the main processor clock.

The main processor clock is an "Internal 2.5% 24/48 MHz Oscillator".

Unfortunately, the spec is only "hard" for 5v operation, and the CFA-533 runs at a wide voltage range.

Can you let us know what voltage you are supplying to the CFA-533?

From: http://pdfserv.maxim-ic.com/en/an/AN2141.pdf

For the normal scenario, the clock mismatch error can be ±5/152 = ±3.3%, and for the nasty scenario it can be ±3/152 = ±2%. As hinted earlier, although the problem will materialize at the receive end of the link, clock mismatch is actually a tolerance issue shared between the transmit and receive UARTs. So presuming that both UARTs are attempting to communicate at exactly the same bit rate (baud), then the allowable error can be shared, in any proportion, between the two UARTs.
So our processor can potentially use up most of the error budget. Since the CFA-533 usually communicates to a PC which typically have accurate crystal controlled clocks on their UART, we have not seen problems.

Can you easily look at the actual bit times with an oscilloscope to see what the bit timings are in each direction? The Tx from the CFA-533 will show the CFA-533's clock. The Rx to the CFA-533 will show your system's clock.
 
Top