Re: Accessing I2C-Bus via ELV USB-I2C
On 10/5/22 18:31, Axel Rau wrote: Am 05.10.2022 um 16:46 schrieb Hans Petter Selasky : On 10/5/22 13:55, Axel Rau wrote: If I do not want to touch th USB stuff, can I get the same effect by close/open of the serial device? The uslcom driver only does this right after attach, in 13-stable and 14-main. Does the attached patch make any difference for you? --HPS <0001-uslcom-4-Clear-stall-at-every-open.patch> As this is a production server, I try to avoid reboots. Meanwhile, I have inserted a read loop which eats the fragments and allows the following status query to get a clean response. With this patch, recovery seems to work. Additionally I have eliminated a hub and connected the device directly to a port. Hopefully this will stop the frequent `/dev/cuaU0: Bus connection lost`events. Thanks for your time, Axel --- PGP-Key: CDE74120 ☀ computing @ chaos claudius Hi, You just need to rebuild the uslcom.ko and kldunload it. make -C /usr/src/sys/modules/usb/uslcom all install KMODDIR=/boot/kernel Anyway, here you go: https://cgit.freebsd.org/src/commit/?id=9e0edafe92ad9fc6745ee4c4c58e45a49b9e7ed1 --HPS
Re: Accessing I2C-Bus via ELV USB-I2C
> Am 05.10.2022 um 16:46 schrieb Hans Petter Selasky : > > On 10/5/22 13:55, Axel Rau wrote: >> If I do not want to touch th USB stuff, can I get the same effect by >> close/open of the serial device? > > The uslcom driver only does this right after attach, in 13-stable and 14-main. > > Does the attached patch make any difference for you? > > --HPS > <0001-uslcom-4-Clear-stall-at-every-open.patch> As this is a production server, I try to avoid reboots. Meanwhile, I have inserted a read loop which eats the fragments and allows the following status query to get a clean response. With this patch, recovery seems to work. Additionally I have eliminated a hub and connected the device directly to a port. Hopefully this will stop the frequent `/dev/cuaU0: Bus connection lost`events. Thanks for your time, Axel --- PGP-Key: CDE74120 ☀ computing @ chaos claudius
Re: Accessing I2C-Bus via ELV USB-I2C
On 10/5/22 13:55, Axel Rau wrote:
If I do not want to touch th USB stuff, can I get the same effect by close/open
of the serial device?
The uslcom driver only does this right after attach, in 13-stable and
14-main.
Does the attached patch make any difference for you?
--HPS
From c59ecc6c361f48f08b70d4fed905667b62e21ed6 Mon Sep 17 00:00:00 2001
From: Hans Petter Selasky
Date: Wed, 5 Oct 2022 16:45:21 +0200
Subject: [PATCH] uslcom(4): Clear stall at every open.
To avoid data loss, make sure both the receive and transmit data toggles
get reset, before trying to read or write any data.
MFC after: 1 week
Sponsored by: NVIDIA Networking
---
sys/dev/usb/serial/uslcom.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/sys/dev/usb/serial/uslcom.c b/sys/dev/usb/serial/uslcom.c
index e4367d6781a7..868711afef01 100644
--- a/sys/dev/usb/serial/uslcom.c
+++ b/sys/dev/usb/serial/uslcom.c
@@ -439,12 +439,6 @@ uslcom_attach(device_t dev)
"error=%s\n", usbd_errstr(error));
goto detach;
}
- /* clear stall at first run */
- mtx_lock(>sc_mtx);
- usbd_xfer_set_stall(sc->sc_xfer[USLCOM_BULK_DT_WR]);
- usbd_xfer_set_stall(sc->sc_xfer[USLCOM_BULK_DT_RD]);
- mtx_unlock(>sc_mtx);
-
sc->sc_partnum = uslcom_get_partnum(sc);
error = ucom_attach(>sc_super_ucom, >sc_ucom, 1, sc,
@@ -514,6 +508,10 @@ uslcom_cfg_open(struct ucom_softc *ucom)
DPRINTF("UART enable failed (ignored)\n");
}
+ /* clear stall */
+ usbd_xfer_set_stall(sc->sc_xfer[USLCOM_BULK_DT_WR]);
+ usbd_xfer_set_stall(sc->sc_xfer[USLCOM_BULK_DT_RD]);
+
/* start polling status */
uslcom_watchdog(sc);
}
--
2.37.3
Re: Accessing I2C-Bus via ELV USB-I2C
> Am 04.10.2022 um 13:43 schrieb Hans Petter Selasky : > > Did you clear the endpoint halt condition (for RX BULK endpoint and TX BULK > endpoint), to reset the so-called USB data-toggle, before starting to > communicate with the device? Else you risk loosing a USB packet? If I do not want to touch th USB stuff, can I get the same effect by close/open of the serial device? Axel --- PGP-Key: CDE74120 ☀ computing @ chaos claudius
Re: Accessing I2C-Bus via ELV USB-I2C
On 10/4/22 12:03, Axel Rau wrote:
Am 04.10.2022 um 10:39 schrieb Hans Petter Selasky :
That looks normal.
The DONE transaction transferred the SETUP packet, but still lists frame [0],
but is not dumping the data, because it has already been sent. frame [0] is
always the SETUP packet for control endpoints.
So where should I dig further to find out why the read at 09:28:44.885162 shows
only
'e:' from the string, shown completely at 09:28:47.463632 (2nd block) ?
09:28:44.878743 usbus1.3 SUBM-BULK-EP=0001,SPD=FULL,NFR=1,SLEN=4,IVAL=0
frame[0] WRITE 1 bytes
3F -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- |? |
flags 0x8
status 0xca023
09:28:44.878816 usbus1.3
DONE-BULK-EP=0001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0
frame[0] WRITE 1 bytes
flags 0x8
status 0xca021
09:28:44.885162 usbus1.3
DONE-BULK-EP=0081,SPD=FULL,NFR=1,SLEN=4,IVAL=0,ERR=0
frame[0] READ 2 bytes
65 3A -- -- -- -- -- -- -- -- -- -- -- -- -- -- |e: |
flags 0xa
status 0xcb021
09:28:44.885176 usbus1.3 SUBM-BULK-EP=0081,SPD=FULL,NFR=1,SLEN=0,IVAL=0
frame[0] READ 1024 bytes
flags 0xa
status 0xeb023
09:28:44.888153 usbus1.3
DONE-BULK-EP=0081,SPD=FULL,NFR=1,SLEN=24,IVAL=0,ERR=0
frame[0] READ 24 bytes
31 31 35 32 30 30 20 62 69 74 2F 73 0D 0A 49 32 |115200 bit/s..I2|
0010 43 2D 43 6C 6F 63 6B 3A -- -- -- -- -- -- -- -- |C-Clock:|
flags 0xa
Here I get the right response:
09:28:47.457426 usbus1.3 SUBM-BULK-EP=0001,SPD=FULL,NFR=1,SLEN=4,IVAL=0
frame[0] WRITE 1 bytes
3F -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- |? |
flags 0x8
status 0xca023
09:28:47.457462 usbus1.3
DONE-BULK-EP=0001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0
frame[0] WRITE 1 bytes
flags 0x8
status 0xca021
09:28:47.463632 usbus1.3
DONE-BULK-EP=0081,SPD=FULL,NFR=1,SLEN=68,IVAL=0,ERR=0
frame[0] READ 66 bytes
0D 0A 45 4C 56 20 55 53 42 2D 49 32 43 2D 49 6E |..ELV USB-I2C-In|
0010 74 65 72 66 61 63 65 20 76 31 2E 38 20 28 43 61 |terface v1.8 (Ca|
0020 6C 3A 35 43 29 0D 0A 4C 61 73 74 20 41 64 72 65 |l:5C)..Last Adre|
0030 73 73 3A 30 78 30 30 0D 0A 42 61 75 64 72 61 74 |ss:0x00..Baudrat|
0040 65 3A -- -- -- -- -- -- -- -- -- -- -- -- -- -- |e: |
flags 0xa
status 0xeb021
09:28:47.463644 usbus1.3 SUBM-BULK-EP=0081,SPD=FULL,NFR=1,SLEN=0,IVAL=0
frame[0] READ 1024 bytes
flags 0xa
status 0xcb023
Axel
---
PGP-Key: CDE74120 ☀ computing @ chaos claudius
---
PGP-Key: CDE74120 ☀ computing @ chaos claudius
Did you clear the endpoint halt condition (for RX BULK endpoint and TX
BULK endpoint), to reset the so-called USB data-toggle, before starting
to communicate with the device? Else you risk loosing a USB packet?
--HPS
Re: Accessing I2C-Bus via ELV USB-I2C
Am 04.10.2022 um 10:39 schrieb Hans Petter Selasky : > > That looks normal. > > The DONE transaction transferred the SETUP packet, but still lists frame [0], > but is not dumping the data, because it has already been sent. frame [0] is > always the SETUP packet for control endpoints. > So where should I dig further to find out why the read at 09:28:44.885162 shows only 'e:' from the string, shown completely at 09:28:47.463632 (2nd block) ? 09:28:44.878743 usbus1.3 SUBM-BULK-EP=0001,SPD=FULL,NFR=1,SLEN=4,IVAL=0 frame[0] WRITE 1 bytes 3F -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- |? | flags 0x8 status 0xca023 09:28:44.878816 usbus1.3 DONE-BULK-EP=0001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0 frame[0] WRITE 1 bytes flags 0x8 status 0xca021 09:28:44.885162 usbus1.3 DONE-BULK-EP=0081,SPD=FULL,NFR=1,SLEN=4,IVAL=0,ERR=0 frame[0] READ 2 bytes 65 3A -- -- -- -- -- -- -- -- -- -- -- -- -- -- |e: | flags 0xa status 0xcb021 09:28:44.885176 usbus1.3 SUBM-BULK-EP=0081,SPD=FULL,NFR=1,SLEN=0,IVAL=0 frame[0] READ 1024 bytes flags 0xa status 0xeb023 09:28:44.888153 usbus1.3 DONE-BULK-EP=0081,SPD=FULL,NFR=1,SLEN=24,IVAL=0,ERR=0 frame[0] READ 24 bytes 31 31 35 32 30 30 20 62 69 74 2F 73 0D 0A 49 32 |115200 bit/s..I2| 0010 43 2D 43 6C 6F 63 6B 3A -- -- -- -- -- -- -- -- |C-Clock:| flags 0xa Here I get the right response: 09:28:47.457426 usbus1.3 SUBM-BULK-EP=0001,SPD=FULL,NFR=1,SLEN=4,IVAL=0 frame[0] WRITE 1 bytes 3F -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- |? | flags 0x8 status 0xca023 09:28:47.457462 usbus1.3 DONE-BULK-EP=0001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0 frame[0] WRITE 1 bytes flags 0x8 status 0xca021 09:28:47.463632 usbus1.3 DONE-BULK-EP=0081,SPD=FULL,NFR=1,SLEN=68,IVAL=0,ERR=0 frame[0] READ 66 bytes 0D 0A 45 4C 56 20 55 53 42 2D 49 32 43 2D 49 6E |..ELV USB-I2C-In| 0010 74 65 72 66 61 63 65 20 76 31 2E 38 20 28 43 61 |terface v1.8 (Ca| 0020 6C 3A 35 43 29 0D 0A 4C 61 73 74 20 41 64 72 65 |l:5C)..Last Adre| 0030 73 73 3A 30 78 30 30 0D 0A 42 61 75 64 72 61 74 |ss:0x00..Baudrat| 0040 65 3A -- -- -- -- -- -- -- -- -- -- -- -- -- -- |e: | flags 0xa status 0xeb021 09:28:47.463644 usbus1.3 SUBM-BULK-EP=0081,SPD=FULL,NFR=1,SLEN=0,IVAL=0 frame[0] READ 1024 bytes flags 0xa status 0xcb023 Axel --- PGP-Key: CDE74120 ☀ computing @ chaos claudius > --- PGP-Key: CDE74120 ☀ computing @ chaos claudius
Re: Accessing I2C-Bus via ELV USB-I2C
> Am 04.10.2022 um 10:39 schrieb Hans Petter Selasky : > > > That looks normal. > > The DONE transaction transferred the SETUP packet, but still lists frame [0], > but is not dumping the data, because it has already been sent. frame [0] is > always the SETUP packet for control endpoints. > > --HPS Thanks for your analysis. Axel --- PGP-Key: CDE74120 ☀ computing @ chaos claudius
Re: Accessing I2C-Bus via ELV USB-I2C
On 10/4/22 01:35, Axel Rau wrote:
Am 03.10.2022 um 17:57 schrieb Hans Petter Selasky :
Can you show the full sequence from the SUBM-CTRL-EP ?
- - -
15:46:38.538480 usbus1.3 SUBM-CTRL-EP=,SPD=FULL,NFR=1,SLEN=8,IVAL=0
frame[0] WRITE 8 bytes
41 07 01 01 00 00 00 00 -- -- -- -- -- -- -- -- |A...|
flags 0 <0>
status 0xca1a3
15:46:38.539679 usbus1.3
DONE-CTRL-EP=,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0
frame[0] WRITE 8 bytes
flags 0 <0>
status 0xca1a1
15:46:38.539719 usbus1.3 SUBM-CTRL-EP=,SPD=FULL,NFR=1,SLEN=8,IVAL=0
frame[0] WRITE 8 bytes
41 07 02 02 00 00 00 00 -- -- -- -- -- -- -- -- |A...|
flags 0 <0>
status 0xea1a3
15:46:38.540291 usbus1.3
DONE-CTRL-EP=,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0
frame[0] WRITE 8 bytes
flags 0 <0>
status 0xea1a1
- - -
That looks normal.
The DONE transaction transferred the SETUP packet, but still lists frame
[0], but is not dumping the data, because it has already been sent.
frame [0] is always the SETUP packet for control endpoints.
--HPS
Re: Accessing I2C-Bus via ELV USB-I2C
> Am 03.10.2022 um 17:57 schrieb Hans Petter Selasky : > > Can you show the full sequence from the SUBM-CTRL-EP ? - - - 15:46:38.538480 usbus1.3 SUBM-CTRL-EP=,SPD=FULL,NFR=1,SLEN=8,IVAL=0 frame[0] WRITE 8 bytes 41 07 01 01 00 00 00 00 -- -- -- -- -- -- -- -- |A...| flags 0 <0> status 0xca1a3 15:46:38.539679 usbus1.3 DONE-CTRL-EP=,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0 frame[0] WRITE 8 bytes flags 0 <0> status 0xca1a1 15:46:38.539719 usbus1.3 SUBM-CTRL-EP=,SPD=FULL,NFR=1,SLEN=8,IVAL=0 frame[0] WRITE 8 bytes 41 07 02 02 00 00 00 00 -- -- -- -- -- -- -- -- |A...| flags 0 <0> status 0xea1a3 15:46:38.540291 usbus1.3 DONE-CTRL-EP=,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0 frame[0] WRITE 8 bytes flags 0 <0> status 0xea1a1 - - - Axel --- PGP-Key: CDE74120 ☀ computing @ chaos claudius
Re: Accessing I2C-Bus via ELV USB-I2C
On 10/3/22 17:50, Axel Rau wrote: 15:46:38.539679 usbus1.3 DONE-CTRL-EP=,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0 frame[0] WRITE 8 bytes Hi, For USB control transfers frame[0] contains a copy of the SETUP packet. Maybe the total length exceeds the internal buffer, so that the USB control transfer gets split into multiple parts. Can you show the full sequence from the SUBM-CTRL-EP ? FYI: The frame[0] never contains any data payload for USB control transfers. --HPS
Re: Accessing I2C-Bus via ELV USB-I2C
> Am 03.10.2022 um 17:38 schrieb Hans Petter Selasky : > > On 10/3/22 17:26, Axel Rau wrote: >> Questions: >> 1. On usbdump, why is the hexdump mssing on some lines like >> frame[0] WRITE bytes ? > > The -s arguments tells to only grab the first 1024 bytes. Maybe it is > truncated. > > Try setting -s to 65536 > That does not help: - - - usbdump -d ugen1.3 -v -v -v -s 65536 > usb.txt - - - 15:46:38.539679 usbus1.3 DONE-CTRL-EP=,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0 frame[0] WRITE 8 bytes flags 0 <0> status 0xca1a1 - - - Axel --- PGP-Key: CDE74120 ☀ computing @ chaos claudius
Re: Accessing I2C-Bus via ELV USB-I2C
On 10/3/22 17:26, Axel Rau wrote: Questions: 1. On usbdump, why is the hexdump mssing on some lines like frame[0] WRITE bytes ? The -s arguments tells to only grab the first 1024 bytes. Maybe it is truncated. Try setting -s to 65536 --HPS
Re: Accessing I2C-Bus via ELV USB-I2C
From time to time the I2C layer on top of the uart locks up
and can’t be recovered via its built in reset command.
Initialialization at [1]:2564 is missing the greeting message.
looking at the traffic with
usbdump -d ugen1.3 -v -v -v -s 1024 > usb.txt
I’m missing some response data from the I2C controller.
Questions:
1. On usbdump, why is the hexdump mssing on some lines like
frame[0] WRITE bytes ?
2. Do we have a tool to dump traffic directly on the uart layer?
Any help appreciated, Axel
[1]: https://github.com/mc3/home2l/blob/master/brownies/brownies.C
> Am 27.04.2022 um 23:08 schrieb Axel Rau :
>
> Next journey starts:
>
> For the home2l project, I need a supported I2C interface via USB.
> I got this one:
> https://de.elv.com/elv-usb-ic-interface-usb-i2c-092255?fs=1805459039
> Unfortunately it shows up as a serial device on FreeBSD:
>
> ugen0.2: at usbus0, cfg=0 md=HOST
> spd=FULL (12Mbps) pwr=ON (500mA)
>
> bLength = 0x0012
> bDescriptorType = 0x0001
> bcdUSB = 0x0110
> bDeviceClass = 0x
> bDeviceSubClass = 0x
> bDeviceProtocol = 0x
> bMaxPacketSize0 = 0x0040
> idVendor = 0x10c4
> idProduct = 0xea60
> bcdDevice = 0x0100
> iManufacturer = 0x0001
> iProduct = 0x0002
> iSerialNumber = 0x0003
> bNumConfigurations = 0x0001
>
> In loader.conf, I have:
> uslcom_load="YES"
> iic_load="YES"
> iicbus_loa
>
> But the i2c utility does not show a new bus.
>
> From dmesg:
> root@axels-bsdbox:~ # dmesg | grep iic
> ig4iic0: mem 0xdf23-0xdf230fff
> irq 16 at device 21.0 on pci0
> ig4iic0: Using MSI
> iicbus0: on ig4iic0
> iic0: on iicbus0
> ig4iic1: mem 0xdf22f000-0xdf22
> irq 17 at device 21.1 on pci0
> ig4iic1: Using MSI
> iicbus1: on ig4iic1
> iic1: on iicbus1
> root@axels-bsdbox:~ # dmesg | grep I2C
> ig4iic0: mem 0xdf23-0xdf230fff
> irq 16 at device 21.0 on pci0
> iicbus0: on ig4iic0
> iic0: on iicbus0
> ig4iic1: mem 0xdf22f000-0xdf22
> irq 17 at device 21.1 on pci0
> iicbus1: on ig4iic1
> iic1: on iicbus1
> ugen0.2: at usbus0
> uslcom0: on usbus0
>
> They provide a (linux) driver ("Treiber") which seems to implement the I2C
> protocoll on top of the serial interface.
> Do we have such a driver on FreeBSD, or exist other supported I2C devices to
> be plugged into USB?
>
> Any help appreciated,
> Axel
---
PGP-Key: CDE74120 ☀ computing @ chaos claudius
[RESOLVED] Re: Accessing I2C-Bus via ELV USB-I2C
The application daemon speaks twi over the serial line (/dev/cuaU0)
Everything works perfectly.
Thanks, Axel
Am 27.04.22 um 23:08 schrieb Axel Rau:
Next journey starts:
For the home2l project, I need a supported I2C interface via USB.
I got this one:
https://de.elv.com/elv-usb-ic-interface-usb-i2c-092255?fs=1805459039
Unfortunately it shows up as a serial device on FreeBSD:
ugen0.2: at usbus0, cfg=0 md=HOST
spd=FULL (12Mbps) pwr=ON (500mA)
bLength = 0x0012
bDescriptorType = 0x0001
bcdUSB = 0x0110
bDeviceClass = 0x
bDeviceSubClass = 0x
bDeviceProtocol = 0x
bMaxPacketSize0 = 0x0040
idVendor = 0x10c4
idProduct = 0xea60
bcdDevice = 0x0100
iManufacturer = 0x0001
iProduct = 0x0002
iSerialNumber = 0x0003
bNumConfigurations = 0x0001
In loader.conf, I have:
uslcom_load="YES"
iic_load="YES"
iicbus_loa
But the i2c utility does not show a new bus.
From dmesg:
root@axels-bsdbox:~ # dmesg | grep iic
ig4iic0: mem
0xdf23-0xdf230fff irq 16 at device 21.0 on pci0
ig4iic0: Using MSI
iicbus0: on ig4iic0
iic0: on iicbus0
ig4iic1: mem
0xdf22f000-0xdf22 irq 17 at device 21.1 on pci0
ig4iic1: Using MSI
iicbus1: on ig4iic1
iic1: on iicbus1
root@axels-bsdbox:~ # dmesg | grep I2C
ig4iic0: mem
0xdf23-0xdf230fff irq 16 at device 21.0 on pci0
iicbus0: on ig4iic0
iic0: on iicbus0
ig4iic1: mem
0xdf22f000-0xdf22 irq 17 at device 21.1 on pci0
iicbus1: on ig4iic1
iic1: on iicbus1
ugen0.2: at usbus0
uslcom0: on usbus0
They provide a (linux) driver ("Treiber") which seems to implement the
I2C protocoll on top of the serial interface.
Do we have such a driver on FreeBSD, or exist other supported I2C
devices to be plugged into USB?
Any help appreciated,
Axel
--
PGP-Key: CDE74120 ☀ computing @ chaos claudius
