Re: uSB: uslcom: CP2102 weirdness when serial communication via cu/tip/cutecom

Am Thu, 23 Nov 2023 20:37:26 +0100
FreeBSD User <freebsd@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