FX30 stuck in reboot loop (less than 30 seconds)

We have a fx30 CAT-1 NA running latest r16 firmware that is stuck in a reboot cycle. It is very hard to diagnose since that we loose usb every 30sec. Even worse, we only have access to it remotely on a arm32 system (cannot use swiflash).

No custom application installed.

We are able to issue AT commands from time to time to it in between reboot and briefly ssh to it.

I am looking for any info on how to prevent it from rebooting so I can figure out what is going on.

Thanks

Are you able to redownload firmware to it by MBPL fw download application?

https://source.sierrawireless.com/resources/airprime/software/mbpl/mbpl-software-latest/

Thank you , I’ll take a look and come back with the result.

This looks very promising but it seems that we fail on the download somehow.

root@xxx:~# ./fwdwl-litearm --fwpath /home/root -s FX30_WP76xx_full_R16.0.2.004-generic-SWI9X07Y_02.37.03.00.cwe -P 2-1.3
Application version: 1.0.2303.0
INFO: QDL Port:
INFO: Device Path: /dev/cdc-wdm1
INFO: FW Path: /home/root
Switching device into download mode ...
Waiting for modem to disconnect from the host ...
Modem disconnected from host.
Waiting for modem to come up in BOOT and HOLD mode ...
QDL port found: /dev/ttyUSB7
BOOT and HOLD Mode. Downloading firmware ...
Downloading: /home/root/FX30_WP76xx_full_R16.0.2.004-generic-SWI9X07Y_02.37.03.00.cwe
^[^[FW download failed: eSDP_FWDWL_ERR_FIREHOSE_STATE_ERR(120)
 [16:01:37.735][7]Received ACK/RAWMODE_TRUE for Program command.  Advance to payload transfer stage.
 [16:01:37.735][7]Current mode: 7, previous max_reads_allowed: 28
 [16:01:37.741][7]Write: /home/root/FX30_WP76xx_full_R16.0.2.004-generic-SWI9X07Y_02.37.03.00.cwe

 [16:01:37.741][7]Actual read block size used: 0 bytes
 [16:01:37.742][7]Write Start
 [16:03:20.957][7]Total bytes sent: 69967306 bytes
 [16:03:21.004][7]Firmware Write Completed, max_reads_allowed reset to 300
 [16:03:21.506][7]read timeout
 [16:03:21.506][7]Current mode: 7, previous max_reads_allowed: 299
 [16:03:21.506][7]prev_mode (7) same as current mode, skip processing.
 [16:03:22.007][7]read timeout
 [16:03:22.007][7]Current mode: 7, previous max_reads_allowed: 298
[[16:03:22.007][7]prev_mode (7) same as current mode, skip processing.
[[16:03:22.508][7]read timeout
[[16:03:22.508][7]Current mode: 7, previous max_reads_allowed: 297
[[16:03:22.509][7]prev_mode (7) same as current mode, skip processing.
[[16:03:23.009][7]read timeout
[[16:03:23.010][7]Current mode: 7, previous max_reads_allowed: 296
[[16:03:23.010][7]prev_mode (7) same as current mode, skip processing.
[[16:03:23.511][7]read timeout
[[16:03:23.511][7]Current mode: 7, previous max_reads_allowed: 295

After a hard reset (cutting power). The modem reboot into the application and does not power cycle.

That is very good news.

Still I’m unsure why the modem is not in a “out of the box” state (ask for password configuration on first login). Might be a separate issue. Feel free to help me on that also ;), I’ll take all the help you can give.

Thanks again. I was about to lose my sanity over all this.

see if this helps:

Sorry my previous post was not clear.

I would have expected that after a firmware “download” that the fx30 be in a “out of the box” state, thus I would have expected that the fx30 ask for password setup etc. Which is not the case here. I failed to find a way to truly “wipe” the fx30 clean so far. I’ll retry the following:

at!entercnd=“A710”
at!rmareset=1

that is not true, after firmware download, it will not ask for password setup if it did not ask before the upgrade.

Ok. Any way to achieve a “clean” that will yield a similar state as “out of the box”, (except the hardware button)?

at!entercnd=“A710”
at!rmareset=1

Does not yield that state.

why do you think it is not clean now?

Not necessarily not “clean” but I would have prefered to be as close as possible to an “out-of-box” state since our application controller does perform “initialization” (with pexpect and all). Any way I can “nuke” the overlayfs?

In any case, thank you again for your help. Having an arm compatible tool for flashing is a big improvement over the situation we were in.

here is a method to erase the userapp partition:

I suggest you making some test with a device locally first