Can't get serial port device information

Hello,

I’m trying to retrieve information from my device which is connected to /dev/ttyACM0, but the feedback is completely empty. Here is my little script:

for port in /dev/ttyACM*; do
    echo "port name : $port"
    echo "manufacturer : $(udevadm info -q property -n $port | grep ID_VENDOR)"
    echo "Id vendor : $(udevadm info -q property -n $port | grep ID_VENDOR_ID)"
    echo "ID product : $(udevadm info -q property -n $port | grep ID_MODEL_ID)"
    echo "-----------------------------------"
done

When I run my script this is what I get:

port name: /dev/ttyACM0
manufacturer:
Vendor ID:
Product ID:
-----------------------------------

I use a raspberry PI3
if I do the same command on a raspberry pi4 with raspberry os I get feedback:

**~** for port in **/dev/ttyACM***; do
echo "port name : $port"
echo "manufacturer : $(udevadm info -q property -n $port | grep ID_VENDOR)"
echo "Id vendor : $(udevadm info -q property -n $port | grep ID_VENDOR_ID)"
echo "ID product : $(udevadm info -q property -n $port | grep ID_MODEL_ID)"
echo "-----------------------------------"
done

port name : /dev/ttyACM0
manufacturer : ID_VENDOR=Newland_Auto-ID
ID_VENDOR_ENC=Newland Auto-ID
ID_VENDOR_ID=1eab
ID_VENDOR_FROM_DATABASE=Fujian Newland Computer Co., Ltd
Id vendor : ID_VENDOR_ID=1eab
ID product : ID_MODEL_ID=1a06
-----------------------------------

I also just tested on a raspberry pi4 with balena OS and I have the same problem
Can someone help me ?
Best Regards

Hi there,

to clarify, are you running this script ON the pi3/pi4 to retrieve the information from a device that is connected to it? Have you tried these instructions for enabling serial on the pi3? I2C and Other Interfaces - Balena Documentation

Yes is that, and yes I followed the documentation, I defined my enable_uart=1 variable on my raspberry pi4. Here is an overview of my configuration:

1 Like

Hello @Firat could you please confirm that your container is running with ENV UDEV=1 to your Dockerfile or maybe adding priviledge: true to the service in docker-compose?

Let us know if this works!

Hello,
I found part of the problem. in my local environment I mounted two volumes:

docker run -v /dev:/dev -v /run/udev:/run/udev:ro --rm -it app bash

but when I want to deploy on balena cloud I do not have the rights to mount the volumes:

/dev:/dev and /run/udev:/run/udev:ro

For exemple:

 peripheral:
    image: app
    labels:
      io.balena.features.dbus: '1'
    volumes:
      - 'src:/src'
      - '/dev:/dev'
      - '/run/udev:/run/udev:ro'
    networks:
      - default
      - peripheral
    mem_limit: 300M
    privileged: true
    environment:
      DBUS_SYSTEM_BUS_ADDRESS: 'unix:path=/host/run/dbus/system_bus_socket'

I have this error:
[Error] Deploy failed Bind mounts are not allowed I gonna try with : UDEV=1

1 Like

@Firat why do you try to create the dev or src volumes?

@mpous The src volume, I need it for my application. In fact, the container is a C++ application which allows you to have information on devices connected in series. The bash script that I am showing you is more or less an equivalent of what my application does. I use the script to test first. Concerning the dev volume, I noticed that if I run my container (locally on my PC) with the dev and run/udev volumes my script worked. I told myself that if by mounting the volume locally it works, why not test on docker-compose. :slight_smile:

@mpous Here is the last situation.
In my dockerfile I added:
ENV UDEV=1

my service looks like this:

peripheral:
    image: app
    labels:
      io.balena.features.dbus: '1'
    volumes:
      - 'src:/src'
    networks:
      -default
      -peripheral
    mem_limit: 300M
    privileged: true
    environment:
      DBUS_SYSTEM_BUS_ADDRESS: 'unix:path=/host/run/dbus/system_bus_socket'

I still have the same problem

Please change the dev volume for something different and try @Firat

Find more information here Interact with hardware - Balena Documentation

Is it possible to do something like that:

- "/dev/ttyACM*:/dev/ttyACM*"
1 Like

I deleted the dev volume and added devices, as in the documentation:

  peripheral:
    image: app
    labels:
      io.balena.features.dbus: '1'
    volumes:
      - 'src:/src'
    devices:
      -  "/dev/ttyACM0:/dev/ttyACM0"
      -  "/dev/ttyACM1:/dev/ttyACM1"
      -  "/dev/ttyACM2:/dev/ttyACM2"
    networks:
      - default
      - peripheral
    mem_limit: 300M
    privileged: true
    environment:
      DBUS_SYSTEM_BUS_ADDRESS: 'unix:path=/host/run/dbus/system_bus_socket'

I still have the same problem…

Hi there,

To help more effectively troubleshoot, I’d recommend this:

  • firstly, ignore the container - go to the hostOS, and run the command udevadm info -q property -n /dev/ttyACM0 from the hostOS command line . What comes out, if anything?
  • if this does give the response you expect, with the correct values, then it means that there is something in the container configuration that is wrong. If even that doesn’t work, then it means that there is something else wrong.
  • confirm that you can communicate with the device you are connecting to over serial - manually over the command line using a utility such as screen
  • what is the device you are connecting to the pi? Maybe its not being recognised by Udev and you might need a custom rule?
