Closed geerlingguy closed 12 months ago
Maybe I have a cursed modem!
haha, I think they are all cursed when they have the lower firmwares.
You could try qmi-firmware-update
this worked for me to unbrick when fwdwl-lite
did not.
Or, maybe upgrading through lower firmwares. Something vaguely sticks in my memory about this but I can't find a source that confirms this.
Where does one acquire qmi-firmware-update
?
libqmi
, I can't say I've used Pi OS but it's in debian package repos if it's debian based
"If possible I’d recommend connecting the modem by USB2 when upgrading from an older firmware. Use an external enclosure with a USB2 cable, or temporarily cover the USB3 pins if you have no other way to disable USB3 on the m.2 slot."
# apt install -y libqmi-utils
# qmi-firmware-update --update --cdc-wdm=/dev/cdc-wdm0 ./swi_fw0105/SWI9X50C_01.05.01.00.cwe ./swi_fw0105/SWI9X50C_01.05.01.00_GENERIC_001.028_000.nvu
loading device information before the update...
setting firmware preference:
firmware version: '01.05.01.00'
config version: '001.028_000'
carrier: 'GENERIC'
rebooting in download mode...
error: error waiting for TTY: waiting for device at '/sys/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb2/2-3' timed out
Then if I run it again:
loading device information before the update...
error: couldn't open QMI device: Operation timed out: device is closed
I might try the external USB enclosure method and try to downrate the speed to USB 2.0 as well. This is quite the annoying diversion :P
These cards are really nice, but the ones I got (admittedly "cheap") also had super old firmware on them and they were terrible to deal with until I upgraded!
I'm going to call it a night and pick back up again soon :) — thanks again for all the handholding here!
Aside: would it be faster to try to upgrade it on a Windows PC?
# apt install -y libqmi-utils # qmi-firmware-update --update --cdc-wdm=/dev/cdc-wdm0 ./swi_fw0105/SWI9X50C_01.05.01.00.cwe ./swi_fw0105/SWI9X50C_01.05.01.00_GENERIC_001.028_000.nvu loading device information before the update... setting firmware preference: firmware version: '01.05.01.00' config version: '001.028_000' carrier: 'GENERIC' rebooting in download mode... error: error waiting for TTY: waiting for device at '/sys/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb2/2-3' timed out
Then if I run it again:
loading device information before the update... error: couldn't open QMI device: Operation timed out: device is closed
What's the vender id and product id of the device in this state? What interfaces does it have open?
You want it to be in download mode (9090), but I'm not sure that setting the product id manually to 9090 actually puts it in the mode
Aside: would it be faster to try to upgrade it on a Windows PC?
Never did that no idea sorry!
In the former case, I see /dev/cdc-wdm0
and ttyUSB[0-2].
And lsusb
shows: Bus 002 Device 003: ID 1199:9091 Sierra Wireless, Inc. EM7565-9
This person has the same firmware and problem: https://forum.sierrawireless.com/t/em7565-cant-upgrade-fw/27550
~MBPL could be interesting~ it's just the same stuff!
Strangely, I got further after another reboot, but it did something very similar to the official tool:
root@waveshare:/home/pi/swi_fw0105# qmi-firmware-update -t /dev/ttyUSB0 --update SWI9X50C_01.05.01.00.cwe SWI9X50C_01.05.01.00_GENERIC_001.028_000.nvu
loading device information before the update...
setting firmware preference:
firmware version: '01.05.01.00'
config version: '001.028_000'
carrier: 'GENERIC'
rebooting in download mode...
download mode detected
downloading cwe image: SWI9X50C_01.05.01.00.cwe (80.2 MB)...
(--*---) 00.0%error: error downloading image: couldn't write in session: couldn't send transfer block 2timed out waiting to write
More confirmation the USB 3.0 link could be the culprit: https://forum.sierrawireless.com/t/updating-em7565-on-openwrt/17723/27?u=geerlingguy
I wonder if I can disable USB 3.0 speeds somehow on the Pi itself?
I tried lspci -nn | grep USB | cut -d '[' -f3 | cut -d ']' -f1 | xargs -I@ setpci -H1 -d @ d0.l=0
as suggested here, but that seems to rely on an Intel-specific flag (-H
) :(
Found this Stack Exchange answer too, but according to the OP that just disables the ports, doesn't downgrade the speed.
All right, so next step is pulling the modem, slapping it in my M.2 B-key to USB adapter, and plugging that into a USB 2.0 port on the Pi, and trying the qmi-firmware-update
command in my comment above again. Whew!
I just realized I don't have a B-key to USB adapter, only mini PCI and M-key/SSD. So I ordered this NGFF(M.2) to USB 3.0 Adapter with Dual Nano SIM Card Slot adapter and it should be here tomorrow.
Reading with bated breath. I have same hardware and same problems with an IIJ MIO sim here in Japan.
With the new adapter, I plugged it into one of the USB 2.0 ports on a spare Pi 4 model B, and I can confirm it's running through the 480Mbps port now:
pi@waveshare:~ $ lsusb -t
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/1p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 4: Dev 3, If 0, Class=Vendor Specific Class, Driver=qcserial, 480M
|__ Port 4: Dev 3, If 2, Class=Vendor Specific Class, Driver=qcserial, 480M
|__ Port 4: Dev 3, If 3, Class=Vendor Specific Class, Driver=qcserial, 480M
|__ Port 4: Dev 3, If 12, Class=Communications, Driver=cdc_mbim, 480M
|__ Port 4: Dev 3, If 13, Class=CDC Data, Driver=cdc_mbim, 480M
Will try qmi-firmware-update
this way and see if it fares any better.
What do you know, it worked over USB 2.0!
root@waveshare:/home/pi/swi_fw0105# qmi-firmware-update -t /dev/ttyUSB0 --update SWI9X50C_01.05.01.00.cwe SWI9X50C_01.05.01.00_GENERIC_001.028_000.nvu
loading device information before the update...
setting firmware preference:
firmware version: '01.05.01.00'
config version: '001.028_000'
carrier: 'GENERIC'
rebooting in download mode...
download mode detected
downloading cwe image: SWI9X50C_01.05.01.00.cwe (80.2 MB)...
finalizing download... (may take several minutes, be patient)
successfully downloaded in 99.67s (804.8 kB/s)
downloading cwe image: SWI9X50C_01.05.01.00_GENERIC_001.028_000.nvu (3.9 kB)...
finalizing download... (may take several minutes, be patient)
successfully downloaded in 0.05s (79.2 kB/s)
rebooting in normal mode...
normal mode detected
------------------------------------------------------------------------
NOTE: in order to validate which is the firmware running in the
module, the program will wait for a complete boot; this process
may take some time and several retries.
------------------------------------------------------------------------
waiting some time for the device to boot...
loading device information after the update (1/12)...
------------------------------------------------------------------------
original firmware revision was:
SWI9X50C_00.06.02.00 f50f0a jenkins 2017/08/25 05:33:58
original running firmware details:
Model: EM7565-9
Boot version: SWI9X50C_00.06.02.00
AMSS version: SWI9X50C_00.06.02.00
Carrier ID: 0
original firmware preference details:
image 'modem': unique id '001.028_000', build id '01.05.01.00_GENERIC'
image 'pri': unique id '001.028_000', build id '01.05.01.00_GENERIC'
new firmware revision is:
SWI9X50C_01.05.01.00 7772ee jenkins 2018/02/23 18:02:21
new running firmware details:
Model: EM7565-9
Boot version: SWI9X50C_01.05.01.00
AMSS version: SWI9X50C_01.05.01.00
Carrier ID: 1
new firmware preference details:
image 'modem': unique id '001.028_000', build id '01.05.01.00_GENERIC'
image 'pri': unique id '001.028_000', build id '01.05.01.00_GENERIC'
NOTE: this device supports stored image management
with qmicli operations:
--dms-list-stored-images
--dms-select-stored-image
--dms-delete-stored-image
NOTE: this device supports firmware preference management
with qmicli operations:
--dms-get-firmware-preference
--dms-set-firmware-preference
------------------------------------------------------------------------
firmware update operation finished successfully
Trying the update to the latest fw now. Will run it twice.
Tried to just update straight to latest but got a timeout:
root@waveshare:/home/pi/swi_fwlatest# qmi-firmware-update -t /dev/ttyUSB0 --update SWI9X50C_01.14.13.00.cwe SWI9X50C_01.14.13.00_GENERIC_002.048_000.nvu
loading device information before the update...
setting firmware preference:
firmware version: '01.14.13.00'
config version: '002.048_000'
carrier: 'GENERIC'
rebooting in download mode...
error: error waiting for TTY: waiting for device at '/sys/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.4' timed out
Going to hard reset power and see if I can get it to boot after that.
Edit: after a reboot I see it with lsusb
, and I can see /dev/cdc-wdm0
, but I don't see the ttyUSB[0-2]
devices anymore. The LED on the breakout board is blinking on and off every second.
Huh, dmesg
shows a stack trace for MBIM:
[ 27.870418] ------------[ cut here ]------------
[ 27.870459] NETDEV WATCHDOG: wwan0 (cdc_mbim): transmit queue 0 timed out
[ 27.870541] WARNING: CPU: 2 PID: 0 at net/sched/sch_generic.c:478 dev_watchdog+0x398/0x3a0
[ 27.870572] Modules linked in: cmac algif_hash aes_arm64 algif_skcipher af_alg bnep hci_uart btbcm bluetooth ecdh_generic ecc 8021q garp stp llc snd_soc_hdmi_codec rpivid_mem bcm2835_v4l2(C) bcm2835_codec(C) bcm2835_isp(C) bcm2835_mmal_vchiq(C) v4l2_mem2mem brcmfmac brcmutil videobuf2_dma_contig videobuf2_vmalloc videobuf2_memops vc4 videobuf2_v4l2 videobuf2_common cfg80211 v3d gpu_sched cec rfkill drm_kms_helper videodev snd_soc_core raspberrypi_hwmon snd_compress snd_bcm2835(C) i2c_brcmstb snd_pcm_dmaengine mc snd_pcm vc_sm_cma(C) snd_timer snd syscopyarea sysfillrect sysimgblt fb_sys_fops nvmem_rmem uio_pdrv_genirq uio cdc_mbim cdc_wdm cdc_ncm cdc_ether drm drm_panel_orientation_quirks fuse backlight ip_tables x_tables ipv6
[ 27.870898] CPU: 2 PID: 0 Comm: swapper/2 Tainted: G C 5.15.32-v8+ #1538
[ 27.870912] Hardware name: Raspberry Pi 4 Model B Rev 1.4 (DT)
[ 27.870921] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 27.870934] pc : dev_watchdog+0x398/0x3a0
[ 27.870945] lr : dev_watchdog+0x398/0x3a0
[ 27.870954] sp : ffffffc0095fbd10
[ 27.870960] x29: ffffffc0095fbd10 x28: ffffff8041992880 x27: 0000000000000004
[ 27.870982] x26: 0000000000000140 x25: 00000000ffffffff x24: 0000000000000002
[ 27.871003] x23: ffffffc009316000 x22: ffffff80431f03dc x21: ffffff80431f0000
[ 27.871023] x20: ffffff80431f0480 x19: 0000000000000000 x18: 0000000000000000
[ 27.871042] x17: ffffffc0f2773000 x16: ffffffc0095fc000 x15: ffffffffffffffff
[ 27.871062] x14: ffffffc008e8a9c8 x13: 74756f2064656d69 x12: ffffffc0093a6670
[ 27.871081] x11: 0000000000000003 x10: ffffffc00938e630 x9 : ffffffc0080ec768
[ 27.871101] x8 : 0000000000017fe8 x7 : 0000000000000003 x6 : 0000000000000000
[ 27.871120] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000103
[ 27.871139] x2 : 0000000000000102 x1 : 8bbaa0590ddbac00 x0 : 0000000000000000
[ 27.871159] Call trace:
[ 27.871166] dev_watchdog+0x398/0x3a0
[ 27.871176] call_timer_fn+0x38/0x1d8
[ 27.871192] run_timer_softirq+0x274/0x508
[ 27.871203] __do_softirq+0x1a8/0x4ec
[ 27.871214] irq_exit+0x110/0x150
[ 27.871229] handle_domain_irq+0x9c/0xe0
[ 27.871245] gic_handle_irq+0xac/0xe8
[ 27.871254] call_on_irq_stack+0x28/0x54
[ 27.871266] do_interrupt_handler+0x60/0x70
[ 27.871278] el1_interrupt+0x30/0x78
[ 27.871294] el1h_64_irq_handler+0x18/0x28
[ 27.871307] el1h_64_irq+0x78/0x7c
[ 27.871316] arch_cpu_idle+0x18/0x28
[ 27.871329] default_idle_call+0x54/0x19c
[ 27.871341] do_idle+0x254/0x268
[ 27.871353] cpu_startup_entry+0x2c/0x80
[ 27.871364] secondary_start_kernel+0x154/0x168
[ 27.871378] __secondary_switched+0x90/0x94
[ 27.871393] ---[ end trace 3a1cdb7eb5332493 ]---
[ 31.710488] cam-dummy-reg: disabling
Trying a firmware update with qmi-firmware-update -t /dev/cdc-wdm0
also results in a timeout. If it ain't one thing, it's another!
rebooting in download mode...
error: error waiting for TTY: waiting for device at '/sys/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.4' timed out
I hotplugged the modem and saw the following in dmesg. No stack traces so far (fingers crossed):
[ 275.369891] usb 1-1.4: new high-speed USB device number 5 using xhci_hcd
[ 275.471620] usb 1-1.4: New USB device found, idVendor=1199, idProduct=90b1, bcdDevice= 0.06
[ 275.471655] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 275.471671] usb 1-1.4: Product: EM7565-9
[ 275.471686] usb 1-1.4: Manufacturer: Sierra Wireless, Incorporated
[ 275.504689] cdc_mbim 1-1.4:1.0: cdc-wdm0: USB WDM device
[ 275.505590] cdc_mbim 1-1.4:1.0 wwan0: register 'cdc_mbim' at usb-0000:01:00.0-1.4, CDC MBIM, ee:a1:f7:c9:ff:0c
[ 275.623956] 8021q: adding VLAN 0 to HW filter on device wwan0
When qmi-firmware-update
reboots the modem, dmesg
prints out:
[ 347.237808] usb 1-1.4: USB disconnect, device number 5
[ 347.238034] cdc_mbim 1-1.4:1.0 wwan0: unregister 'cdc_mbim' usb-0000:01:00.0-1.4, CDC MBIM
[ 348.158344] usb 1-1.4: new high-speed USB device number 6 using xhci_hcd
[ 348.260888] usb 1-1.4: New USB device found, idVendor=1199, idProduct=90b0, bcdDevice= 0.00
[ 348.260904] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 348.260909] usb 1-1.4: Product: QUSB__BULK
[ 348.260914] usb 1-1.4: Manufacturer: Sierra Wireless, Incorporated
But of course no USB TTY shows up. Maybe it's changing the vendor/product ID again?
Yep. I had to force it back:
# modprobe option
# echo 1199 90b1 > /sys/bus/usb-serial/drivers/option1/new_id
// Inside minicom
AT!ENTERCND="A710"?\r\n'
AT!USBPID=9091
And yay, that worked! Gave me a scare since the reboot into normal mode took like 3 minutes this time:
original firmware revision was:
SWI9X50C_01.05.01.00 7772ee jenkins 2018/02/23 18:02:21
original running firmware details:
Model: EM7565-9
Boot version: SWI9X50C_01.05.01.00
AMSS version: SWI9X50C_01.05.01.00
Carrier ID: 1
original firmware preference details:
image 'modem': unique id '002.048_000', build id '01.14.13.00_GENERIC'
image 'pri': unique id '002.048_000', build id '01.14.13.00_GENERIC'
new firmware revision is:
SWI9X50C_01.14.13.00 883709 jenkins 2022/01/05 07:08:35
new running firmware details:
Model: EM7565-9
Boot version: SWI9X50C_01.14.13.00
AMSS version: SWI9X50C_01.14.13.00
Carrier ID: 1
Config version: 001.028_000
new firmware preference details:
image 'modem': unique id '002.048_000', build id '01.14.13.00_GENERIC'
image 'pri': unique id '002.048_000', build id '01.14.13.00_GENERIC'
I'm re-flashing it to be safe. Then I'll work on getting this modem back over in the Waveshare chassis with the SixFab SIM and we'll see if it 'just works' or if there's anything else I need to do.
Looks like everything should be good to go... however I'm in my basement, and it's probably not getting a 4G LTE signal. I wish I had an outdoor antenna that ran down here so I wouldn't have to run everything upstairs to test!
root@OpenWrt:~# mmcli -m 0
----------------------------------
General | path: /org/freedesktop/ModemManager1/Modem/0
| device id: 8cddab4c5cd384bed3467b12abec01a2a9fd0960
----------------------------------
Hardware | manufacturer: Sierra Wireless, Incorporated
| model: EM7565-9
| firmware revision: SWI9X50C_01.14.13.00
| carrier config: default
| h/w revision: EM7565-9
| supported: gsm-umts, lte
| current: gsm-umts, lte
| equipment id: [redacted]
----------------------------------
System | device: /sys/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb2/2-3
| drivers: cdc_mbim
| plugin: sierra
| primary port: cdc-wdm0
| ports: cdc-wdm0 (mbim), wwan0 (net)
----------------------------------
Status | unlock retries: sim-pin2 (10)
| state: enabled
| power state: on
| signal quality: 0% (cached)
----------------------------------
Modes | supported: allowed: 3g; preferred: none
| allowed: 4g; preferred: none
| allowed: 3g, 4g; preferred: 4g
| allowed: 3g, 4g; preferred: 3g
| current: allowed: 2g, 3g, 4g; preferred: 4g
----------------------------------
Bands | supported: utran-1, utran-3, utran-4, utran-6, utran-5, utran-8,
| utran-9, utran-2, eutran-1, eutran-2, eutran-3, eutran-4, eutran-5,
| eutran-7, eutran-8, eutran-9, eutran-12, eutran-13, eutran-18,
| eutran-19, eutran-20, eutran-26, eutran-28, eutran-29, eutran-30,
| eutran-32, eutran-41, eutran-66, utran-19
| current: utran-1, utran-3, utran-4, utran-6, utran-5, utran-8,
| utran-9, utran-2, eutran-1, eutran-2, eutran-3, eutran-4, eutran-5,
| eutran-7, eutran-8, eutran-9, eutran-12, eutran-13, eutran-18,
| eutran-19, eutran-20, eutran-26, eutran-28, eutran-29, eutran-30,
| eutran-32, eutran-41, eutran-66
----------------------------------
IP | supported: ipv4, ipv6, ipv4v6
----------------------------------
3GPP | imei: [redacted]
| enabled locks: fixed-dialing
| registration: idle
----------------------------------
3GPP EPS | initial bearer ip type: ipv4v6
----------------------------------
SIM | primary sim path: /org/freedesktop/ModemManager1/SIM/0
Blog post about the journey to this point: Upgrading 4G LTE modem firmware is an experience.
It's working!!!
Status | unlock retries: sim-pin2 (10)
| state: connected
| power state: on
| access tech: lte
| signal quality: 29% (recent)
It's uh... not very fast right now:
root@OpenWrt:~# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: seq=0 ttl=107 time=2391.845 ms
64 bytes from 8.8.8.8: seq=1 ttl=107 time=2428.172 ms
64 bytes from 8.8.8.8: seq=3 ttl=107 time=948.061 ms
64 bytes from 8.8.8.8: seq=2 ttl=107 time=1951.155 ms
64 bytes from 8.8.8.8: seq=4 ttl=107 time=348.784 ms
64 bytes from 8.8.8.8: seq=6 ttl=107 time=1656.673 ms
64 bytes from 8.8.8.8: seq=7 ttl=107 time=720.385 ms
64 bytes from 8.8.8.8: seq=8 ttl=107 time=1708.277 ms
^C
--- 8.8.8.8 ping statistics ---
11 packets transmitted, 8 packets received, 27% packet loss
round-trip min/avg/max = 348.784/1519.169/2428.172 ms
I tried swapping in my AT&T SIM card and updating the APN in LuCI for the wwan interface to NXTGENPHONE
. It shows me my phone number in the mmcli
output, but it does 'searching'... then after a couple minutes it switches to 'idle':
root@OpenWrt:~# mmcli -m 0
...
Status | unlock retries: sim-pin2 (3)
| state: enabled
| power state: on
| signal quality: 0% (cached)
...
3GPP | imei: 001027009999999
| enabled locks: fixed-dialing
| registration: idle
...and if I swap back to the SixFab SIM and switch the APN back to super
it is doing the same thing now. The signal surely isn't that bad... right? It just gets stuck in a loop of idle/searching/idle/searching
Did you check that it wasn't low power mode? Unlock the bands etc?
@rjocoleman - Can you remind me what the command was to check for low power mode? Also, it looks like for some reason the APN is not updated if I change it in the LuCI interface. I can see that it's updated in the settings in /etc/config/network
:
config interface 'wwan'
option proto 'modemmanager'
option device '/sys/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb2/2-3'
option auth 'none'
option iptype 'ipv4'
option apn 'NXTGENPHONE'
But it seems like the modem itself might not be picking up that change. It looks like I'm not the only one with problems with the APN not updating on the EM7565. I might have to run:
AT+CGDCONT=1,"IP","NXTGENPHONE"
See also: mmcli
stuck in registered
state
(If that's the right command... though it looks like the modem just reset it's USB PID again, so I have to fix that to get TTY access again, lol).
Sorry I'm away from my desk in the middle of nowhere and can't really read everything until Monday!
Low power mode is AT!PCINFO?
AT!PCINFO?
State: Online
LPM voters - Temp:0, Volt:0, User:0, W_DISABLE:0, IMSWITCH:0, BIOS:0, LWM2M:0, OMADM:0, FOTA:0, RFCAL:0
LPM persistence - None
Additionally, as measured in my basement (underground):
AT!GSTATUS?
!GSTATUS:
Current Time: 495 Temperature: 32
Reset Counter: 1 Mode: ONLINE
System mode: LTE PS state: Not attached
LTE band: B66 LTE bw: 15 MHz
LTE Rx chan: 66811 LTE Tx chan: 132347
LTE SCC1 state:NOT ASSIGNED
LTE SCC2 state:NOT ASSIGNED
LTE SCC3 state:NOT ASSIGNED
LTE SCC4 state:NOT ASSIGNED
EMM state: Deregistered Attaching
RRC state: RRC Idle
IMS reg state: No Srv
PCC RxM RSSI: -93 PCC RxM RSRP: -140
PCC RxD RSSI: -78 PCC RxD RSRP: -113
Tx Power: -- TAC: af04 (44804)
RSRQ (dB): -16.3 Cell ID: 0063ac03 (6532099)
SINR (dB): 3.8
Looks like I won't get any connection in the basement! See RSSI/SINR/RSRP/RSRQ guide.
Looks like it's using the right APN for Twilio right now:
# minicom -b 115200 -D /dev/ttyUSB2
AT+COPS? // Find available networks.
+COPS: 0,0,"T-Mobile Twilio",7
AT+CGDCONT? // Check current APN.
+CGDCONT: 1,"IP","super","0.0.0.0",0,0,0,0
AT+CREG? // Check current registration status.
+CREG: 0,5
CREG 0,5
indicates it's registered and roaming ("Registered, roaming. The device is registered on a foreign (national or international) network.") Which is the same as I see with mmcli -m 0
. For some reason it enjoy staying in registered
mode and doesn't seem to want to hold a connection. I'll try moving it to different parts of the house and see if anything helps.
Another thing that's helpful is running ATE
so the command being typed is echoed back to screen (otherwise you have to type blindly in minicom
/screen
).
@geerlingguy mind sharing your interface configs please? I have the same hardware now and I'm not able to get modemmanager to move to state registered
For what it's worth, I got a new Lenovo branded EM7565 yesterday and it had this old firmware on it too. I took my notes of a full upgrade unlock procedure, they're here if they are useful for anyone: https://gist.github.com/rjocoleman/7e2ca10c0e9e371411d1ca1fb21aa8ad I used libqmi and libqmi-utils and not the sierra wireless examples fwdlite, I also covered off removing FCC Auth.
Additionally my waveshare board with the cm4 works well over MBIM with both of my EM7565 cards including PWM fan using openwrt 22.03. I am still toying with using QMI rather than MBIM to see if that has any impact. But this is low priority for me because the use-case is met.
I'd be happy to make a PR for my configs if that would be helpful (there's not much to it tbh)
This issue has been marked 'stale' due to lack of recent activity. If there is no further activity, the issue will be closed in another 30 days. Thank you for your contribution!
Please read this blog post to see the reasons why I mark issues as stale.
Hello there I have EM7565 with same FW SWI9X50C_00.06.02.00 and can't update FW to the lastest FW version
ati
Manufacturer: Sierra Wireless, Incorporated
Model: EM7565-9
Revision: SWI9X50C_00.06.02.00 f50f0a jenkins 2017/08/25 05:33:58
IMEI: 001027009999999
IMEI SV: 1
FSN: XK734688680306
+GCAP: +CGSM
OK
AT!PCINFO?
State: Online
LPM voters - Temp:0, Volt:0, User:0, W_DISABLE:0, IMSWITCH:0, BIOS:0, LWM2M:0, OMADM:0, FOTA:0, RFCAL:0
LPM persistence - None
OK
at!IMPREF?
!IMPREF:
preferred fw version: 00.06.02.00
preferred carrier name:
preferred config name:
current fw version: 00.06.02.00
current carrier name:
current config name:
OK
at!image?
TYPE SLOT STATUS LRU FAILURES UNIQUE_ID BUILD_ID
FW 1 EMPTY 0 0 0
FW 2 EMPTY 0 0 0
FW 3 EMPTY 0 0 0
FW 4 EMPTY 0 0 0
Max FW images: 4
Active FW image is at slot 255
TYPE SLOT STATUS LRU FAILURES UNIQUE_ID BUILD_ID
Max PRI images: 50
OK
Module works fine, but i need the lastest FW, this one pretty outdated (no luck in WIndows with flashing new FW, there was a link to my problem at sierra's forum) I'm not linux user, but i have to try to do same steps as you: Mudule connecned by USB 2.0, but if you have an success, i - don't:
sudo qmi-firmware-update --update -d 1199:90b1 SWI9X50C_01.05.01.00.cwe WI9X50C_01.05.01.00_GENERIC_001.028_000.nvu
loading device information before the update...
setting firmware preference:
firmware version: '01.05.01.00'
config version: '001.028_000'
carrier: 'GENERIC'
rebooting in download mode...
error: error waiting for TTY: waiting for device at '/sys/devices/pci0000:00/0000:00:14.0/usb1/1-9' timed out
Any advices?) Thanks for answer!
This issue is no longer marked for closure.
your vendor id is 1199
and product id 90b1
in my gist https://gist.github.com/rjocoleman/7e2ca10c0e9e371411d1ca1fb21aa8ad where I say 1199 90c3
or 1199:90c3
you want to use 1199 90b1
or 1199:90b1
.
Specifically step 0 keep the same AT!USBPID=9091,9090
as the gist to turn it to the standard vendor/product id combo.
Steps 5 & 7 keep the same 1199:9091
as you are now using the standard product ids.
I've upgraded a bunch of these with the same steps various product ids from early firmware, but they are my notes so maybe I missed a step.
good luck!
Thanks for help, it works
This issue has been marked 'stale' due to lack of recent activity. If there is no further activity, the issue will be closed in another 30 days. Thank you for your contribution!
Please read this blog post to see the reasons why I mark issues as stale.
This issue has been closed due to inactivity. If you feel this is in error, please reopen the issue or file a new issue with the relevant details.
I need to get the following set up and working:
.config
/diff
//etc/config/network
(et all) so I can get a reproducible build in here?