AT port not attacted with RM520N-GL

[Pradeep Gopanapalli]

Hi Aleksander,

Thanks for your reply, I will try out the suggested methods.
And another thing is we are planning to update ModemManager
,currently we are at 1.16.6-2) and we can go to 1.20 stable versions.
Is there any stable version that you can push into ModemManager sources?
https://www.freedesktop.org/software/ModemManager/

Thanks,
Pradeep G

On Tue, Feb 13, 2024 at 3:44 AM Aleksander Morgado <
aleksandermj at chromium.org> wrote:

> Hey Pradeep!
>
> >
> > We are using RM520N-GL in our SD-WAN edge device in USB mode on M.2 Slot.
> > We are facing an issue where AT USB ports(ttyUSB2, ttyUSB3) are not
> enumerated .
> > We are using "modemmanager - 1.16.6-2" and also added RM520 blob to "
> /lib/udev/rules.d/77-mm-quectel-port-types.rules" but still the AT port is
> not attached .
> > Please advise any changes needed to resolve this issue.
> >
> > # Quectel RM520
> > # #  ttyUSB0 (if #0): QCDM/DIAG port
> > # #  ttyUSB1 (if #1): GPS data port
> > # #  ttyUSB2 (if #2): AT primary port
> > # #  ttyUSB3 (if #3): AT secondary port
> > ATTRS{idVendor}=="2c7c", ATTRS{idProduct}=="0801",
> ENV{.MM_USBIFNUM}=="00", ENV{ID_MM_PORT_TYPE_QCDM}="1"
> > ATTRS{idVendor}=="2c7c", ATTRS{idProduct}=="0801",
> ENV{.MM_USBIFNUM}=="01", ENV{ID_MM_PORT_TYPE_GPS}="1"
> > ATTRS{idVendor}=="2c7c", ATTRS{idProduct}=="0801",
> ENV{.MM_USBIFNUM}=="02", ENV{ID_MM_PORT_TYPE_AT_PRIMARY}="1"
> > ATTRS{idVendor}=="2c7c", ATTRS{idProduct}=="0801",
> ENV{.MM_USBIFNUM}=="03", ENV{ID_MM_PORT_TYPE_AT_SECONDARY}="1"
> >
> > In debug message there is log about "port is not AT-capable"
> > >>
> > 2024-01-25T16:45:52.070 DEBUG  daemon ModemManager[8350]: <debug>
> [ttyUSB3/probe] port is not AT-capable
> > 2024-01-25T16:45:52.070 DEBUG  daemon ModemManager[8350]: <debug>
> [ttyUSB2/probe] port is not AT-capable
> >
>
> If the USB ports are exposed by the kernel, but they are not
> responsive by the time MM tries to use them, it may be that MM didn't
> wait long enough. I know we have updated those timeouts many times in
> past releases, and you may be using an older value of the timeout. It
> could also be that MM cannot, for some reason, communicate properly
> with the device.
>
> You should investigate a bit more:
>
> 1) Let it detect the modem without AT ports, wait some minutes, then
> restart ModemManager. Does MM use the AT ports in that case? If it
> doesn't process them yet, then it's not a timing issue.
>
> 2) Try to ignore only one of the TTYs:
>
> Edit 77-mm-quectel-port-types.rules and add:
> ATTRS{idVendor}=="2c7c", ATTRS{idProduct}=="0801",
> ENV{.MM_USBIFNUM}=="03", ENV{ID_MM_PORT_IGNORE}="1"
>
> Then reboot the system. Does MM try to probe and process the non-ignored
> TTY?
>
> --
> Aleksander
>

-- 
This electronic communication and the information and any files transmitted 
with it, or attached to it, are confidential and are intended solely for 
the use of the individual or entity to whom it is addressed and may contain 
information that is confidential, legally privileged, protected by privacy 
laws, or otherwise restricted from disclosure to anyone else. If you are 
not the intended recipient or the person responsible for delivering the 
e-mail to the intended recipient, you are hereby notified that any use, 
copying, distributing, dissemination, forwarding, printing, or copying of 
this e-mail is strictly prohibited. If you received this e-mail in error, 
please return the e-mail to the sender, delete it from your computer, and 
destroy any printed copy of it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/modemmanager-devel/attachments/20240213/257064a7/attachment.htm>