SDK Unable to Find Device for MC7455

Ive have followed the QMI SDK documentation, and done extensive Google searching (with a lot of results being on this forum), but even though it SEEMS like everything is connected and functioning properly, the SDK is still unable to find the Modem.

Hardware:
Minicard Development Kit
MC7455
USB Power/Connector

I downloaded the latest Linux SDK (04.00.18) as well as Drivers (S2.36N2.55).

The SDK came pre-built, and I loaded up the drivers successfully (to my knowledge). I read that the MC7455 required RAWIP to work when compiling, so I did that (and you can see it in the dmesg output below)

System specs:

tech@scorpius:~$ uname -a
Linux scorpius 4.15.0-43-generic #46-Ubuntu SMP Thu Dec 6 14:45:28 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

tech@scorpius:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 18.04.1 LTS
Release: 18.04
Codename: bionic

Connection Info:

tech@scorpius:~$ lsusb
Bus 003 Device 005: ID 1199:9071 Sierra Wireless, Inc.

tech@scorpius:~$ lsmod | grep -i gob
GobiSerial 20480 1
usbserial 45056 3 GobiSerial
GobiNet 417792 0
usbnet 45056 1 GobiNet

dmesg:

[66163.752462] usb 3-6: new high-speed USB device number 7 using xhci_hcd
[66163.901802] usb 3-6: config 1 has an invalid interface number: 8 but max is 4
[66163.901808] usb 3-6: config 1 has an invalid interface number: 10 but max is 4
[66163.901812] usb 3-6: config 1 has no interface number 1
[66163.901815] usb 3-6: config 1 has no interface number 4
[66163.902441] usb 3-6: New USB device found, idVendor=1199, idProduct=9071
[66163.902445] usb 3-6: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[66163.902449] usb 3-6: Product: Sierra Wireless MC7455 Qualcomm® Snapdragon™ X7 LTE-A
[66163.902452] usb 3-6: Manufacturer: Sierra Wireless, Incorporated
[66163.902455] usb 3-6: SerialNumber: LQ72769152011020
[66163.904323] GobiSerial 3-6:1.0: GobiSerial converter detected
[66163.904622] usb 3-6: GobiSerial converter now attached to ttyUSB0
[66163.905452] GobiSerial 3-6:1.2: GobiSerial converter detected
[66163.905672] usb 3-6: GobiSerial converter now attached to ttyUSB1
[66163.906580] GobiSerial 3-6:1.3: GobiSerial converter detected
[66163.906783] usb 3-6: GobiSerial converter now attached to ttyUSB2
[66163.907753] GobiNet 3-6:1.8 eth0: register ‘GobiNet’ at usb-0000:00:14.0-6, GobiNet Ethernet Device, f2:32:bf:9f:b5:5a
[66163.907847] USB Speed : USB 2.0
[66163.908656] GobiNet 3-6:1.10 eth1: register ‘GobiNet’ at usb-0000:00:14.0-6, GobiNet Ethernet Device, f2:32:bf:9f:b5:5a
[66163.908782] USB Speed : USB 2.0
[66163.934355] GobiNet 3-6:1.8 enp0s20u6i8: renamed from eth0
[66163.956855] GobiNet 3-6:1.10 enp0s20u6i10: renamed from eth1
[66163.988938] IPv6: ADDRCONF(NETDEV_UP): enp0s20u6i8: link is not ready
[66163.989030] IPv6: ADDRCONF(NETDEV_UP): enp0s20u6i8: link is not ready
[66163.998534] IPv6: ADDRCONF(NETDEV_UP): enp0s20u6i10: link is not ready
[66163.998659] IPv6: ADDRCONF(NETDEV_UP): enp0s20u6i10: link is not ready
[66177.236584] creating qcqmi0
[66177.236784] RawIP mode
[66181.552662] creating qcqmi1
[66181.552944] RawIP mode

I also read that the modem needs to be in QMI mode and not mbim, which I believe I did via AT commands (yes AT commands work just fine on /dev/ttyUSB2 via minicom).

AT
OK
AT!ENTERCND=“A710”
OK
AT!USBCOMP?
Config Index: 1
Config Type: 1 (Generic)
Interface bitmask: 0000050D (diag,nmea,modem,rmnet0,rmnet1)
OK

I unfortunately do NOT have a /var/log/user.log file, but this is what I get when trying to run the qatest.

./qatesthostx86_64 -p …/…/build/bin/hostx86_64/slqssdk

Using …/…/build/bin/hostx86_64/slqssdk
Unable to find device…
Unable to find device…

Anyone have any tips/pointers? I would love to get the logs running if anyone knows how to get that working as well (would probably assist you and me both).

Got logs working I am stupid:

