CF533 (RS232 Version) - Command Response Problems

[inno]

We have a bunch of new 533's (CFA533YYHKS) that we are testing out as replacements for 633's. We are seeing an issue with the 533s where they receive commands from applications, but don't send responses correctly. Some of them don't seem to transmit at all (key presses or in response to ping, version request,e tc.) and some seem to occasionally send a keypress report, although at a less than 20% recogition rate.

We know they are receiving commands correctly, since we can see data on the display, clear the display, change the backlight, etc.

We have tried this with a number of applications that we have written for the 633s and saw the behavior. We have also recreated it with the linux command line example code. We have tried the units at the default 19200 and also switched them for operation at 115200 with the same results.

We have also tried several different hardware configurations, to make sure it isn't a cabling issue (including swapping in a 5V modified (by CF) 633. All the other displays work as advertised.

Any ideas?

Crystalfontz LCD Blog

Looking for additional LCD resources? Check out our LCD blog for the latest developments in LCD technology.

 

[CF Tech]

The "golden" packet host code is 633 Wintest:

http://www.crystalfontz.com/product/633WinTest

Can you see if there are any problems when 633 Wintest is used?

The CFA-533 processor runs slower--this allows the lower voltage operation range. The slower speed, should be completely hidden by the packet protocol. But if the packet protocol is not followed correctly, it can look like communications errors.

 

[inno]

More information

As suggested, we ran the 533 with the WinTest program on a PC. It passed, so we wanted to dig a little deeper to see what was happening.

We then took the linux example code and ran it on an x86 based linux box (a Thinkpad x61). It again passed.

Next step was to compile the linux example code for our embedded platform (an Xscale architecture). At this point it failed (no responses were seen from the display). We could send it commands (clear, text, brightness) and have them show up on the display w/out any acknowledgement.

At this point, we wondered what was going on, since we could talk to it but not read from it, so we modified the examples to report the actual bytes read from the serial port at the lowest level. It turns out that the display is sending responses, but occassionally the bits in a particular byte are corrupt. The overall length of the response and most of the bytes are correct.

This is surprising because this platform has worked fine with literally hundreds of 633s and 635s under RS232. It has also been used with numerous other RS232 devices, so it is a robust implementation.

What appears is that x86 architectures can handle the subtle differences from the 533 to the 633, but our embedded platform is a different story.

At this point, my question is what are the differences in the RS232 implementation between the 533 and 633? We need to determine if the 533 can truly be made a plug-in replacement for our application.

Thanks.

 

[CF Tech]

We did see one instance where the tolerance stacking on the baud rates ended up being too much.

What voltage is your CFA-533 running at?

I'll ask support to get a ticket open for you, and we can try a firmware tweak that was suggested by by the processor guys.

 

[inno]

Power Supply

We are running at a solid 5V, either from an internal DC-DC converter or a good quality external transformer.

We measured both sources to be within +/- 1%.