1 Like

I think the problem is with the container configuration. Here is the output from balena host :

:root@e620ed4:~# udevadm info -q property -n /dev/ttyACM0
DEVPATH=/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.2/1-1.2:1.0/tty/ttyACM0
DEVNAME=/dev/ttyACM0
MAJOR=166
MINOR=0
SUBSYSTEM=tty
USEC_INITIALIZED=14256434
ID_VENDOR=Newland_Auto-ID
ID_VENDOR_ENC=Newland\x20Auto-ID
ID_VENDOR_ID=1eab
ID_MODEL=NLS_IOTC_PRDsUSBVCP
ID_MODEL_ENC=NLS\x20IOTC\x20PRDsUSBVCP
ID_MODEL_ID=1a06
ID_REVISION=0001
ID_SERIAL=Newland_Auto-ID_NLS_IOTC_PRDsUSBVCP_FCCB2972
ID_SERIAL_SHORT=FCCB2972
ID_TYPE=generic
ID_BUS=usb
ID_USB_INTERFACES=:020201:0a0000:
ID_USB_INTERFACE_NUM=00
ID_USB_DRIVER=cdc_acm
ID_PATH=platform-3f980000.usb-usb-0:1.2:1.0
ID_PATH_TAG=platform-3f980000_usb-usb-0_1_2_1_0
ID_MM_CANDIDATE=1
DEVLINKS=/dev/serial/by-path/platform-3f980000.usb-usb-0:1.2:1.0 /dev/serial/by-id/usb-Newland_Auto-ID_NLS_IOTC_PRDsUSBVCP_FCCB2972-if00
TAGS=:systemd:
CURRENT_TAGS=:systemd:
root@e620ed4:~# udevadm info -q property -n $port | grep ID_SERIAL
info: option requires an argument -- 'n'
root@e620ed4:~# udevadm info -q property -n /dev/ttyACM0 | grep ID_SERIAL
ID_SERIAL=Newland_Auto-ID_NLS_IOTC_PRDsUSBVCP_FCCB2972
ID_SERIAL_SHORT=FCCB2972

If a do the same command in my container, I have nothing:

root@285e58bc8530:/app# udevadm info -q property -n /dev/ttyACM0 | grep ID_SERIAL
root@285e58bc8530:/app# 

Also the full command in my container give this :

root@285e58bc8530:/app# udevadm info -q property -n /dev/ttyACM0
DEVPATH=/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.2/1-1.2:1.0/tty/ttyACM0
DEVNAME=/dev/ttyACM0
MAJOR=166
MINOR=0
SUBSYSTEM=tty

That said, I don’t know what is missing in my configuration. I activated uart with

enable_uart=1

In my dockerfile I also have:

ENV UDEV=1

I have the right labels for the service at docker-compose and I have the privileges:

privileged: true
1 Like

ah nice. If you restart the container, while keeping everything physically still connected, do you still get the same result? Sometimes I’ve seen udev not pick up on devices if they are plugged at runtime, lets eliminate that as a possibility next

Yes, after restarting, I still get the same result:

SSH session disconnected
SSH reconnecting...
Spawning shell...
root@d7a139c8548b:/app# udevadm info -q property -n /dev/ttyACM0
DEVPATH=/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.2/1-1.2:1.0/tty/ttyACM0
DEVNAME=/dev/ttyACM0
MAJOR=166
MINOR=0
SUBSYSTEM=tty

thanks for confirming.

what does your dockerfile look like? What is the base image you are using?

I use : debian:bullseye-slim
And here my dockerfile:

FROM debian:bullseye-slim
ENV UDEV=1
RUN apt-get update && DEBIAN_FRONTEND=noninteractive apt-get install -y \
    build-essential \
    qtbase5-dev \
    libc6 \
    daemontools \
    libpcsclite-dev \
    ca-certificates \
    procps \
    libusb-0.1-4 \
    libdbus-1-3 \
    libpcsclite-dev \
    libnfc6 \
    i2c-tools \
    libqt5serialport5-dev \
 && apt-get clean \
 && rm -rf /var/lib/apt/lists/*

RUN qmake -r && make -j$(nproc)

COPY src/libs/libcomValina-* /usr/lib/

RUN pwd;
RUN ls -la

RUN chmod a+x src/peripherals
RUN chmod a+x src/start.sh

CMD ["src/start.sh"]

I think we’re getting close to the problem. The UDEV=1 feature is only something that works with the balenalib base images: Balena base images - Balena Documentation

You could try
FROM balenalib/%%BALENA_ARCH%%--debian:bullseye

instead.

And in your docker-compose, you shouldn’t need to specify devices, you can change it to:

peripheral:
    image: app
    labels:
      io.balena.features.dbus: '1'
    volumes:
      - 'src:/src'
    networks:
      - default
      - peripheral
    mem_limit: 300M
    privileged: true
    environment:
      DBUS_SYSTEM_BUS_ADDRESS: 'unix:path=/host/run/dbus/system_bus_socket'
2 Likes

sorry i made a typo: FROM balenalib/%%BALENA_ARCH%%-debian:bullseye instead

1 Like

Thank you very much for your help, I am pleased to announce that the problem is resolved :slight_smile:

1 Like