EC25 Modem Initialization Failure

Similar to a lot of folks out there

I have a Quectel EC25 connected to a Raspberry Pi CM4 in an Edatec Cm4 Sensing. We have 10 devices deployed and about half of the time, the modem doesn’t initialize properly. We also have a number of devices on which the modem was up, then drops out for a period of time. Basically only a power cycler will work in some cases.
This is a product we’re looking to scale, so, we need help getting ModemManager, NetworkManager and this modem to work reliably.

1 Like

Hey, we use many different CM4 based devices with EC25 modems and have no problems at all.

In our experience, however, there are a few steps that are extremely important to follow:

Configuration adjustments:

  • Enable UART (sometimes)
  • DT parameters must be adjusted correctly
  • DT overlays must be adjusted correctly
  • GPIO pins must be adjusted correctly

Mostly required custom configuration:

  • RESIN_HOST_CONFIG_otg_mode = 1

Often some files have to be added to the device after flashing

  • boot/overlays folder
  • boot folder

What are your settings regarding these points?

1 Like

Thanks for the help! The manufacturer recommended the dtoverlays and params. None of them were specifically addressing the Modem, though.
They also recommended that I reboot the modem on start (a little nuanced in container-land), they have a GPIO attached to the Modem. Doing so once at the start has worked well. There are still times where the modem will show in modem manager’s journal as “unusable”.
Other than writing code to catch that state and reset it again, I am unsure of what to do.

1 Like

Since the EC25 modem is usually used as a USB device with the CM4, the problem is usually due to some USB problems.

If the modem shows up as “unusable”, does “lsusb” show the EC25 modem?

Can you show me your dtoverlays and params as well as GPIO pins settings?

Have you tried the otg_mode too?

If you need to restart the modem on startup, you can write a small container that sends the necessary AT commands to the modem via USB serial upon startup.

For everyone following this thread, we just wanted to share the final solution. The issue was sorted in a Private / Paid Support ticket, but the answer is sharable. :slight_smile:

There are two possible paths we discussed - resetting GPIO from within a container, or by using NetworkManager dispatcher user scripts. The second option was the most effective solution in @rdecarre11’s case, but they both might be useful in different scenarios, so hopefully sharing both is helpful to others!

1. Resetting GPIO from within a container
The recommended approach for this option is to use libgpio, which interacts with the GPIO character device (/dev/gpiochipX ). You can write a small program that links with libgpio directly, or if the reset process is simple enough, you can use gpioset on the command line, which comes with libgpio.

There are a few ways you can access this device from a container:

  • You can map it into the container in your docker-compose.yml under devices
  • You can add CAP_MKNOD to the container and create the device node in your entry script using mknod
  • You can also run the container privileged, which by default recreates all the host’s devices inside of the container, though this is a greater security and stability risk as it disables much of the sandboxing of your application.

2. Using NetworkManager dispatcher scripts
Alternatively, you can add a NetworkManager dispatcher script.

Using the NetworkManager connection check feature, you can detect when the device has lost network connectivity (using the CONNECTIVITY_STATE variable), and bring the modem interface down/up.

You can then use the dispatcher script to reset the modem before the interface is brought up, which should guarantee a known state for the modem when ModemManager finds it.

1 Like