Linux device issue with STEVAL-STWINCSV1b and cli_example

TJM · ‎2021-06-04

I'm at a loss to figure out this issue with this sensor box, STWINCSV1b. I can get almost all of the applications to build, run and install, I can send the sensor data to the SD files and stream via USB to a terminal and get the BT and WiFi to work. What I can't get to work is the actual cli_example application to connect to the device. I notice there is no device file generated when it's plugged in via the USB, but lsusb and the logs show the proper information:

kernel: [259152.269021] usb 9-3: new full-speed USB device number 97 using ohci-pci

kernel: [259152.472070] usb 9-3: New USB device found, idVendor=0483, idProduct=5743, bcdDevice= 2.00

kernel: [259152.472075] usb 9-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3

kernel: [259152.472078] usb 9-3: Product: STWIN Multi-Sensor Streaming

kernel: [259152.472081] usb 9-3: Manufacturer: STMicroelectronics

kernel: [259152.472083] usb 9-3: SerialNumber: 204E31845652

Does the cli_example application use raw USB commands to access the box or am I missing a udev file to setup the tty device access, if this is what is needed?

PS: Looking through more logs I found a segfault with the libusb-1.0.so.0.1.0 lib, otherwise cli_example gives me a no device found message.

tjm

TJM · ‎2021-06-05

Solved, and a simple solution, too. On the one hand, I like to find my own resolutions to any issues. On the other hand, the solutions too often are so simple that I have to wonder why I work with this stuff at all. After rebuilding and running the cli_example executable through gdb a more informative error popped up. A permissions error was presented that boiled down to accessing the bus:device file for the USB device, which is why libusb generated the error. The default is to allow user read but not write access, which means any commands sent to the device failed. The cli_example app does appear to use raw USB commands and does not depend on creating a /dev/ttyXXX device for the current user. Running as root worked. Adding a udev rule to permanently change the user permissions for this device solved the problem. The rule is this line,

SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", ATTRS{idVendor}=="0483", ATTRS{idProduct}=="5743",MODE="0666"

in a 50-usb_bus_device.rules file but with the original MODE="0664" changed to MODE="0666". I'm hoping the vendor and product ID for the STWINCSV1 will allow the user permissions changed for only this device.

Added: For a bit more information, with everything working correctly I was able to complete all sections and demonstrations of the Industrial Sensor Logging webinar using Windows10 or Linux.

tjm

View solution in original post

TJM · ‎2021-06-05

Solved, and a simple solution, too. On the one hand, I like to find my own resolutions to any issues. On the other hand, the solutions too often are so simple that I have to wonder why I work with this stuff at all. After rebuilding and running the cli_example executable through gdb a more informative error popped up. A permissions error was presented that boiled down to accessing the bus:device file for the USB device, which is why libusb generated the error. The default is to allow user read but not write access, which means any commands sent to the device failed. The cli_example app does appear to use raw USB commands and does not depend on creating a /dev/ttyXXX device for the current user. Running as root worked. Adding a udev rule to permanently change the user permissions for this device solved the problem. The rule is this line,

SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", ATTRS{idVendor}=="0483", ATTRS{idProduct}=="5743",MODE="0666"

in a 50-usb_bus_device.rules file but with the original MODE="0664" changed to MODE="0666". I'm hoping the vendor and product ID for the STWINCSV1 will allow the user permissions changed for only this device.

Added: For a bit more information, with everything working correctly I was able to complete all sections and demonstrations of the Industrial Sensor Logging webinar using Windows10 or Linux.

tjm

Eleon BORLINI · ‎2021-06-23

Hi @TJM ,

Glad you solved the issue!

Ya, root access should be effective.

Sorry for my very late feedback -I was on vacation and than back on other projects-...

-Eleon

ALogo.1 · ‎2021-08-25

Hey @TJM,

thanks for the post.

I was hitting my head against the wall with the nasty `Error handle Segmentation fault`. Not even once has the idea "Hey, maybe try with sudo" come to my mind. Oh my!...