Verdin IMX8M
We are trying to connect a USB device over serial to a carrier board for the Verdin IMX8M.
We can see that the device is mounted, and it seems that we can write successfully to eat, but when we read from the device, the buffer is empty.
Is there some documentation we should read to better understand how to configure these ports for communications with peripheral devices? In the past it just worked, so we haven’t had to think about it.
Greetings @LBeaudry,
Just to make sure I understand your issue. So you have a USB device connected via serial.
What is this USB device? And when you say serial do you mean like serial port/UART?
we can write successfully to eat, but when we read from the device
Also how are you reading and writing to the device?
In the past it just worked, so we haven’t had to think about it.
Do you mean it worked on our hardware/software before? Or are you talking about something else?
Best Regards,
Jeremias
We have a wireless base station that collects instrument data and transmits it to the Toradex carrier board over USB. ttyACM0. We wrote a C program to collect data from this device. On other IoT boards we use this has worked without any issue.
One peculiarity we have seen across all of the Toradex based devices so far is that the system requires a reboot to mount anything over USB. Maybe this is related.
With this Toradex board we have had success connecting modbus rs485 converters over USB, but this device is not working, and it is not working in an unusual way, given that it mounts. I have attached a screenshot showing write success but no reading response.
Ok so this USB device then is a USB modem of sorts it sounds like? Or is it something else entirely?
One peculiarity we have seen across all of the Toradex based devices so far is that the system requires a reboot to mount anything over USB. Maybe this is related.
This sounds strange to me. So you’re saying when you plug in this device or any USB device it doesn’t get enumerated in /dev/* until after you reboot the system? If so that doesn’t sound right to me. USB devices should be initialized shortly after being plugged in, assuming there’s an appropriate driver for that class of device available. Does this phenomenon even happen with a simple USB storage drive?
Also what version of our OS is your software based off of here?
Best Regards,
Jeremias
Yes, any USB device is only recognized after a reboot.
The OS version is TorizonCore 5.7.0+build.17 (dunfell)
Ok something is definitely abnormal here with the USB enumeration on your system. I just did a test using a Verdin i.MX8M Mini and our Dahlia carrier board. I used the same version of software as you stated for my test.
While the system was running I attached a ttyUSB device to the carrier board’s USB port. Without having to reboot the system I can see an entry for /dev/ttyUSB0. I remove and re-attached the device several times without rebooting the system and every time it was enumerated properly.
As you said previously, perhaps this behavior is related somehow to your reading/buffer issue. I assume you’re using a non-Toradex carrier board yes? If possible do you have a Toradex carrier board available to test to see if your device gets mounted immediately without rebooting.
Best Regards,
Jeremias
We are using a non-Toradex board, correct. Unfortunately, we don’t have a Toradex board available for testing.
Devices listed as /dev/ttyUSB0 require a reboot to be recognized but then they work properly.
The problematic device is listed as /dev/ttyACM0; this one appears to be recognized after reboot but still doesn’t work.
Perhaps, there is a difference between these two types of devices that we are not aware of? What shall we look for in the configuration of the carrier board?
Hello Jeremias,
It looks increasingly like the root problem has to do with the linux kernel packaging of Torizon Core. There seem to be lots of other posts on these forums that point in this direction. Maybe bounce this off of some of your colleagues as the problem seems known.
There seem to be lots of other posts on these forums that point in this direction.
@LBeaudry Could you please provide links to these other posts that you are referring to. So that I can get an idea of the issue and communicate it internally if needed.
Best Regards,
Jeremias
Here is a recent one:
The post you linked has a workaround described in it. Can you try this workaround and see if it fixes the issue you have with reading from your USB device. This will answer whether this USB detection issue is related or a separate issue entirely.
Best Regards,
Jeremias
I checked the workaround in that link. Unfortunately we are not able to build the kernel and test it as many boards were already shipped to the fields. I also saw them applying new image and it worked. Now that we are unable to burn image locally, I wonder if we can apply a remote OTA to make an upgrade? We are currently running Torizon Core 5.7.0-build.17.
Here are some info about the USB serial device we are trying to connect to:
Bus 002 Device 002: ID 03eb:2018 Atmel Corp. at90usbkey sample firmware (CDC ACM)
Couldn't open device, some information will be missing
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 2 Communications
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 32
idVendor 0x03eb Atmel Corp.
idProduct 0x2018 at90usbkey sample firmware (CDC ACM)
bcdDevice 10.00
iManufacturer 0
iProduct 0
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x0043
bNumInterfaces 2
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 2 Communications
bInterfaceSubClass 2 Abstract (modem)
bInterfaceProtocol 1 AT-commands (v.25ter)
iInterface 0
CDC Header:
bcdCDC 1.10
CDC Call Management:
bmCapabilities 0x03
call management
use DataInterface
bDataInterface 1
CDC ACM:
bmCapabilities 0x06
sends break
line coding and serial state
CDC Union:
bMasterInterface 0
bSlaveInterface 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0020 1x 32 bytes
bInterval 255
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 10 CDC Data
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
verdin-imx8mm-06996499:~$ dmesg | grep acm
[ 5.788783] cdc_acm 2-1:1.0: ttyACM0: USB ACM device
[ 5.795417] usbcore: registered new interface driver cdc_acm
[ 5.795425] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters
udevadm info -a -n /dev/ttyACM0
Udevadm info starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.
looking at device '/devices/platform/soc@0/soc@0:bus@32c00000/32e50000.usb/ci_hdrc.1/usb2/2-1/2-1:1.0/tty/ttyACM0':
KERNEL=="ttyACM0"
SUBSYSTEM=="tty"
DRIVER==""
ATTR{consumers}==""
ATTR{suppliers}==""
looking at parent device '/devices/platform/soc@0/soc@0:bus@32c00000/32e50000.usb/ci_hdrc.1/usb2/2-1/2-1:1.0':
KERNELS=="2-1:1.0"
SUBSYSTEMS=="usb"
DRIVERS=="cdc_acm"
ATTRS{bInterfaceSubClass}=="02"
ATTRS{consumers}==""
ATTRS{bmCapabilities}=="6"
ATTRS{bAlternateSetting}==" 0"
ATTRS{bNumEndpoints}=="01"
ATTRS{bInterfaceClass}=="02"
ATTRS{authorized}=="1"
ATTRS{suppliers}==""
ATTRS{bInterfaceProtocol}=="01"
ATTRS{bInterfaceNumber}=="00"
ATTRS{supports_autosuspend}=="1"
looking at parent device '/devices/platform/soc@0/soc@0:bus@32c00000/32e50000.usb/ci_hdrc.1/usb2/2-1':
KERNELS=="2-1"
SUBSYSTEMS=="usb"
DRIVERS=="usb"
ATTRS{speed}=="12"
ATTRS{removable}=="unknown"
ATTRS{bDeviceSubClass}=="00"
ATTRS{bMaxPacketSize0}=="32"
ATTRS{bMaxPower}=="100mA"
ATTRS{suppliers}==""
ATTRS{tx_lanes}=="1"
ATTRS{version}==" 2.00"
ATTRS{urbnum}=="78"
ATTRS{bNumConfigurations}=="1"
ATTRS{configuration}==""
ATTRS{rx_lanes}=="1"
ATTRS{devpath}=="1"
ATTRS{bDeviceProtocol}=="00"
ATTRS{busnum}=="2"
ATTRS{bNumInterfaces}==" 2"
ATTRS{authorized}=="1"
ATTRS{bmAttributes}=="80"
ATTRS{ltm_capable}=="no"
ATTRS{maxchild}=="0"
ATTRS{devnum}=="2"
ATTRS{bcdDevice}=="1000"
ATTRS{quirks}=="0x0"
ATTRS{bDeviceClass}=="02"
ATTRS{idProduct}=="2018"
ATTRS{devspec}=="(null)"
ATTRS{bConfigurationValue}=="1"
ATTRS{idVendor}=="03eb"
ATTRS{avoid_reset_quirk}=="0"
ATTRS{consumers}==""
looking at parent device '/devices/platform/soc@0/soc@0:bus@32c00000/32e50000.usb/ci_hdrc.1/usb2':
KERNELS=="usb2"
SUBSYSTEMS=="usb"
DRIVERS=="usb"
ATTRS{manufacturer}=="Linux 5.4.193-5.7.0+git.f78299297185 ehci_hcd"
ATTRS{idVendor}=="1d6b"
ATTRS{suppliers}==""
ATTRS{configuration}==""
ATTRS{bmAttributes}=="e0"
ATTRS{authorized}=="1"
ATTRS{speed}=="480"
ATTRS{idProduct}=="0002"
ATTRS{bNumInterfaces}==" 1"
ATTRS{rx_lanes}=="1"
ATTRS{bMaxPower}=="0mA"
ATTRS{version}==" 2.00"
ATTRS{bDeviceSubClass}=="00"
ATTRS{devnum}=="1"
ATTRS{busnum}=="2"
ATTRS{authorized_default}=="1"
ATTRS{removable}=="unknown"
ATTRS{bMaxPacketSize0}=="64"
ATTRS{urbnum}=="25"
ATTRS{consumers}==""
ATTRS{bDeviceProtocol}=="01"
ATTRS{ltm_capable}=="no"
ATTRS{interface_authorized_default}=="1"
ATTRS{tx_lanes}=="1"
ATTRS{bcdDevice}=="0504"
ATTRS{maxchild}=="1"
ATTRS{bNumConfigurations}=="1"
ATTRS{serial}=="ci_hdrc.1"
ATTRS{bConfigurationValue}=="1"
ATTRS{quirks}=="0x0"
ATTRS{bDeviceClass}=="09"
ATTRS{product}=="EHCI Host Controller"
ATTRS{devpath}=="0"
ATTRS{avoid_reset_quirk}=="0"
looking at parent device '/devices/platform/soc@0/soc@0:bus@32c00000/32e50000.usb/ci_hdrc.1':
KERNELS=="ci_hdrc.1"
SUBSYSTEMS=="platform"
DRIVERS=="ci_hdrc"
ATTRS{role}=="host"
ATTRS{suppliers}==""
ATTRS{consumers}==""
ATTRS{driver_override}=="(null)"
ATTRS{uframe_periodic_max}=="0"
looking at parent device '/devices/platform/soc@0/soc@0:bus@32c00000/32e50000.usb':
KERNELS=="32e50000.usb"
SUBSYSTEMS=="platform"
DRIVERS=="imx_usb"
ATTRS{suppliers}=="regulator.6"
ATTRS{consumers}==""
ATTRS{driver_override}=="(null)"
looking at parent device '/devices/platform/soc@0/soc@0:bus@32c00000':
KERNELS=="soc@0:bus@32c00000"
SUBSYSTEMS=="platform"
DRIVERS==""
ATTRS{suppliers}==""
ATTRS{consumers}==""
ATTRS{driver_override}=="(null)"
looking at parent device '/devices/platform/soc@0':
KERNELS=="soc@0"
SUBSYSTEMS=="platform"
DRIVERS==""
ATTRS{suppliers}==""
ATTRS{consumers}==""
ATTRS{driver_override}=="(null)"
looking at parent device '/devices/platform':
KERNELS=="platform"
SUBSYSTEMS==""
DRIVERS==""
ATTRS{suppliers}==""
ATTRS{consumers}==""
I also saw them applying new image and it worked. Now that we are unable to burn image locally, I wonder if we can apply a remote OTA to make an upgrade? We are currently running Torizon Core 5.7.0-build.17.
Well apparently the issue described in that other post was fixed in our 6.X.Y OS versions. However, it’s not currently possible to update from 5.7.0 to 6.X.Y. You could create a custom image with the workaround based on 5.7.0 then OTA update to that, to test.
As for your root problem with the read issue. I did have another idea, so on TorizonCore we have ModemManager enabled by default. ModemManager has the annoying affect of interacting with tty/serial devices that it suspects to be a modem device. This can interfere if you are trying to interact with this device in parallel. You can try disabling or stopping the ModemManager service, with something like sudo systemctl stop ModemManager.service. Then see if this improves your situation to read/write to the device.
Unfortunately we can’t really provide much more advice on this. We have no knowledge or experience with this specific USB device you are working with, so it’s hard for us to say what could be the issue here. Also there’s no information on this readACM9 application you are using to read and write to your device. There’s also many factors involved with this so it’s hard to narrow down what could be the issue without more specific information that we don’t have.
Best Regards,
Jeremias
Stopping ModemManager.service works like a charm. Actually we applied sudo systemctl disable ModemManager.service as we never want it to block the device. The devices not recognized issue is still there, but I guess we can live with that for now. Those two problems are unrelated I think. Thanks for the hint.
Good to hear that it was just simply ModemManager interfering. I guess it was only interfering with reads and not your writes. As you said I guess the USB detection issue is then a separate issue.
Anyways glad I could be of assistance!
Best Regards,
Jeremias