Ok, I see. Having a workaround in ModemManager would be great.
I will also try to contact the supplier/manufacturer to see, if this can be changed.
What would be the proper reponse in such a case?
CME ERROR: 14 SIM busy?

Also, from the logs can be seen, that other commands also produced errors during the "warm up" phase, they were just skipped by ModemManager. Is the behavior of such a "warm up" phase specified somewhere? I guess not, I guess when these specifications were created, modems didn't have complex software with such initializing phases.

BR, Christian

Am 10.04.23 um 10:28 schrieb Aleksander Morgado:
Hey Christian,


Hi, I have a SIMCOM_SIM7600E-H modem.

When the Modem is freshly "activated" (eg. after powering on the whole
device, toggling the MPCIE reset pin, unplugging/plugging the MPCIE
card), ModemManager is not able to utilize the modem, it ends in state
    Status   |             state: failed
             |     failed reason: sim-missing
             |       power state: on

at this point, when I restart ModemManager (I don't do anything with the
modem itself), it works, the modem is usable, calls, sms, internet
connection work.

I've looked at the debug output of ModemManager and found this: In the
"bad" case, some of the AT commands fail, where the final straw for
ModemManager seems to be "AT+CPIN?" that is answered with "+CME ERROR:
10" which is interpreted as "SIM not inserted" by ModemManager.
In the "good" case the answer to "AT+CPIN?" is "+CPIN: READY" and
ModemManager is happy.

Using the AT interface manually, I can notice this behavior:
Directly after starting the modem, the answer to "AT+CPIN?" is "+CME
ERROR: 10", only after some 30 seconds, the answer is "+CPIN: READY"
I don't now the standards good enough, to judge if such behavior is
allowed, but I'm pretty sure, that this behavior is the problem for
ModemManager. When the answer to "AT+CPIN?" is "+CME ERROR: 10" once, it
marks the modem as failed without retrying.


Yeah, that's kind of expected, "+CME ERROR: 10" means "SIM not
inserted", and MM trusts what the modem says in this case. It is
actually not uncommon to have this kind of behavior, we have also seen
it in other modems (e.g. MC7710 in MBIM).

For the MBIM case we explicitly treat SIM_NOT_INSERTED as
SIM_NOT_INITIALIZED, so that the generic retry mechanism is applied,
and eventually it will either report the SIM locked/unlocked or
otherwise fail all attempts as SIM_NOT_INSERTED, which is when we
really report the modem in "Failed" state.

It is true that this issue is a modem firmware error; the modem should
not say there is no SIM when the problem is that it hasn't finished
initializing it. If you can report that to the manufacturer it would
be great. Still, we should probably workaround it in MM as well, as we
did for the MBIM case.

I've opened a new issue to track it in gitlab:
https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/725


--
---------------------------------------------------------------------
RADIODATA GmbH
Newtonstr. 18
12489 Berlin
Germany

Homepage:              www.radiodata.biz

USt_IdNr.:             DE 195663499
WEEE-Reg.-Nr.:         DE 63967380

Sitz der Gesellschaft: Berlin
Registergericht:       Amtsgericht Charlottenburg HRB  Nr.: 67865
Geschäftsführer:       Hans-Joachim Langermann, Malte Langermann

Reply via email to