633USB and Linux

T

theart

New member
Hi,

I'm experiencing some stange behaviour with a CF633USB and Linux.

My setup: CF633 USB, HW version 1.3, Firmware version 1.5, connected to a Slackware system running stock kernel 2.4.26.

I was trying to get LCDproc 0.5 CVS running with this display but whatever I do, nothing appears on the display.

So I downloaded the Linux sample code (the infamous test633 program) to see if I could communicate with the display.

When running this test program, the strings only appear _after_ the serial port is closed... as if the
display needs some trigger, or the data needs to be flushed.

The datasheet I could download for the 633 has firmware 0.6 printed on the frontpage, so I don't know what has changed between that version and the 1.5 version I'm using.

So what is going on here, anyone having similar experiences ?

grtz,

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

dillon68

New member
633, USB, Fedora Core 1 (Linux 2.4.27)

I'm also using the 633 USB with Linux (2.4.27 kernel) and I'm having similar results to the other poster. LDCproc does absolutely nothing and the test633 program behavior is intermittent (at best).

Any ideas?
 
D

dillon68

New member
same results

I had already tried it. The behavior is intermittent....

In the original test633 app, I noticed the "read" statement would sometimes hang (waiting for input even though keypad buttons had been pressed). Normally, this call would block until bytes were ready to be read, but it seems like things just lock up at some point.

If I do a simple "cat \\dev\ttyUSB0" and start hitting the 633 keypad, I see bytes flowing out. If I do this enough, I'm able to make the output stop. Doing a CTRL-C and starting the "cat" again causes a backlog of bytes to be displayed (and new key presses appear again).

So....what does this mean?
 
Last edited:
D

dillon68

New member
more info

I tried my tests under fedora core 2 (which has the 2.6.X kernel)

I can also make the 633 break, but the syslog messages give more information. Evidently, the USB system is resetting (as if the device was unplugged and re-attached). In the case of the 2.6 kernel, a new device name is given to the 633. In the 2.4 kernel, things are probably just being reset internally to the same device (see my next post for test results).

So - is it the 633/FTDI that's doing this if an error condition is detected? Why???

Message Log:

Oct 28 18:13:24 hops kernel: ftdi_sio 5-1:1.0: FTDI 8U232AM Compatible converter detected
Oct 28 18:13:24 hops kernel: usb 5-1: FTDI 8U232AM Compatible converter now attached to ttyUSB0
Oct 28 18:13:24 hops kernel: usbcore: registered new driver ftdi_sio
Oct 28 18:13:24 hops kernel: drivers/usb/serial/ftdi_sio.c: v1.4.0:USB FTDI Serial Converters Driver

**** Here's where I start pressing keypad buttons repeatedly. When things break, we have these new messages *****

Oct 28 18:15:14 hops kernel: hub 5-0:1.0: port 1 disabled by hub (EMI?), re-enabling...
Oct 28 18:15:14 hops kernel: usb 5-1: USB disconnect, address 4
Oct 28 18:15:14 hops kernel: ftdi_sio 5-1:1.0: device disconnected
Oct 28 18:15:15 hops kernel: usb 5-1: new full speed USB device using address 5
Oct 28 18:15:15 hops kernel: ftdi_sio 5-1:1.0: FTDI 8U232AM Compatible converter detected
Oct 28 18:15:15 hops kernel: usb 5-1: FTDI 8U232AM Compatible converter now attached to ttyUSB1
 
Last edited:
D

dillon68

New member
2.4 kernel message log

In my 2.4 kernel, running the new 631_633 test app caused it to reset while it was writing new lines of text to the 633. But, at least it resets to the same device name...

Is it the FTDI driver?
The FTDI chip on the 633?
My motherboard's USB implementation?
Or...?

