Hello,
since a couple of months I use a small electronics device from a German company (ELV, "Maker/IoT style stuff"), utilizing a Amtel88 as I2C busmaster and a CP2102 UART chip as USB-UART bridge. Specs and details readable for those with German language knowledge can be found [[here: ELV I2C-USB]] (didn't find any English veriant, nor the electronic connection layout).
With recent Linux (Xubuntu 23.10) and Windows 10 there is no problem connectiong and retrieving data from sensors attached to the device via serial communications: putty (Linux/Windows), cu and CuteCom (Linux). When using FreeBSD (14-STABLE, CURRENT, 13.2-RELENG) with comms/cutecom, cu, tip, I do not have any luck getting two identical pieces to work (while they work with Linux without flaws). The behaviour of FreeBSD's cu line (connection with -speed 115200) is messy: sometimes (no sensor attached) after disconnecting/connecting physically from USB, then connecting via "cu -l /dev/cuaU1 -s 115200" I'm able to hit "?" to retrieve the device's configuration status and some informations about the firmware - then the line dies (no output from(!) the device. I can see the on-device LED flickering after hitting any key, as this is also the case on Linux and indicating that something ist sent towards the device, but while Linux doesn't have any trouble dealing with the device over a long term session retrieving several environmental data, for instance from a Bosch BME280 sensor (humidity, temperature, pressure), this isn't going to work on FreeBSD.
Just for the record: using the same computer for Linux and FreeBSD doesn't change the picture. Nor does the change of the USB HUB, changing the cabling, the base system (AMD, Intel, older, newer) does change anything except Linux works, FreeBSD doesn't. So my conclusion is that FreeBSD's uslcom driver for the CP2102 Silabs family must be the culprit.
I'd like to debug the USB/serial session without recompiling a whole "debugging" OS, so the question is whether I'll be able to simply debug the serial communications.
I'd like to get rid of the Linux clients since our infrastructure is mostly FreeBSD, so I'd like to make this working on my prefered OS.
Here some details probably of interest:
since a couple of months I use a small electronics device from a German company (ELV, "Maker/IoT style stuff"), utilizing a Amtel88 as I2C busmaster and a CP2102 UART chip as USB-UART bridge. Specs and details readable for those with German language knowledge can be found [[here: ELV I2C-USB]] (didn't find any English veriant, nor the electronic connection layout).
With recent Linux (Xubuntu 23.10) and Windows 10 there is no problem connectiong and retrieving data from sensors attached to the device via serial communications: putty (Linux/Windows), cu and CuteCom (Linux). When using FreeBSD (14-STABLE, CURRENT, 13.2-RELENG) with comms/cutecom, cu, tip, I do not have any luck getting two identical pieces to work (while they work with Linux without flaws). The behaviour of FreeBSD's cu line (connection with -speed 115200) is messy: sometimes (no sensor attached) after disconnecting/connecting physically from USB, then connecting via "cu -l /dev/cuaU1 -s 115200" I'm able to hit "?" to retrieve the device's configuration status and some informations about the firmware - then the line dies (no output from(!) the device. I can see the on-device LED flickering after hitting any key, as this is also the case on Linux and indicating that something ist sent towards the device, but while Linux doesn't have any trouble dealing with the device over a long term session retrieving several environmental data, for instance from a Bosch BME280 sensor (humidity, temperature, pressure), this isn't going to work on FreeBSD.
Just for the record: using the same computer for Linux and FreeBSD doesn't change the picture. Nor does the change of the USB HUB, changing the cabling, the base system (AMD, Intel, older, newer) does change anything except Linux works, FreeBSD doesn't. So my conclusion is that FreeBSD's uslcom driver for the CP2102 Silabs family must be the culprit.
I'd like to debug the USB/serial session without recompiling a whole "debugging" OS, so the question is whether I'll be able to simply debug the serial communications.
I'd like to get rid of the Linux clients since our infrastructure is mostly FreeBSD, so I'd like to make this working on my prefered OS.
Here some details probably of interest:
Code:
~: 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 <XXXXXXXXXXXXXXXXXI>
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