Hi
A customer reported that newer EM7590 modules do not run with ModemManager 1.20.4.
All have firmware SWIX12C_01.01.07.00_GENERIC_001.002_001 programmed.
sudo qmicli -d /dev/cdc-wdm0 -p --dms-get-firmware-preference
reports two different “Unique IDs” (‘001.002_002’ and ‘001.002_001’ for Image type: ‘pri’. Everything else is identical.
Any hint on this?
How about the latest firmware?
Hi jyijyi
Yes, we proposed to test the latest firmware SWIX12C_03.01.02.00_GENERIC_003.000_006.
However the customer wants to know, why the modules do not behave the same with the current firmware SWIX12C_01.01.07.00_GENERIC_001.002_001 and what exactly the difference is. He has over 500 systems in the field.
Regards,
Urban
What interface is used in modemmanager?
AT command?
Mbim interface?
I’m not sure, I have to ask the customer.
yes, need to figure what is wrong in the modem manager.
Hi jyijyi
The customer uses the identical setup (firmware SWIX12C_01.01.07.00_GENERIC_001.002_001, ModemManager 1.20.4).
Older EM7590 do work without problems (for example IMEI 357999720052978), newer EM7590 fail (for example IMEI 357999720316951).
Updating to firmware SWIX12C_03.01.02.00_GENERIC_003.000_006 seems to solve the problem.
Downgrading to firmware SWIX12C_01.01.07.00_GENERIC_001.002_001 brings back the problem on the newer modules.
The two batches of EM7590 have the same sku, but there must be a difference in hardware or in some hidden “firmware”.
Is there anything known at Sierra Wireless about such differences of the same sku?
What interface is used in modemmanager?
AT command?
Mbim interface?
What is getting wrong in the modem manager?
Why don’t you just upgrade the firmware so that issue can be solved?
The customer uses Mbim.
ModemManager does not recognize the EM7590.
The customer will do that, but we have to know why it is dependent on the EM7590 batch and how we can recognize the faulty modules. We did not get any notice or PCN about a change in the EM7590.
The firmware update of over 500 systems distributed in railways allover the world costs a lot of money. It’s not just a single system.
This is a product quality matter. I remember that we already had an issue with the EM7590 where the first batches had an internal eSIM activated insted of the second SIM interface although it was the identical sku.
did you see the cdc-wdm interface in dmesg?
Instead of using modem manager, ow about using mbimcli to establish data connection?
What is the return of AT!USBCOMP? on problematic modules?
Yes, the cdc-wdm interface shows up in dmesg.
The modules are accessible with qmicli commands.
AT!USBCOMP? returns USB composition 8 for both types of modules, which is the default setting.
We do not see any difference beside the issue with ModemManager.
While qmicli has no problem, then why only this 3rd party application modemanager cannot see the MBIM interface?
Did you check any debug log from the modemmanager?
Is there any difference with OK module and NOK module on the following commands?
ati3
AT!impref?
AT!priid?
Here are the logs which the customer provided to us.
Running_SN_17201407.zip (26.1 KB)
Not_Running_SN_17310784.zip (25.9 KB)
I saw “error initializing: Modem in failed state: sim-missing” in the modemmanager log for “Running_SN_17201407”
Is this a OK log or NOK log?
Is there any difference with OK module and NOK module on the following commands?
ati3
AT!impref?
AT!priid?
AT+CPIN?
AT!UIMS?
AT!CUSTOM?
AT+CFUN?
AT!PCINFO?
AT+CGDCONT?
Running_SN_17201407 is the OK log.
I asked the customer to get results for ati3, AT!impref?, AT!priid?. We have to wait for the answer, I guess it will be tomorrow (our current local time is 18:10).
please get more information like below:
ati3
AT!impref?
AT!priid?
AT+CPIN?
AT!UIMS?
AT!CUSTOM?
AT+CFUN?
AT!PCINFO?
AT+CGDCONT?
ok, I’ll ask for it.
BTW, you might need to enable more debug trace in the modemmanager
From the OK log of dmesg, I can see it is using qmi_wwan which is RMNET in AT!USBCOMP
From the NOK log of dmesg, I can see it is using MBIM interface which should be using MBIM in AT!USBCOMP.
Have you really diff the setting of AT!USBCOMP?
According to the customer the OK log was done on a module which was set to USB composition 6. They changed afterwards to USB composition 8 and the ModemManager was still working. All systems in the field have USB composition 8. So this is not the cause.