Am Thu, 23 Nov 2023 20:37:26 +0100 FreeBSD User <free...@walstatt-de.de> schrieb:
> Hello, > > I'm facing some strange behaviour when connecting to a CP2102 USB-UART bridge > built-in into > a I2C-USB device (I2C is handled by an Amtel88, USB-UART is handled by an > CP2102, see here: > > https://de.elv.com/pc-usb-i2c-interface-200958 > > for an sketch/overview. The device is recognised as > > uslcom0 on uhub6 > uslcom0: <ELV USB-I2C-Interface> on usbus0 > > for more details via usbconfig see below. > > Using FreeBSD CURRENT and 14-STABLE (both most recent) connecting to the > device via > > cu -l /dev/cuaUX -s 115200 > > results in most cases in a stuck connection. The LED of the device is > responding to every > keystroke made in the terminal, but I never see any output (which should). > In some rare cases disconneting and reconnecting the USB link and connecting > via "cu" gives > the opportunity for a couple of seconds to enter "?" in the terminal which > provides some > firmware data on the device - then the communications goes dark. This > behaviour is erratic > and non predictable. > > I tried several platforms (hardware), all USB 3, tried FreeBSD 14-STABLE and > CURRENT. On a > notebook (Lenovo T560) running 14-STABLE the very same situation, but trying > the Lenovo with > Xubuntu 23.10 gives me a working "cu" and I'm able reading environmental data > from the > device. > > Using the methusalem USB 2 port of a computer were available gives me a few > seconds more on > FreeBSD, before the serial connection goes mute. > > In cases were possible I tried the same hardware with FreeBSD and Linux > Xubuntu, FreeBSD > fails, Xubuntu prevails the task. At this point I was quite sure that > FreeBSD's uslcom-driver > might be the culprit. > > Out of couriosity I tried a FSBD-13.2RELENG image for AARCH64 (PINE64 I have > at hand) and > connected the same way, the same device acts as normal as I see under Linux > Xubuntu. I'm able > to take environmental data as long as I please without a problem so far. > > Can someone hint me how to debug such a situation? I'm unwilling to use Linux > since our > infrastructure is based on FreeBSD and ... well, no further explanation on > that subject ;-) > > Thanks in advance, > > O. Hartmann Forgot this one: [...] usbconfig -d 0.7 dump_all_desc ugen0.7: <Silicon Labs ELV USB-I2C-Interface> at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (500mA) bLength = 0x0012 bDescriptorType = 0x0001 bcdUSB = 0x0110 bDeviceClass = 0x0000 <Probed by interface class> bDeviceSubClass = 0x0000 bDeviceProtocol = 0x0000 bMaxPacketSize0 = 0x0040 idVendor = 0x10c4 idProduct = 0xea60 bcdDevice = 0x0100 iManufacturer = 0x0001 <Silicon Labs> iProduct = 0x0002 <ELV USB-I2C-Interface> iSerialNumber = 0x0003 <XXXXXXXXXXXXXXXXXXXXX> bNumConfigurations = 0x0001 Configuration index 0 bLength = 0x0009 bDescriptorType = 0x0002 wTotalLength = 0x0020 bNumInterfaces = 0x0001 bConfigurationValue = 0x0001 iConfiguration = 0x0000 <no string> bmAttributes = 0x0080 bMaxPower = 0x00fa Interface 0 bLength = 0x0009 bDescriptorType = 0x0004 bInterfaceNumber = 0x0000 bAlternateSetting = 0x0000 bNumEndpoints = 0x0002 bInterfaceClass = 0x00ff <Vendor specific> bInterfaceSubClass = 0x0000 bInterfaceProtocol = 0x0000 iInterface = 0x0002 <ELV USB-I2C-Interface> Endpoint 0 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0081 <IN> bmAttributes = 0x0002 <BULK> wMaxPacketSize = 0x0040 bInterval = 0x0000 bRefresh = 0x0000 bSynchAddress = 0x0000 Endpoint 1 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0001 <OUT> bmAttributes = 0x0002 <BULK> wMaxPacketSize = 0x0040 bInterval = 0x0000 bRefresh = 0x0000 bSynchAddress = 0x0000 -- O. Hartmann
