Dropped packets on 635-TMF-KU but not 631 or 635-TML-KU

[mark999]

I know the TMF hasn't been produced for several years, but we have a number of them out in the field. I'm adding some additional functionality to the software and noticed problems with the one model. I haven't seen anything in the documentation, and after trying various things I'm scratching my head over what to try next.

Symptoms

The display will stop responding to sent packets. I have seen it start responding again, but it seems to take 30s or more. Hardly ideal for a menu that I'd like to have a timeout in the range of 30s - 1m.

There doesn't seem to be a specific command sequence that triggers the problem. It can happen after the first line or two is displayed, or after many updates to the display. I can trigger it very reliably by mashing buttons on the display, but at times the problem has started almost instantly - before I have had a chance to press a single button.

Units

With some test code that displays a menu and listens for key presses, I've tried a CFA-631-TMF-KU (works fine) and a XES-635BK-TMF-KU (drops packets). I had a co-worker try with a different XES-635BK-TMF-KU. He got the same result as I - dropped packets. He also has an XES-635BK-TML-KU and reported no issues running my test program with that model.

So it appears that this problem is limited to the 635 TMF but isn't specific to the unit I have on hand.

Environment

Desktop PCs running Linux. The 631 has no extra hardware attached, and of course the XES units have no provision for external hardware. I generally use a USB extension cable to make it easier to plug/unplug the display, but I have tried without, plugging directly into a motherboard port. Doing so made no difference, unfortunately.

What I've tried

I thought that maybe the problem occurred when a packet was sent at the same time the display was sending a key press/release report packet, but after disabling key reports I still get lost packets.

Injecting delays between packets hasn't seemed to make a difference, and neither has increasing the response timeout from 300ms (250ms + 50 for OS overhead) to 400ms, 500ms, ..., 1s.

----

If it was a RS-232 device I'd try changing the baud rate but I'm guessing that'd have no real effect on a usb-serial device.

I don't see any discussion of serial port configuration in the PDF; are there any serial port settings it'd be sensible to tweak?

Any suggestions on other things to try?

Crystalfontz LCD Blog

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

 

[mark999]

My unit reports its model and revision levels as CFA635:h1v2,u2v0.

Example back-and-forth with lost packets:

Found LCD at /dev/ttyUSB0
-> HwFwVers <no data> (crc 169f)
<- OK__HwFwVers [16]data="CFA635:h1v2,u2v0" (crc 97ac)
-> ReadReportingAndStatus <no data> (crc 00c6)
<- OK__ReadReportingAndStatus [15]data="\x00\x00\x00\x00\x00??\x00\x00\x01\x01\x01\x01d(" (crc 4a6d)
-> Clear <no data> (crc 5b97)
<- OK__Clear <no data> (crc 1df1)
-> SetBacklight [1]data="\n" (crc 6055)
<- OK__SetBacklight <no data> (crc d331)
-> SetCursorStyle [1]data="\x01" (crc 6b3e)
<- OK__SetCursorStyle <no data> (crc e081)
-> CfgKeyReports [2]data="\x00'" (crc 885b)
no response to CfgKeyReports pkt
-> Ping [8]data="\xa1N\xee\xcfO\xf7\x8a\x15" (crc a9ed)
no response to Ping pkt
-> CfgKeyReports [2]data="\x00'" (crc 885b)
no response to CfgKeyReports pkt
-> Ping [8]data="\xc9\x19\xb9\xf3O\xf7\x8a\x15" (crc 1dd6)
no response to Ping pkt

Another example, this time with a 30s packet timeout:

Found LCD at /dev/ttyUSB1
-> HwFwVers <no data> (crc 169f)
<- OK__HwFwVers [16]data="CFA635:h1v2,u2v0" (crc 97ac)
-> ReadReportingAndStatus <no data> (crc 00c6)
<- OK__ReadReportingAndStatus [15]data="\x00\x00\x00\x00\x00??\x00\x00\x01\x01\x01\x01d(" (crc 4a6d)
-> Clear <no data> (crc 5b97)
<- OK__Clear <no data> (crc 1df1)
-> SetBacklight [01]data="\n" (crc 6055)
<- OK__SetBacklight <no data> (crc d331)
-> SetCursorStyle [01]data="\x01" (crc 6b3e)
<- OK__SetCursorStyle <no data> (crc e081)
-> CfgKeyReports [02]data="\x00\x00" (crc dde6)
<- OK__CfgKeyReports <no data> (crc 91b8)
-> Write [21]data="\x00\x00First item " (crc 0288)
<- OK__Write <no data> (crc 5f78)
-> Write [21]data="\x00\x012 " (crc e01c)
<- OK__Write <no data> (crc 5f78)
-> Write [21]data="\x00\x02this is the THIRD i" (crc 782d)
<- OK__Write <no data> (crc 5f78)
-> Write [21]data="\x00\x03and the fourth item" (crc f4f1)
<- OK__Write <no data> (crc 5f78)
-> ReadKeys <no data> (crc 5416)
<- OK__ReadKeys [03]data="\x00//" (crc bcf6)
-> ReadKeys <no data> (crc 5416)
<- OK__ReadKeys [03]data="\x00\x00\x00" (crc c5f8)
-> SetCursorStyle [01]data="\x00" (crc 7ab7)
<- OK__SetCursorStyle <no data> (crc e081)
-> Clear <no data> (crc 5b97)
no response to Clear pkt
-> Ping [08]data="\xdeLɰ\xdb\xfd\x8a\x15" (crc ae7a)
^Csignal: interrupt

In both cases I run my test program a few seconds after plugging the unit in.

 

[mark999]

So this is more-or-less solved now. When I got invalid data (for example, with type of 0xff) I logged the error and tried to read any more outstanding data. However, I was reading before logging - so if something went wrong with the read (i.e. hanging), no message was printed. I thought I was printing the message first, so didn't look at this code too hard. I'd expected my read operation to read bytes available and then return, but that isn't the documented or observed behavior. Instead, the function will only return if it sees EOF or if the output buffer fills. Since the read was hanging, it appeared to the other thread that no packets were coming in - and it dutifully printed out messages about not getting a response.

Wireshark and strace were instrumental in tracing this issue down. Wireshark to determine that the lcd was sending packets normally even when my app didn't get them, and strace as a sanity check on serial port config and app behavior.

The only part of this that isn't solved is why I'm seeing spurious data, but that's quite easy to work around now that I know what's happening - if I see an out-of-range value, I flush the port and try the last command again.

 

[cosmicvoid]

Thanks for updating this topic. I was wondering what you would discover.