EM8695 stuck in RmNet configuration

IoT Modules
1

We have been working on integrating an EM8695 module for several months. It was initially running firmware version SWIX35C_00.01.14.00, which was updated to SWIX35C_01.01.01.00, then a few weeks ago SWIX35C_02.01.03.00. It has always presented the USB MBIM interface, and our host system expects to see the MBIM interface.

After a power-cycle the EM8695 began presenting the RmNet interface instead of MBIM. We have not been able to find any method to revert it back to MBIM.

The AT interface shows:

AT!USBCOMP?
Config Index: 1
Config Type:  1 (Generic)
Interface bitmask: 0000100D (diag,modem,gnss,rmnet0)

We can use

AT!USBCOMP=1,1,00001009

to set it back to MBIM, but after an AT!RESET or power-cycle the interface always reverts to RmNet.

AT!CUSTOM? shows that MBIMMODE is enabled.

AT!RMARESET=1 didn’t help.

When we use the Windows tool to try and reflash the firmware, it can’t access the MBIM interface, reverts to the serial interface, has an unhandled exception, exits and triggers a kernel panic on the Windows 11 PC.

The latest Linux tool to reflash the firmware refuses to do a reflash because it detects the EM8695 is already running the latest version. The tool does not have a switch to force the update. We don’t have a copy of the tool for an older version of firmware (but if we did, we assume it would refuse to downgrade the firmware).

Does anyone know how we can proceed? How can we force our EM8695 to present the MBIM interface again?

Is this a known fault? It is extremely concerning that if we deploy a product with the EM8695 and it randomly switches to RmNet, the product will no longer function. This will be costly both financially and to our reputation.

2

did you report this issue to your distributor?

Actually I don’t see such issue so far, so not quite sure how to reproduce this issue

at!entercnd="A710"
OK
at!usbcomp=?
!USBCOMP:
AT!USBCOMP=<Config Index>,<Config Type>,<Interface bitmask>
  <Config Index>      - configuration index to which the composition applies, should be 1

  <Config Type>       - 1:Generic 2:USBIF-MBIM

  <Interface bitmask> - diag          - 0x00000001,
                        modem         - 0x00000008,
                        gnss          - 0x00000010,
                        rmnet0        - 0x00000100,
                        mbim          - 0x00001000,

OK
ati3
Manufacturer: Sierra Wireless, Incorporated
Model: EM8695
Revision: SWIX35C_02.01.04.03 2026/04/28 14:53:21
IMEI: 359577770012345
IMEI SV:  3
FSN: G2540554912435
TS.25: 2026.1.12
+GCAP: +CGSM

OK
at!usbcomp?
Config Index: 1
Config Type:  1 (Generic)
Interface bitmask: 00001019 (diag,modem,gnss,mbim)

OK
3

We will report the problem to our distributor.

We don’t know how the problem can be reproduced. It has struck completely at random following a power-cycle. The firmware appears to have got into a bad state and cannot be recovered using AT commands.

Are there any undocumented AT commands we could try to force a really hard reset of the firmware?

Our EM8695 reports:

ATI3
Manufacturer: Sierra Wireless, Incorporated
Model: EM8695
Revision: SWIX35C_02.01.03.00 2026/03/30 12:18:22
IMEI: 359577770020950
IMEI SV:  3
FSN: G25244335802H0
TS.25: 2026.1.12
+GCAP: +CGSM

When will the SWIX35C_02.01.04.03 firmware be available?

4

it is quite strange that from your AT command response:

AT!USBCOMP?
Config Index: 1
Config Type:  1 (Generic)
Interface bitmask: 0000100D (diag,modem,gnss,rmnet0)

Actually 0x100d means MBIM, but still it shows RMNET…

SWIX35C_02.01.04.03 is just an internal firmware test build, but I don’t think it is related to this issue

If you plug into Linux PC, does it still show RMNET in dmesg or it will show MBIM in dmesg?

BTW, to flash again FW 02.01.03.00, you can get an older firmware from distributor, and then go to an old firmware and go back to current firmware.

5

On a Linux PC, with a EM8695 that is working correctly, lsusb -t -v shows:

/:  Bus 003.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/16p, 480M
    ID 1d6b:0002 Linux Foundation 2.0 root hub
    |__ Port 003: Dev 044, If 0, Class=Vendor Specific Class, Driver=qcserial, 480M
        ID 1199:90e5 Sierra Wireless, Inc. 
    |__ Port 003: Dev 044, If 3, Class=Vendor Specific Class, Driver=qcserial, 480M
        ID 1199:90e5 Sierra Wireless, Inc. 
    |__ Port 003: Dev 044, If 12, Class=Communications, Driver=cdc_mbim, 480M
        ID 1199:90e5 Sierra Wireless, Inc. 
    |__ Port 003: Dev 044, If 13, Class=CDC Data, Driver=cdc_mbim, 480M
        ID 1199:90e5 Sierra Wireless, Inc.

The Application Developers Guide document shows that for the MBIM mode interfaces 12 and 13 are the MBIM network interface on “9x50, 9x30 based modules”. The cdc_mbim driver is being used.

With the non-working EM8695:

