From nobody Thu Nov 23 19:40:12 2023 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4SbpPb0Mxlz51NfG for ; Thu, 23 Nov 2023 19:40:51 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from smtp052.goneo.de (smtp052.goneo.de [85.220.129.60]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4SbpPY70Frz3bj4 for ; Thu, 23 Nov 2023 19:40:49 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=walstatt-de.de header.s=DKIM001 header.b=EaKMKpvV; spf=none (mx1.freebsd.org: domain of freebsd@walstatt-de.de has no SPF policy when checking 85.220.129.60) smtp.mailfrom=freebsd@walstatt-de.de; dmarc=none Received: from hub2.goneo.de (hub2.goneo.de [IPv6:2001:1640:5::8:53]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by smtp5.goneo.de (Postfix) with ESMTPS id 5CF07240C8E for ; Thu, 23 Nov 2023 20:40:42 +0100 (CET) Received: from hub2.goneo.de (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by hub2.goneo.de (Postfix) with ESMTPS id 849132403AA for ; Thu, 23 Nov 2023 20:40:40 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walstatt-de.de; s=DKIM001; t=1700768440; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=FX04g2yroxRcxdCnI629YwsWEyWaaTlc46E1TP837nw=; b=EaKMKpvV8SiJcbcYx+r702bOJJlH3H/An5GApm9YcjoSjl+ReyRPwKZV1PprIj9v+h2ZUP 0O00fn0G2T1Vij8dvczjTR2QsBupwYXerXdtAVwFabNer8m59wDXFH0Rwi36kI2iztGsXX mtjXVOKxFnOH0sBl6gUZz2envbcFU2pIdJ6ATLtwZj85wlvNZFPgaQ1IRJEowRoFMwEn7M ZevTVcaQ46Fvm7bBFlbFHuy15IibJ4XrCih+r79LjBQ7ypKw1yalsYTTYKPjS83dO0WrjR W6Ja0PfJYtD2J4Jy1ThpK5fgHBDWa7HYgyaLDKTyyADBVqBLuHppTIIxvZgPNw== Received: from thor.intern.walstatt.dynvpn.de (dynamic-089-014-074-227.89.14.pool.telefonica.de [89.14.74.227]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by hub2.goneo.de (Postfix) with ESMTPSA id 37727240269 for ; Thu, 23 Nov 2023 20:40:40 +0100 (CET) Date: Thu, 23 Nov 2023 20:40:12 +0100 From: FreeBSD User To: FreeBSD CURRENT Subject: Re: uSB: uslcom: CP2102 weirdness when serial communication via cu/tip/cutecom Message-ID: <20231123204039.68c77fde@thor.intern.walstatt.dynvpn.de> In-Reply-To: <20231123203753.6ca93cc8@thor.intern.walstatt.dynvpn.de> References: <20231123203753.6ca93cc8@thor.intern.walstatt.dynvpn.de> Organization: walstatt-de.de List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-UID: 4104a1 X-Rspamd-UID: 8ab116 X-Spamd-Result: default: False [-3.29 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.993]; R_DKIM_ALLOW(-0.20)[walstatt-de.de:s=DKIM001]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; DKIM_TRACE(0.00)[walstatt-de.de:+]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_NA(0.00)[no SPF record]; TO_DN_ALL(0.00)[]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; RCPT_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:25394, ipnet:85.220.128.0/17, country:DE]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; HAS_ORG_HEADER(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DMARC_NA(0.00)[walstatt-de.de]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCVD_TLS_ALL(0.00)[] X-Rspamd-Queue-Id: 4SbpPY70Frz3bj4 X-Spamd-Bar: --- Am Thu, 23 Nov 2023 20:37:26 +0100 FreeBSD User 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: 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: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (500mA) bLength = 0x0012 bDescriptorType = 0x0001 bcdUSB = 0x0110 bDeviceClass = 0x0000 bDeviceSubClass = 0x0000 bDeviceProtocol = 0x0000 bMaxPacketSize0 = 0x0040 idVendor = 0x10c4 idProduct = 0xea60 bcdDevice = 0x0100 iManufacturer = 0x0001 iProduct = 0x0002 iSerialNumber = 0x0003 bNumConfigurations = 0x0001 Configuration index 0 bLength = 0x0009 bDescriptorType = 0x0002 wTotalLength = 0x0020 bNumInterfaces = 0x0001 bConfigurationValue = 0x0001 iConfiguration = 0x0000 bmAttributes = 0x0080 bMaxPower = 0x00fa Interface 0 bLength = 0x0009 bDescriptorType = 0x0004 bInterfaceNumber = 0x0000 bAlternateSetting = 0x0000 bNumEndpoints = 0x0002 bInterfaceClass = 0x00ff bInterfaceSubClass = 0x0000 bInterfaceProtocol = 0x0000 iInterface = 0x0002 Endpoint 0 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0081 bmAttributes = 0x0002 wMaxPacketSize = 0x0040 bInterval = 0x0000 bRefresh = 0x0000 bSynchAddress = 0x0000 Endpoint 1 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0001 bmAttributes = 0x0002 wMaxPacketSize = 0x0040 bInterval = 0x0000 bRefresh = 0x0000 bSynchAddress = 0x0000 -- O. Hartmann