SU:Process Started, version: SLQS04.00.18
SU:7 → task started
QM:Task started
SU:12 → task started
UDIAG:DS Shell launched
UDIAG:DS Shell launched
SU:17 → task started
>>MM sn or usb [0] LQ72769152011020
#012=====swi_ossdkusbscan=====line:1886
#012=====swi_ossdkusbscan=====line:1886
QM:qmqmireq/2215: Request: QMI Instance 0
QM:SDK->Mdm: request received : ipcch/svctype/xactionlen/clientnum: 0/00f7/4/12
QM:SDK->Mdm: request validated : ipcch/svctype/xactionlen/clientnum: 0/00f7/4/12
QM:SDK->DCS: Request Sent : ipcch/xactionid: 0/0001
QM-DCS:SDK->DCS: Request Received : ipcch/xactionid: 0/0001
QM:qmshortresp( 6, ch: 0)
#012=====swi_ossdkusbscan=====line:1886
#012=====swi_ossdkusbscan=====line:1886
QM:qmqmireq/2215: Request: QMI Instance 0
QM:SDK->Mdm: request received : ipcch/svctype/xactionlen/clientnum: 0/00f7/4/12
QM:SDK->Mdm: request validated : ipcch/svctype/xactionlen/clientnum: 0/00f7/4/12
QM:SDK->DCS: Request Sent : ipcch/xactionid: 0/0002
QM-DCS:SDK->DCS: Request Received : ipcch/xactionid: 0/0002
QM:qmshortresp( 6, ch: 0)
#012=====swi_ossdkusbscan=====line:1886
#012=====swi_ossdkusbscan=====line:1886
QM:qmqmireq/2215: Request: QMI Instance 0
QM:SDK->Mdm: request received : ipcch/svctype/xactionlen/clientnum: 0/00f7/4/12
QM:SDK->Mdm: request validated : ipcch/svctype/xactionlen/clientnum: 0/00f7/4/12
QM:SDK->DCS: Request Sent : ipcch/xactionid: 0/0003
QM-DCS:SDK->DCS: Request Received : ipcch/xactionid: 0/0003
QM:qmshortresp( 6, ch: 0)
#012=====swi_ossdkusbscan=====line:1886
SWI0 message repeated 12 times: [ SDK Process: #012=====swi_ossdkusbscan=====line:1886]
unexpected signal SIGTERM, address 0x3e8000013d1
QM-DCS:SDK<-DCS Notif: ch/Msgid/Msglen/Svctype: 1/0014/0/247
QM-DCS:SDK<-DCS Notif: ch/Msgid/Msglen/Svctype: 3/0014/0/247
QM-DCS:SDK<-DCS Notif: ch/Msgid/Msglen/Svctype: 5/0014/0/247
context offset 0x000: 0x71eb00
context offset 0x008: (nil)
context offset 0x010: (nil)
context offset 0x018: 0x246
context offset 0x020: (nil)
context offset 0x028: 0x439890
context offset 0x030: 0x439920
context offset 0x038: (nil)
context offset 0x040: 0x71ebec
context offset 0x048: 0x80
context offset 0x050: 0x7ffe9c12e3a0
context offset 0x058: 0x4002f8
context offset 0x060: 0x1
context offset 0x068: 0xfffffffffffffffc
context offset 0x070: 0x4316a4
context offset 0x078: 0x7ffe9c12e340
context offset 0x080: 0x4316a4
context offset 0x088: 0x246
context offset 0x090: 0x2b000000000033
context offset 0x098: (nil)
context offset 0x0a0: (nil)
context offset 0x0a8: (nil)
context offset 0x0b0: (nil)
context offset 0x0b8: 0x7ffe9c12df40
context offset 0x0c0: 0x4f7ae0
context offset 0x0c8: 0x1
context offset 0x0d0: 0x8
context offset 0x0d8: 0x254306b
context offset 0x0e0: 0x4b0024
context offset 0x0e8: 0x1
context offset 0x0f0: (nil)
context offset 0x0f8: 0x700000000
exiting ----------------------

I solved the issue. For those wondering, the device was creating two device paths at /dev/qcqmi0 and /dev/qcqmi1. The modem needs to be accessed via qcqmi1, but all of the sample apps, including the SDK, are hard coded to access via qcqmi0. The only SampleApp that let’s you specify the modem_index is the Connection Manager.

I copied the code from the Connection Manager that allows for a command line argument to specify modem_index, re-compiled a few other apps, and now they work (specifically was trying to test the Call Handling Application).

I’m not sure why there are 2 qcqmi’s that are created, or what they are both even for. But I just wanted to write this so people would know when testing the SampleApps (would be nice if the developers changed all of the apps to allow for the specifying of modem_index).