Oct 28 18:30:49 hops kernel: usbserial.c: FTDI 8U232AM Compatible converter now attached to ttyUSB0 (or usb/tts/0 for devfs)
Oct 28 18:30:49 hops kernel: usbserial.c: USB Serial support registered for FTDI FT232BM Compatible
Oct 28 18:30:49 hops kernel: ftdi_sio.c: v1.3.5:USB FTDI Serial Converters Driver
Oct 28 18:33:48 hops kernel: hub.c: already running port 1 disabled by hub (EMI?), re-enabling...
Oct 28 18:33:48 hops kernel: usb.c: USB disconnect on device 00:1d.3-1 address 2
Oct 28 18:33:48 hops kernel: ftdi_sio.c: Error unlinking urb
Oct 28 18:33:48 hops kernel: usbserial.c: FTDI 8U232AM Compatible converter now disconnected from ttyUSB0
Oct 28 18:33:49 hops kernel: hub.c: new USB device 00:1d.3-1, assigned address 3
Oct 28 18:33:49 hops kernel: usbserial.c: FTDI 8U232AM Compatible converter detected
Oct 28 18:33:49 hops kernel: usbserial.c: FTDI 8U232AM Compatible converter now attached to ttyUSB0 (or usb/tts/0 for devfs)
Oct 28 18:33:49 hops devlabel: devlabel service started/restarted
Oct 28 18:33:52 hops usb.agent[2187]: missing kernel or user mode driver ftdi_sio
Oct 28 18:33:53 hops devlabel: devlabel service started/restarted
 
Last edited:
D

dillon68

New member
The 633 I have is v1.4 and FW b1.9

I've tried it under two kernels with bad results:

Fedora Core 2 - v2.6.8-1.521 (this was a "stock" rpm installation)

Fedora Core 1 - v2.4.27 (compiled directly from kernel.org sources using these USB options)

CONFIG_USB=y
CONFIG_USB_EHCI_HCD=y
CONFIG_USB_UHCI_ALT=y
CONFIG_USB_OHCI=y
CONFIG_USB_SERIAL=y
CONFIG_USB_SERIAL_GENERIC=y
CONFIG_USB_SERIAL_FTDI_SIO=m
CONFIG_USB_LCD=m

If you have a version 2.4 linux distribution (and options) that work, I'd be interested in knowing what they are...
 
C

CF Web

Administrator
This is a modified version of the existing 633 linux test program. Basically, it just pushes info to the display infinitely, while still being able to read key presses.

http://www.crystalfontz.com/products/633/633_linux_looping.tar.gz

I'm going to run this on my linux box (Fedora 2) all weekend on a usb display and see what happens when I get back on Monday.

I would appreciate it if any of you having problems could run this utility as well and post back on Monday with your results.
 
USB LCD Displays - Graphic and Character LCDs with a Keypad
D

dillon68

New member
I didn't see this Friday, so I wasn't able to try it...

