I’m using TorizonCore 6.5.0-build.8 on an iMX8MM with quectel modem.
I’m using Modem-Manager to manage the connections without problems.
I’ve only encountered a problem because I need to send some configs with AT commands over the serial port, and it seems modem manager sometimes is blocking the ttyUSB# for AT commands.
I know for sure it is the ModemManager because if I stop the service I’ve got no errors with the sending and receiving data from ttyUSB#. If I start the service, sometimes works, sometimes don’t.
I tried THIS approach by adding a new rule for the modem with the id and id product 2c7c:0125 for the USB modem, ACTION=="add|change", SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", ATTRS{idVendor}=="2c7c", ATTRS{idProduct}=="0125", ENV{ID_MM_DEVICE_IGNORE}="1"
to
/etc/udev/rules.d/99-toradex.rules
but is seems it does not work
Not sure what is the best solution to exchange AT commands to the modem without stopping the service Modem-Manager.
Hope someone can give me some hints here.
I thought I remembered something about multiple channels on those modems that are exposed? How many ttyUSB# are listed after the system is up? Does modem-manager.mmcli -m 1 list them?
From your description, it seems that Modem-Manager occasionally using the ttyUSB# port is the expected behavior.
Therefore, it would not be ideal to stop that communication.
An approach which could allow you to still send AT commands to the modem while keeping Modem-Manager working as expected is to handle the EBUSY error code when you try to open the ttyUSB# on your custom application.
If you get that error code you can try to open the port again some time later.
Waiting for the port to be available does not seems a solution for us, we need to check periodically some data using AT commands.
I’ve also encounter THIS alternative, which kind of works by starting the modem-manager in debug mode with: sudo /usr/sbin/ModemManager --debug
We can later send AT commands and check response with: sudo mmcli -m 0 --command="ATI"
The downside of this approach is the complete garbage of logs that modem-manager spits into journald
I really thought that a more elegant solution can be done here to use the serial ports in “parallel” with modem manager.
So, are both USB3 and USB4 “supposed” to be available for AT commands? Is one of them specifically for modemManager access and the other for other users? Is your “usually” comment when you kill modemManager and are able to access or is there something else there? Does the modemManager use a lock file when it accesses the modem and then respects it when something else accesses the modem?
That is unfortunate, sorry for the incorrect advice.
So we have the following situation:
ModemManager and your application need to use the same serial port
Waiting to open the serial port on your application is not an option
Debug mode gives too many logs and is not ideal for production
I see two possible ways to handle the problem:
Create a custom plugin for ModemManager that does the tasks you require. If inter-process communication is required with your application, this would have to be implemented as well. This approach would be the most proper way to deal with your requirements.
Run ModemManager in debug mode and deal with the increased logs. While debug mode does not allow the log level to be reduced, the logs can be redirected somewhere else with --log-file=. This approach is not recommended, as the debug mode of ModemManager is only intended to be used for debugging.
