RC7611 bricked during upgrade need recovery method for arm/aarch64

IoT Modules RC76
1

Hi,

I have an RC7611 module deployed on an ARM device that bricked mid-upgrade using the qmi-firmware-upgrade tool.

Right now when booted normally (TP1 low) - the module just bootloops about 1-2secs of coming up.
Each time it fails around here:

ModemManager[1949]: [/dev/cdc-wdm0] Checking version info (25 retries)...
[   98.108201] usb 1-1: USB disconnect, device number 6
[   98.115479] qcserial_1 ttyUSB0: Qualcomm USB modem converter now disconnected from ttyUSB0
[   98.124472] qcserial 1-1:1.0: device disconnected
[   98.128973] qcserial_1 ttyUSB1: usb_wwan_open: submit read urb 0 failed: -19
[   98.136679] qcserial_1 ttyUSB1: usb_wwan_open: submit read urb 1 failed: -19
[   98.143771] qcserial_1 ttyUSB1: usb_wwan_open: submit read urb 2 failed: -19
[   98.150919] qcserial_1 ttyUSB1: usb_wwan_open: submit read urb 3 failed: -19
[   98.160455] qcserial_1 ttyUSB1: Qualcomm USB modem converter now disconnected from ttyUSB1
ModemManager[1949]: <info>  [base-manager] port [   98.169497] qcserial 1-1:1.2: device disconnected
ttyUSB0 released by device '/sys[   98.179696] qcserial_1 ttyUSB2: Qualcomm USB modem converter now disconnected from ttyUSB2

I managed to get the 3 /dev/ttyUSB0-2 ports and I can briefly access the AT port and get the following info. After a lot of retries, I was able to get the following out of the module:

 ati
Manufacturer: Sierra Wireless, Incorporated
Model: RC7611
Revision: SWI9X07H_00.08.20.00 d73df7 jenkins 2021/10/14 00:48:45
IMEI: 352138110582626
IMEI SV: 18
FSN: 6M1474352210B0
+GCAP: +CGSM

OK

AT!BCFWUPDATESTATUS

!BCFWUPDATESTATUS: UNKNOWN

OK

AT!ERR

MODEM                     APPS
00   01 seccrypt 00208
01   01 rfuser   00192
02   01 gpstask  04166
03   01 rfant    01351
04   01 bshw_gpi 00185
05   01 gsnvif   00858
06   02 sio      00502
07   01 sio      00720

OK

AT!GCDUMP

No crash data available

OK

AT!IMAGE?
ModemManager[1922]: <warn>  [ttyUSB0/probe] failed to parse QCDM version info command result: -7
ModemManager[1922]: <warn>  [ttyUSB0/probe] failed to parse QCDM version info command result: -7

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
Max FW images: 1
Active FW image is at slot 255

TYPE SLOT STATUS LRU FAILURES UNIQUE_ID   BUILD_ID
PRI  FF   GOOD   0   0 0      001.075_000 00.08.20.00_ATT
PRI  FF   GOOD   0   0 0      001.046_000 00.03.03.00_GENERIC
PRI  FF   GOOD   0   0 0      000.027_000 00.03.03.00_SIERRA
Max PRI images: 50

OK

I’ve attempted to the following also:

AT!RMAREST=1 - don’t work (ERROR, AT!ENTERCND=… also ERROR, not enough time)
AT!BOOTHOLD=1 - don’t work, continues to bootloop

AT!WFWUPD… - not sure what file I would be flashing. I’m not sure what Documentation goes with this command. I can xmodem stuff but I need some more info.

I am able to assert TP1 on the module to enter bootloader mode and see the single serial port over USB (I’m guessing this is the DM Port).

Based on reading various posts, I came across this page: https://source.sierrawireless.com/resources/legato/wpxxxxrecoveryprocedure/#sthash.KFRjLFjm.dpbs

which seems to provide the tools on x86 machines to recovery the module once you can boot it into bootloader mode.

Problem is, my module is deployed on an ARM(aarch64) device, and I don’t have an easy way to get the module to talk to the PC.

Is there a arm/aarch64 build of the swiflash tool that I can run on our ARM processor to do this recovery? Is that even the right tool? I also see something about swicve referenced in other threads.

I also can have access to the real UART port if there’s another way to reprogram the module by that path.

Any information would be helpful.

Thanks in advance.

Ben

2

Hi @Ben.Hsu,

As far as I find out on the source page, there is no swiflash tool for your RC7611. I see your RC7611 is still under warranty.
In case the port is not received, please make an RMA request (Return Merchandise Authorization).

Thanks,

3

Hi @jerdung ,

Thank you for the reply.

So is there any tool can we use after setting TP1 to program the RC7611? Even on MS-Windows?

We’ve also tried using qmi-firmware-update tool but it did not seem to like it…

Steps

  1. Disabled ModemManager/NetworkManager, inhibit them from touching module.
  2. Powered off the modem
  3. Set TP1 for bootloader mode
  4. Power on the modem
  5. wait for modem to come up (we have one ttyUSB port)
  6. Use qmi-firmware-update -t /dev/ttyUSB0 --update-download /mnt/sdcard/RC76xx_Release9_ATT_7611.spk

Here’s the verbose output:

[10 Oct 2022, 10:42:23] [Debug] [qfu-qdl-device] setting terminal in raw mode...
[10 Oct 2022, 10:42:23] [Debug] [qfu,dload-message] sent sdp:
[10 Oct 2022, 10:42:23] [Debug] [qfu-qdl-device] >> 70:00:00 [3, unframed]
[10 Oct 2022, 10:42:23] [Debug] [qfu-qdl-device] >> 7E:70:00:00:14:46:7E [7]
[10 Oct 2022, 10:42:23] [Debug] [qfu-qdl-device] << 01:00:00:00:30:00:00:00:02:00:00:00:01:00:00:00:00:04:00:00:02:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00 [48]
[10 Oct 2022, 10:42:23] [Debug] [qfu-updater] qdl device creation failed: HDLC trailing control character not found
error: unsupported download protocol

Is there nothing we can use to unbrick the device? I’m afraid that if our customers pulls battery during operation we might end up with a camera that has this same issue. We can work on UI and other User Notifications to not do that. But is there any way to prevent devices from having to come back to RMA?

Thanks,

Ben