MC7430 GobiNet driver probe fails

IoT Modules MC/EM Series
1

Hi,

I’m trying to get my MC7430 module to work on my embedded linux target but for some reason GobiNet has some troubles with probing. I’m using following versions compiled with RAWIP=1 as application developer’s guide suggests:

GobiNet: 2015-12-08/SWI_2.36
GobiSerial: 2015-08-27/SWI_2.25

When driver gets called GobiSerial is able to create ttyUSB interfaces and I’m able to access the modem with minicom using /dev/ttyUSB2. But as can be seen from following log GobiNet fails in its probe:

usb 1-2: new high speed USB device number 3 using ehci_hcd
usb 1-2: config 1 has an invalid interface number: 12 but max is 4
usb 1-2: config 1 has an invalid interface number: 13 but max is 4
usb 1-2: config 1 has an invalid interface number: 13 but max is 4
usb 1-2: config 1 has no interface number 1
usb 1-2: config 1 has no interface number 4
usb 1-2: New USB device found, idVendor=1199, idProduct=9071
usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-2: Product: MC7430
usb 1-2: Manufacturer: Sierra Wireless, Incorporated
usb 1-2: SerialNumber: LU62630096011012
GobiNet::GobiNetDriverBind invalid interface 0
GobiNet::GobiUSBNetProbe usbnet_probe failed -19
GobiSerial::GobiProbe 
GobiSerial::GobiProbe Num Interfaces = 5
GobiSerial::GobiProbe This Interface = 0
GobiSerial 1-2:1.0: GobiSerial converter detected
usb 1-2: GobiSerial converter now attached to ttyUSB0
GobiNet::GobiNetDriverBind invalid interface 2
GobiNet::GobiUSBNetProbe usbnet_probe failed -19
GobiSerial::GobiProbe 
GobiSerial::GobiProbe Num Interfaces = 5
GobiSerial::GobiProbe This Interface = 2
GobiSerial 1-2:1.2: GobiSerial converter detected
usb 1-2: GobiSerial converter now attached to ttyUSB1
GobiNet::GobiNetDriverBind invalid interface 3
GobiNet::GobiUSBNetProbe usbnet_probe failed -19
GobiSerial::GobiProbe 
GobiSerial::GobiProbe Num Interfaces = 5
GobiSerial::GobiProbe This Interface = 3
GobiSerial 1-2:1.3: GobiSerial converter detected
usb 1-2: GobiSerial converter now attached to ttyUSB2
GobiNet::GobiNetDriverBind Ignoring non vendor class interface #12
GobiNet::GobiUSBNetProbe usbnet_probe failed -19
GobiSerial::GobiProbe 
GobiSerial::GobiProbe Num Interfaces = 5
GobiSerial::GobiProbe This Interface = 12
GobiSerial::GobiProbe Ignoring non vendor class interface #12
GobiNet::GobiNetDriverBind invalid num_altsetting 2
GobiNet::GobiUSBNetProbe usbnet_probe failed -19
GobiSerial::GobiProbe 
GobiSerial::GobiProbe Num Interfaces = 5
GobiSerial::GobiProbe This Interface = 13
GobiSerial::GobiProbe Ignoring non vendor class interface #13

Has anyone else had a similar problem? Any ideas how to fix it? If I replace MC7430 with MC7304 I have no problems at all. Also, if I connect that MC7430 to my windows laptop, it’s working fine so there shouldn’t be anything broken on that module.

-Sami

2

USB interfaces 12 and 13 are MBIM. You must to configure the modem for QMI if you want to use GobiNet. See the AT command reference.

3

Greetings,

I have the same problem. A 3rd party performed a firmware upgrade to change the default carrier from ATT to Verizon. After doing so, the modules are left in QBI mode:

AT!UDINFO?

VID: 0x1199
APP PID: 0x68C0
BOOT PID: 0x68C0
Interface: QBI
Manufacturer: Sierra Wireless, Incorporated
Product: MC7354

The modules which were not upgraded are still in QMI mode and work fine.

I tried sending a AT!UDPID=68C0, but that returns an error, as do AT!UDPID? and AT!UDPID=?.

Any help would be greatly appreciated.

UPDATE!!
I determined my problem. Before issuing UDPID command, you must provide ENTERCND=“A710”

My complete script:

ABORT "NO CARRIER"
ABORT "ERROR"
"" AT

OK AT!ENTERCND="A710"

OK AT!UDPID=68C0

OK AT!RESET

OK

And the new results of UDINFO, note interface now reports QMI:

AT!UDINFO?

VID: 0x1199
APP PID: 0x68C0
BOOT PID: 0x68C0
Interface: QMI
Manufacturer: Sierra Wireless, Incorporated
Product: MC7354
4

