When communicating between a Raspberry Pi running the latest version of Resin and a Teensy microcontroller I have been getting random messages being sent from the Raspberry Pi to the Teensy that I am not able to recreate on my computer.
I have a simple node application which uses node-serialport to communicate with the Teensy. The node application connects to the Teensy and logs all messages received, it then disconnects and starts again from the beginning. The Teensy is running a script that waits to receive a BEGIN message from the Raspberry Pi and then sends data every 10000 loops. If the Teensy receives any messages over serial it prints them with RECEIVED: followed by the received message.
When running on my computer the Teensy does not receive any messages however when running on the Raspberry Pi the Teensy receives characters which when combined make up PORTCFG alongside repeated characters AT. This data is never sent by the node application so I am at a loss as to where these characters come from. Has anyone seen this character combination when communicating over serial? I can only assume that this is the operating system trying to configure the port, or that some other part of the system is controlling the port.
I have also found that the Teensy does not always reset between tests. This is peculiar behaviour as the Teensy is meant to reset whenever there is no longer a terminal connected over serial. I have tried adjusting the settings on the dashboard for RESIN_HOST_CONFIG_enable_uart and RESIN_HOST_CONFIG_dtoveraly but I believe this is only relevant for when using serial over the GPIO pins (or perhaps not relevant at all). Does the host operating system make use of serial for any function and if so could this be affecting the serial communication within the container?
I have created an issue on the serial port library which shows a little more details on the problem. I have also created a repository node-serialport-issue which includes the code used on both the Raspberry Pi and Teensy microcontroller. This repository can easily be deployed directly to Resin.
I have looked into the advanced logs for the node-serialport library and am getting an error when trying to read data from the device. When both reading and polling it returns bad file descriptor and then does not manage to read any data from the device. If the device is unplugged then the error returned is no such file or directory.
Could this perhaps mean that the mapping to the serial port has corrupted? How does Resin provide the container access to the /dev folder and could there be any malfunction there? Has anyone seen anything similar previously?
serialport:main opening path: /dev/ttyACM0 +12s
serialport:bindings open +12s
serialport:poller Creating poller +12s
serialport:main opened path: /dev/ttyACM0 +9ms
serialport:main _read reading +1ms
serialport:bindings read +10ms
serialport:unixRead Starting read +12s
serialport:unixRead waiting for readable because of code: EAGAIN +1ms
serialport:poller Polling for "readable" +2ms
serialport:poller error Error: bad file descriptor +33ms
serialport:main binding.read error Error: bad file descriptor +35ms
serialport:main disconnected Error: bad file descriptor +0ms
serialport:main #close +1ms
serialport:bindings close +36ms
serialport:main _read queueing _read for after open +0ms
serialport:poller Stopping poller +3ms
serialport:main binding.close finished +5ms
I have created a thread on the Teensy forums to get insight into how to resolve this issue.
A suggestion from Paul Stoffregen, the creator of Teensy, is to look at the syslog file and see if there are any issues logged from the cdc_acm driver when connecting over USB to the Teensy. However, I am not able to find the syslog file in the /var/log folder in either the host or application container.
How can I access the syslog file from the terminal in the dashboard?
Hi @hpgmiskin,
The presence of the string AT in the serial data leads me to believe that ModemManager is trying to configure the serial device as a modem. Could you try stopping the ModemManager service on the host OS using systemctl stop ModemManager and see if those messages still appear?
Thanks so much for your reply @abrodersen, stopping the ModemManager service solved the problem completely. There are no longer any lost communications or random messages received on the device.
Is there a way that I can disable modem manager permanently for an entire application?
A potential way to solve this problem in my case could to add the 49-teensy.rules to /etc/udev/rules.d/ folder. In particular, the following line tells ModemManager to not access the Teensy.
ATTRS{idVendor}=="16c0", ATTRS{idProduct}=="04[789B]?", ENV{ID_MM_DEVICE_IGNORE}="1"
I have attempted to test this by adding the udev rules in the Dockerfile, however, this has not worked as I believe the modification needs to be completed in the host OS.
This issue may be related to ResinOS Issue 317 in which a user reports
On the intel edison, it appears that somehow the serial console is detected as a usb0 ethernet interface. This is problematic because ModemManager thinks it is a modem and continually tries to probe it, which makes the serial console on .dev images unusable.
@abrodersen do you have any ideas how I might be able to test out if this udev rule can correct the issue?
1 Like
For anyone looking for a way to disable ModemManager from within the main container please use the following command.
DBUS_SYSTEM_BUS_ADDRESS=unix:path=/host/run/dbus/system_bus_socket \
dbus-send \
--system \
--reply-timeout=2000 \
--dest=org.freedesktop.systemd1 \
/org/freedesktop/systemd1 \
org.freedesktop.systemd1.Manager.StopUnit \
string:ModemManager.service string:fail