However, the exact same hardware seems to be working with Windows XP (so I'm assuming the USB cable and other hardware is fine).

But, I *don't* want to use Windows for this project....
 
C

CF Web

Administrator
Go ahead and give the new one a try. I let it run on my linux machine all weekend and is still going strong today. (Counter is up over 3.5 million)

It's got a few minor changes that may have an impact. If it seems to make a difference, I'll update the 631_633_linux.tar to reflect the changes.

Just drop a line here and let us know what your experience is, or if you've got any questions.
 
C

CF Web

Administrator
Just an update:

My USB display is still going strong since Friday night. Counter is up over 5 million.

Any indication as to whether this solved your problem or not?
 
D

dillon68

New member
I have yet to test with your new code. However, my test on a Windows XP configuration is still running fine....

Without any test software, I can break the linux implementation by simply doing a "cat" on the tty device and repeatedly hitting the keypad... This is independent of any test software running. It's a very simple low level test that fails.

At this point, I can only assume there's a problem with the USB driver and possibly a conflict with my motherboard's USB implementation.

As much as I hate it - the Windows driver is working better than Linux....
 
CF Tech

CF Tech

Administrator
In real life though, you would only use a program to communicate with the CFA-631 or CFA-633, since they require a CRC in the packet.

So I do not think there is a practical consequence of being able to break the driver with a "cat" because it would never happen in actual application. Sure, it would be nice if a "cat" did not break the driver, but if the program can run correctly and never break when it sends properly formatted packets, then I do not think there is any reason to even test the "cat", it is just meaningless information in this application.
 
D

dillon68

New member
I'm only using "cat" to report information *from* the LCD (when the 633 buttons are pressed).

It confirms that something much lower is broken... If the system is unstable doing this basic operation, it's unreliable in *any* scenario.
 
D

dillon68

New member
I tried the looping example...

After 1142 iterations, it got a segmentation fault. I was casually hitting keypad buttons while the test was executing.

Nov 2 06:59:52 kernel: usb-uhci.c: interrupt, status 2, frame# 1887
Nov 2 06:59:52 kernel: hub.c: already running port 1 disabled by hub (EMI?), re-enabling...
Nov 2 06:59:52 kernel: usb.c: USB disconnect on device 00:1d.3-1 address 2
Nov 2 06:59:52 kernel: ftdi_sio.c: Error unlinking urb
Nov 2 06:59:52 kernel: usbserial.c: FTDI 8U232AM Compatible converter now disconnected from ttyUSB0
Nov 2 06:59:52 kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000060
Nov 2 06:59:52 kernel: printing eip:
Nov 2 06:59:52 kernel: e0154893
Nov 2 06:59:52 kernel: *pde = 00000000
Nov 2 06:59:52 kernel: Oops: 0002
Nov 2 06:59:52 kernel: CPU: 0
Nov 2 06:59:52 kernel: EIP: 0010:[<e0154893>] Not tainted
Nov 2 06:59:52 kernel: EFLAGS: 00210286
Nov 2 06:59:52 kernel: eax: 00000000 ebx: 00000000 ecx: 00000060 edx: 00000000
Nov 2 06:59:52 kernel: esi: 00000060 edi: 00000001 ebp: bffff897 esp: cf363eec
Nov 2 06:59:52 kernel: ds: 0018 es: 0018 ss: 0018
Nov 2 06:59:52 kernel: Process test633 (pid: 2187, stackpage=cf363000)
Nov 2 06:59:52 kernel: Stack: 00000000 d518f000 0000000a cf4c6a40 00000000 00000001 bffff897 cf362000
Nov 2 06:59:52 kernel: cf621000 c01dcd9a cf621000 00000001 bffff897 00000001 cf621974 00000000
Nov 2 06:59:52 kernel: 00000000 cf362000 00000000 00000000 00000000 cf362000 cf621978 cf621978
Nov 2 06:59:52 kernel: Call Trace: [<c01dcd9a>] [<c01d7b15>] [<c01dcbb0>] [<c0144eeb>] [<c010724b>]
Nov 2 06:59:52 kernel:
Nov 2 06:59:52 kernel: Code: f0 ff 4b 60 0f 88 90 26 00 00 80 7b 35 00 74 25 f0 ff 43 60
 
C

CF Web

Administrator
After doing quite a bit of 'google'ing, I'm starting to feel that what you're seeing is a linux problem that has to do with the usb and usb to serial drivers. I've seen quite a few posts on linux forums describing similar behavior with a myriad of usb devices, from mice to zip drives. (a quick google of "usb-uhci.c: interrupt, status 2" will net some of these)

I am by no means a linux "expert" and don't have the time or the means to fully debug this problem. I cannot get it to fail reliably (or at all) on my linux box.
Unfortunately, we did not write the Linux FTDI drivers, so we are quite limited in our ability to correct issue.

As a side note, I found several indications that there has been some ongoing changes to these drivers.
http://seclists.org/lists/linux-ker...4/Apr/2973.html
http://lwn.net/Articles/93724/

If you're still using Fedora 2 (I use this as a reference because it's what I'm using: 2.6.5-1.358, fully patched), make sure that you've got all the latest updates and patches.
 
D

dillon68

New member
I'm also uncomfortable with USB<->serial adapters.... We've had mixed luck with them.

As such, we're looking for a SBC motherboard that has real COM ports....
 
CF Tech

CF Tech

Administrator
No matter how hard the industry pushes USB, serial is still orders of magnitude more simple in both hardware and software, and so has much less to go wrong with it. If RS232 is available, there is good reason to consider it over USB.
 
You must log in or register to reply here.
Top