Well, it seems the QMI mode is necessary, but not sufficient. The GobiNet drivers now attach to the modem properly, however, now that the modem is in QMI mode, the radio part is not working. The SCACT results in ERROR, as does COPS command.

I know both worked correctly when it was in QBI mode, though I didn’t save any logs from it.

Again, any suggestions are greatly appreciated. Here’s the logs from QMI mode. Apologies for the length.

# cat /var/log/begin_log 
abort on (NO CARRIER)
abort on (ERROR)
send (AT^M)
expect (OK)
AT

OK
 -- got it

send (AT!GSTATUS?^M)
expect (OK)

AT!GSTATUS?

!GSTATUS:
Current Time:  29               Temperature: 42
Bootup Time:   5                Mode:        ONLINE
System mode:   WCDMA            PS state:    Not attached
WCDMA band:    WCDMA 2100
WCDMA channel: 10618
GMM (PS) state:DEREGISTERED     NO IMSI
MM (CS) state: IDLE             PLMN SEARCH

WCDMA L1 state:L1M_ACQ          LAC:         0000 (0)
RRC state:   DISCONNECTED       Cell ID:     00000000 (0)
RxM RSSI C0:   -86              RxD RSSI C0: -106
RxM RSSI C1:   -106             RxD RSSI C1: -106


OK
 -- got it

send (AT!PCINFO?^M)
expect (OK)

AT!PCINFO?

State: Online
LPM force flags - W_DISABLE:0, User:0, Temp:0, Volt:0, BIOS:0, GOBIIM:0
W_DISABLE: 0
Poweroff mode: 0
LPM Persistent: 0


OK
 -- got it

send (AT!PCVOLT?^M)
expect (OK)

AT!PCVOLT?

Volt state: Normal
Power supply voltage: 3356 mV


OK
 -- got it

send (AT+CFUN?^M)
expect (OK)


AT+CFUN?

+CFUN: 1

OK
 -- got it

send (AT+CFUN=1^M)
expect (OK)

AT+CFUN=1

OK
 -- got it

send (AT+CGDCONT?^M)
expect (OK)


AT+CGDCONT?

+CGDCONT: 1,"IP","isp.telus.com","0.0.0.0",0,0
+CGDCONT: 1,"IP","vpn.telus.com","0.0.0.0",0,0

OK
 -- got it

send (AT!SCACT=1,1^M)
expect (OK)

AT!SCACT=1,1

ERROR
 -- failed
Failed (ERROR)
# 
# cat /var/log/cell_info
abort on (NO CARRIER)
abort on (ERROR)
send (AT^M)
expect (OK)
AT


OK
 -- got it

send (AT!UDINFO?^M)
expect (OK)

AT!UDINFO?


VID: 0x1199
APP PID: 0x68C0
BOOT PID: 0x68C0
Interface: QMI
Manufacturer: Sierra Wireless, Incorporated
Product: MC7354


OK
 -- got it

send (AT+COPS=?^M)
expect (OK)

AT+COPS=?

alarm
Failed
#
5

You could try using other connection methods. It seems you are using pppd, not sure if this is supported anymore.

6

Hi,

I got mine working after I changed vid/pid from 0x1199/0x9071 to 0x1199/0x68C0. Thanks for your replies.

Sami

7

I figured out the problem with the SCACT & COPS. It was an antenna issue.

It now appears I can connect to a Verizon cell (!SCACT command result is OK); however, I don’t get a response to my DHCP discovery packets. The FAE is saying !SCACT is not supported and I have to use the SDK, but that sounds suspect to me. !SCACT works fine using default firmware programmed for ATT, even with Verizon: I used a Verizon SIM and Verizon APN and get a E-UTRAN tower (per AcT field in the +COPS? reply). He cannot explain why it stops working when I switch to Verizon firmware.

One thing I noticed is that when I have the default “ATT” firmware !GSTATUS command shows IMS reg state: No Srv, while when I have the modem programmed with Verizon firmware !GSTATUS command shows IMS reg state: Full Srv IMS mode: Normal.

Does anyone know if IMS somehow alters the process for connecting and getting an IP address?

Thanks much.

8

UPDATE: I got a third modem, this one provisioned with Telus fw. Using my Verizon SIM and Verizon APN, I was able to get onto Verizon’s network and served an IP via DHCP.

I checked the !GSTATUS, and IMS reg state reports “No Srv”, same as the default “ATT” firmware. I take this as another data point implicating IMS.

Since this is no longer a driver problem, but a connection issue with the Verizon network, I’ve started a new thread here:
viewtopic.php?f=121&t=10013