Bus 003.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/16p, 480M
    ID 1d6b:0002 Linux Foundation 2.0 root hub
    |__ Port 003: Dev 042, If 0, Class=Vendor Specific Class, Driver=qcserial, 480M
        ID 1199:90e5 Sierra Wireless, Inc. 
    |__ Port 003: Dev 042, If 3, Class=Vendor Specific Class, Driver=qcserial, 480M
        ID 1199:90e5 Sierra Wireless, Inc. 
    |__ Port 003: Dev 042, If 4, Class=Vendor Specific Class, Driver=[none], 480M
        ID 1199:90e5 Sierra Wireless, Inc. 
    |__ Port 003: Dev 042, If 8, Class=Vendor Specific Class, Driver=[none], 480M
        ID 1199:90e5 Sierra Wireless, Inc.

The Application Developers Guide shows that interface 8 is the Rmnet interface. No driver is available for this. We don’t know what interface 4 is.

So we are reasonably sure that the broken EM8695 is presenting Rmnet instead of MBIM.

6

Does the qmi_wwan driver in MBPL work?

7

With the qmi_wwan driver built and loaded on Ubuntu 24.04, lsusb -t still shows no driver for the Rmnet interface.

8

I can see the qmi_wwan.c includes the EM8695:


	{QMI_QUIRK_SET_DTR_QMI_8K(0x1199, 0x90e5, 8)},	/* Sierra Wireless EM8695 RmNET */
9

Sorry, I hadn’t restarted my PC. Now that I have, I do see the qmi_wwan driver being loaded for the Rmnet interface:

/:  Bus 001.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/16p, 480M
    ID 1d6b:0002 Linux Foundation 2.0 root hub
    |__ Port 003: Dev 005, If 0, Class=Vendor Specific Class, Driver=qcserial, 480M
        ID 1199:90e5 Sierra Wireless, Inc. 
    |__ Port 003: Dev 005, If 3, Class=Vendor Specific Class, Driver=qcserial, 480M
        ID 1199:90e5 Sierra Wireless, Inc. 
    |__ Port 003: Dev 005, If 4, Class=Vendor Specific Class, Driver=[none], 480M
        ID 1199:90e5 Sierra Wireless, Inc. 
    |__ Port 003: Dev 005, If 8, Class=Vendor Specific Class, Driver=qmi_wwan, 480M
        ID 1199:90e5 Sierra Wireless, Inc. 

[ 1130.555040] usb 1-3: new high-speed USB device number 5 using xhci_hcd
[ 1130.679983] usb 1-3: config 1 has an invalid interface number: 4 but max is 3
[ 1130.680000] usb 1-3: config 1 has an invalid interface number: 8 but max is 3
[ 1130.680009] usb 1-3: config 1 has no interface number 1
[ 1130.680016] usb 1-3: config 1 has no interface number 2
[ 1130.680603] usb 1-3: New USB device found, idVendor=1199, idProduct=90e5, bcdDevice= 5.15
[ 1130.680619] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 1130.680628] usb 1-3: Product: Sierra Wireless EM8695 Mobile Broadband Adapter
[ 1130.680635] usb 1-3: Manufacturer: Sierra Wireless, Incorporated
[ 1130.680642] usb 1-3: SerialNumber: 359577770020950
[ 1130.704438] qcserial 1-3:1.0: Qualcomm USB modem converter detected
[ 1130.704541] usb 1-3: Qualcomm USB modem converter now attached to ttyUSB0
[ 1130.709390] qcserial 1-3:1.3: Qualcomm USB modem converter detected
[ 1130.709496] usb 1-3: Qualcomm USB modem converter now attached to ttyUSB1
[ 1130.711664] qmi_wwan 1-3:1.8: cdc-wdm1: USB WDM device
[ 1130.711839] [D]qmi_wwan: qmi_wwan dev 00000000b97e5e96 tstats 0000000000000000
[ 1130.712096] qmi_wwan 1-3:1.8 wwan0: register 'qmi_wwan' at usb-0000:00:14.0-3, WWAN/QMI device, da:40:61:f6:40:86
10

then that means the faulty module is really running on RMNET even it says 0x1009 in AT!USBCOMP.
I think you need to report this to your distributor

11

The issue has been reported to our distributor, who has told us that other customers have reported the same problem after moving to the SWIX35C_02.01.03.00 firmware. So hopefully Semtech will resolve this issue quickly and release a firmware update.

To reiterate:

  • The AT!USBCOMP? command on our EM8695 is reporting an interface bitmask of 0000100D (diag,modem,gnss,rmnet0). This is not a valid bitmask. The correct bitmask for that combination would be 00000119.
  • Regardless of what we set the bitmask to, after a power-cycle it has reverted to 0000100D and the Rmnet interface is being used, not MBIM.
  • An attempt to set AT!USBCOMP=1,1,0000100D returns ERROR.
12

How many problematic modules are having this behavior on RMNET?

13

We are developing a new product and working with 2 EM8695 modules. At the moment only 1 module is affected by the Rmnet problem. From our perspective it is a 50% failure rate and we do not know if or when the problem might occur on the second module.