FORUM
For the last two days I've been trying to get the USB communication operational. I can't pinpoint the issue yet, but it appears to be either caused by the 'cdc_acm' driver, or something on the device side. I managed to get the pure UART up and running, so it seems it's not an issue of the device itself.
The solo is happily blinking the E2 diode, E1 is off, green diode is lit.
After connecting the USB to a linux machine, the device enumerates properly:
$ dmesg
...
[13858.048764] usb 1-1.2: new full-speed USB device number 12 using xhci_hcd
[13858.186299] usb 1-1.2: New USB device found, idVendor=1cbe, idProduct=0002, bcdDevice= 1.00
[13858.186318] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[13858.186335] usb 1-1.2: Product: Virtual COM Port
[13858.186350] usb 1-1.2: Manufacturer: Texas Instruments
[13858.186364] usb 1-1.2: SerialNumber: 12345678
[13858.202618] cdc_acm 1-1.2:1.0: ttyACM0: USB ACM device
$ lsusb -t
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/1p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 1: Dev 3, If 1, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 1: Dev 3, If 2, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 1: Dev 3, If 0, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 2: Dev 12, If 0, Class=Communications, Driver=cdc_acm, 12M
|__ Port 2: Dev 12, If 1, Class=CDC Data, Driver=cdc_acm, 12M
|__ Port 3: Dev 4, If 0, Class=Human Interface Device, Driver=usbhid, 12M
After connecting the device, the first time I'm trying to send data through the /dev/ttyACM0 port, the write seems to succeed (although it may simply be kernel buffering), but the read times out and doesn't return any response. Here, an example using python and pyserial:
$ python3 -c "import serial; s = serial.Serial('/dev/ttyACM0', baudrate=937500, bytesize=serial.EIGHTBITS, parity=serial.PARITY_NONE, stopbits=serial.STOPBITS_ONE, timeout=10); print(s.write(b'\xff\xff\x00\x81\x00\x00\x00\x00\x00\xfe')); print(s.read(10));"
10
(after ~10s)
b''
But after this, each consecutive write will hang on select:
$ python3 -c "import serial; s = serial.Serial('/dev/ttyACM0', baudrate=937500, bytesize=serial.EIGHTBITS, parity=serial.PARITY_NONE, stopbits=serial.STOPBITS_ONE, timeout=10); print(s.write(b'\xff\xff\x00\x81\x00\x00\x00\x00\x00\xfe')); print(s.read(10));"
(after >30s waiting, manual ^C)
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/usr/lib/python3/dist-packages/serial/serialposix.py", line 556, in write
abort, ready, _ = select.select([self.pipe_abort_write_r], [self.fd], [], None)
KeyboardInterrupt
This will repeat until I unplug and plug again (which increases dev id, which is why in these examples SOLO has dev id 12). Two consecutive writes also have the same effect. The same happens regardless of the chosen baudrate (I tried at least with 937500, 921600, 115200 and 9600).
Using tshark and usbmon I can see some data going through:
4939 1882.452496 host → 1.12.1 USB 64 URB_INTERRUPT in
4940 1882.452515 host → 1.12.2 USB 64 URB_BULK in
4941 1882.452521 host → 1.12.2 USB 64 URB_BULK in
4942 1882.452527 host → 1.12.2 USB 64 URB_BULK in
4943 1882.452533 host → 1.12.2 USB 64 URB_BULK in
4944 1882.452539 host → 1.12.2 USB 64 URB_BULK in
4945 1882.452544 host → 1.12.2 USB 64 URB_BULK in
4946 1882.452551 host → 1.12.2 USB 64 URB_BULK in
4947 1882.452557 host → 1.12.2 USB 64 URB_BULK in
4948 1882.452562 host → 1.12.2 USB 64 URB_BULK in
4949 1882.452567 host → 1.12.2 USB 64 URB_BULK in
4950 1882.452573 host → 1.12.2 USB 64 URB_BULK in
4951 1882.452578 host → 1.12.2 USB 64 URB_BULK in
4952 1882.452583 host → 1.12.2 USB 64 URB_BULK in
4953 1882.452589 host → 1.12.2 USB 64 URB_BULK in
4954 1882.452594 host → 1.12.2 USB 64 URB_BULK in
4955 1882.452599 host → 1.12.2 USB 64 URB_BULK in
4956 1882.452611 host → 1.12.0 USBCOM 64 SET CONTROL LINE STATE Request
4957 1882.453521 1.12.0 → host USB 64 URB_CONTROL out
4958 1882.453642 host → 1.12.0 USBCOM 71 SET LINE CODING Request
4959 1882.454263 1.12.0 → host USB 64 URB_CONTROL out
4960 1882.454335 host → 1.12.0 USBCOM 71 SET LINE CODING Request
4961 1882.455014 1.12.0 → host USB 64 URB_CONTROL out
4962 1882.455177 host → ff:ff:00:81:00:00 Ethernet 74 URB_BULK out[Malformed Packet]
4963 1882.455222 1.12.1 → host USB 64 URB_BULK out
4964 1892.470328 host → 1.12.0 USBCOM 64 SET CONTROL LINE STATE Request
4965 1892.470849 1.12.0 → host USB 64 URB_CONTROL out
4966 1892.471202 1.12.1 → host USB 64 URB_INTERRUPT in
4967 1892.471395 1.12.2 → host USB 64 URB_BULK in
4968 1892.471522 1.12.2 → host USB 64 URB_BULK in
4969 1892.471613 1.12.2 → host USB 64 URB_BULK in
4970 1892.471705 1.12.2 → host USB 64 URB_BULK in
4971 1892.471800 1.12.2 → host USB 64 URB_BULK in
4972 1892.472060 1.12.2 → host USB 64 URB_BULK in
4973 1892.472173 1.12.2 → host USB 64 URB_BULK in
4974 1892.472268 1.12.2 → host USB 64 URB_BULK in
4975 1892.472534 1.12.2 → host USB 64 URB_BULK in
4976 1892.472636 1.12.2 → host USB 64 URB_BULK in
4977 1892.472885 1.12.2 → host USB 64 URB_BULK in
4978 1892.472982 1.12.2 → host USB 64 URB_BULK in
4979 1892.473073 1.12.2 → host USB 64 URB_BULK in
4980 1892.473164 1.12.2 → host USB 64 URB_BULK in
4981 1892.473257 1.12.2 → host USB 64 URB_BULK in
4982 1892.473514 1.12.2 → host USB 64 URB_BULK in
4983 1987.930596 host → 1.12.1 USB 64 URB_INTERRUPT in
4984 1987.930618 host → 1.12.2 USB 64 URB_BULK in
4985 1987.930624 host → 1.12.2 USB 64 URB_BULK in
4986 1987.930629 host → 1.12.2 USB 64 URB_BULK in
4987 1987.930635 host → 1.12.2 USB 64 URB_BULK in
4988 1987.930641 host → 1.12.2 USB 64 URB_BULK in
4989 1987.930646 host → 1.12.2 USB 64 URB_BULK in
4990 1987.930654 host → 1.12.2 USB 64 URB_BULK in
4991 1987.930659 host → 1.12.2 USB 64 URB_BULK in
4992 1987.930664 host → 1.12.2 USB 64 URB_BULK in
4993 1987.930670 host → 1.12.2 USB 64 URB_BULK in
4994 1987.930675 host → 1.12.2 USB 64 URB_BULK in
4995 1987.930681 host → 1.12.2 USB 64 URB_BULK in
4996 1987.930686 host → 1.12.2 USB 64 URB_BULK in
4997 1987.930692 host → 1.12.2 USB 64 URB_BULK in
4998 1987.930697 host → 1.12.2 USB 64 URB_BULK in
4999 1987.930702 host → 1.12.2 USB 64 URB_BULK in
5000 1987.930714 host → 1.12.0 USBCOM 64 SET CONTROL LINE STATE Request
5001 1987.931987 1.12.0 → host USB 64 URB_CONTROL out
5002 1987.932114 host → 1.12.0 USBCOM 71 SET LINE CODING Request
5003 1987.932734 1.12.0 → host USB 64 URB_CONTROL out
5004 1987.932806 host → 1.12.0 USBCOM 71 SET LINE CODING Request
5005 1987.933478 1.12.0 → host USB 64 URB_CONTROL out
5006 1987.933615 host → ff:ff:00:81:00:00 Ethernet 74 URB_BULK out[Malformed Packet]
5007 2049.215148 host → 1.12.0 USBCOM 64 SET CONTROL LINE STATE Request
5008 2049.216122 1.12.0 → host USB 64 URB_CONTROL out
5009 2049.216466 1.12.1 → host USB 64 URB_INTERRUPT in
5010 2049.216660 1.12.1 → host USB 64 URB_BULK out
5011 2049.216887 1.12.2 → host USB 64 URB_BULK in
5012 2049.217155 1.12.2 → host USB 64 URB_BULK in
5013 2049.217413 1.12.2 → host USB 64 URB_BULK in
5014 2049.217667 1.12.2 → host USB 64 URB_BULK in
5015 2049.217916 1.12.2 → host USB 64 URB_BULK in
5016 2049.218168 1.12.2 → host USB 64 URB_BULK in
5017 2049.218460 1.12.2 → host USB 64 URB_BULK in
5018 2049.218589 1.12.2 → host USB 64 URB_BULK in
5019 2049.218840 1.12.2 → host USB 64 URB_BULK in
5020 2049.218939 1.12.2 → host USB 64 URB_BULK in
5021 2049.219187 1.12.2 → host USB 64 URB_BULK in
5022 2049.219286 1.12.2 → host USB 64 URB_BULK in
5023 2049.219538 1.12.2 → host USB 64 URB_BULK in
5024 2049.219790 1.12.2 → host USB 64 URB_BULK in
5025 2049.220085 1.12.2 → host USB 64 URB_BULK in
5026 2049.220184 1.12.2 → host USB 64 URB_BULK in
You can see the outgoing packets supposedly sent as malformed Ethernet packets. I'm not sure if this is because usbmon invalidly interprets the packets, or the driver sends them incorrectly.
So far I tried two different linux boxes with modern kernels (mostly on 5.4.51-v7l+ armv7l GNU/Linux) but also on Windows 10 with default VCOM driver (the behaviour was mostly the same, but I checked there the least). I'm quite reluctant to installing unsigned drivers (as the ones provided on this site) and need a solution that ultimately works on armv7l Linux, which shouldn't be this hard.
In the end I can confirm this should be possible, as exactly once I managed to actually get an answer from SOLO:
$ python3 -c "import serial; s = serial.Serial('/dev/ttyACM0', baudrate=937500, bytesize=serial.EIGHTBITS, parity=serial.PARITY_NONE, stopbits=serial.STOPBITS_ONE, timeout=10); s.write(b'\xff\xff\x00\xA2\x00\x00\x00\x00\x00\xfe'); print(s.read(10));"
b'\xff\xff\x00\xa2\x00\x00\xb0\x04\x00\xfe'
$ python3 -c "import serial; s = serial.Serial('/dev/ttyACM0', baudrate=937500, bytesize=serial.EIGHTBITS, parity=serial.PARITY_NONE, stopbits=serial.STOPBITS_ONE, timeout=10); s.write(b'\xff\xff\x00\xA2\x00\x00\x00\x00\x00\xfe'); print(s.read(10));"
b''
But then it went back to the previous behaviour.
All help will be appreaciated. I can provide full(er) tshark/usbmon dumps if someone wants to take a look.
Hi @mdl,
At the moment we have provided our support mostly for Windows, and our Motion Terminal works in the Windows environment with no issues, Regarding Linux support, we had customers before, which they could use SOLO in Linux while using QT environment, and they said it's working normally (check this thread especially the last page), but in your case at the moment, we need to investigate the issue. The Driver we put on our website, by the way, is a signed driver from Texas Instruments and there shouldn't be any issue regarding that matter.
your problem seems with the activation of a serial port or sth similar to that on your machine with USB and hardware looks fine as the USB enumerates, at the moment some of our software engineers are working on that matter, we will get back to you once we have a solution. by the way, we highly appreciate if you share your progress in this case here in this thread so all of us can use it in the future.
We will Remain Available.
Regards
If you found the answers helpful and you could solve your problems, please kindly verify here to help others in the future.
@milad regarding the driver: right, I misinterpreted another warning about unverified source (in the prompt of the .inf file itself), the driver itself is indeed signed. I just checked and it seems to work on Windows 10 with either pyserial or the Chrome Terminal.
I have already read the linked thread. Not much help there, as I'm not developing a QT application, although I share @illylonka's sentiment:
Windows always needs third party drivers, but Linux always works like plug and play
Will try again with a minimal or lower level setup and report if I find anything.
@mdl Great, Yeah, we will also investigate the issue, and if we find some solutions, we will keep you updated here.
Regards
Milad
If you found the answers helpful and you could solve your problems, please kindly verify here to help others in the future.
I have a lead that this might be caused by some system service querying the device using standard CDC codes and Solo not understanding them (and potentially entering some undefined state in the USB driver side of things).
For reference, I found https://unix.stackexchange.com/a/560614 . Using a similar set of rules (accounting for ATTRS{idVendor}=="1cbe", ATTRS{idProduct}=="0002") I managed to get a working and stable setup for a while, but sadly I messed something up and couldn't reproduce it after reboot.
One of the environments I've tested is simply Raspberry Pi 4, so if you need a repro environment you can try it. The other I tested is a live-USB-booted Ubuntu 20.10, so also easy to grab.
I found the solution for the problem.
just do these two things. I was having the same problem with SOLO mini it was not able to communicate with my ubuntu machine then I tried these two things and it solved the problem.
#1
In a terminal, with the board plugged in, enter.
ls -l /dev/ttyACM*, this will show the group that has access to the port.
Example: crw-rw-r-- 1 root dialout ... /dev/ttyACM0, root is owner, dialout is the group with access.
Entering the command, groups, in a terminal will show the groups you belong to.
sudo adduser YourUserName GroupToJoin Will fix things if you need to join a group, logout and login after you run adduser.
modem-manager can also be a problem -- most people just remove the package.
#2
try the following command
sudo chmod a+rw /dev/ttyACM0
