Stuck in Low Power Mode - Image Preference Mismatch


Thanks @EvetsMostel, yes it’s the “User” field, in this case, which is supposed to mean that you (or a SW application as user) actually requested LPM. As I assume this is not the case :), I suspect this is related to a resolved issue in Release 9, listed in release notes as QTI9X07-1009, with the following description: “In rare cases it has been reported that after entering LPM with AT+CFUN=0 that the module was unable to return online with AT+CFUN=1 despite having no other reason to prevent it. This state is now removed.”

Since we haven’t released a carrier certified Verizon image as part of Release 9, this makes things less convenient. But you can resolve this issue with a short but awkward workaround:
AT!ENTERCND=“A710” // enable level 2 access
AT!CUSTOM=“CFUNPERSISTEN”,01 // Enable Persistent LPM
AT!CUSTOM=“CFUNPERSISTEN”,00 // Assuming you want the customization disabled

Or you can leave the customization enabled, if it’s something you’d rather keep enabled. Let me know if that doesn’t get you out of your LPM state.


Yep, that did it. Thanks!


Does this mean that AT+CFUN is removed in release 10, or the LPM state is no longer available, or ?



@EvetsMostel, CFUN and Persistent LPM are (and will be) still supported. The problem in Release 8 and earlier was that if the module was in Persistent LPM, and then the CFUNPERSISTEN customization was disabled, there was no mechanism to get out of persistent LPM. As of Release 9, when CFUNPERSISTEN is disabled, the module will always come out of LPM (persistent or not) when requested (via CFUN or other APIs). This was a logic error in implementation.

But I’ve been looking into this, and I think there is another underlying issue here. The customization itself is getting wiped out on the image update, meaning that if you want CFUNPERSISTEN enabled (0x01), you need to re-enable it after a FW update. I opened an internal ticket for this and it should be resolved in Release 11. In the meantime, if you need to enable CFUNPERSISTEN, the following will make the customization persistent across updates:
AT!ENTERCND=“A710” (or your level 2 password, if you’ve changed it)

If you prefer that customization disabled, which is default, no need for any action.



Thanks @rkirk for the explanation!


This seems to mirror my issue with a new WP7608 (mangOH red). But the given solution doesn’t seem to be helping much.

Setting AT!CUSTOM="CFUNPERSISTEN",01 is allowing me to issue AT+CFUN=1 without any error, but the modem is switching off after 2-3 secs and its back to 0.
Setting AT!CUSTOM="CFUNPERSISTEN",00 just keeps giving me: CME ERROR: operation not supported

Whatever I do, I am getting the below

State: Low Power Mode
LPM voters - Temp:0, Volt:0, User:1, W_DISABLE:0, IMSWITCH:0, BIOS:0, LWM2M:0, OMADM:0, FOTA:0
LPM persistence - User:1

As this is a WP7608, there doesn’t seem to be any Release 9 firmware for it (using Generic). I just don’t need this LPM at all, just want to get rid/avoid it completely. I am missing something obvious to stop it from going back to LPM automatically? Tried reflashing firmware and userdata but always boots into LPM after.


Hi @mallets, the Release 9 firmware page is relevant for WP7608 too:

Are you saying the response to “AT!CUSTOM=“CFUNPERSISTEN”,00” is a “CME ERROR:…”? Or are you getting that error when you call AT+CFUN later?

One case where the “User” flag would be set is if a Legato app is requesting LPM. Do you have any custom apps that could be doing this? I agree this is a little different than the previous scenarios. A log of the event using “logread -f &” or similar, starting just before you issue AT+CFUN=1, might indicate why LPM is being triggered immediately after.



The release notes says there is no “approved” release for WP7608 and WP7609. (Search WP7608/WP7608-1 Approved, within the release notes). There is no error during installation but it doesn’t seem to work? Even Legato DS seems to default to release 8 for WP7608.

Getting that error when I call AT+CFUN later.

logread -f output:

Jan 6 00:20:01 swi-mdm9x28 user.warn kernel: [ 481.601399] PSM: Modem oprt mode - 0
Jan 6 00:20:01 swi-mdm9x28 user.warn kernel: [ 481.601399] PSM: Modem oprt mode - 0
Jan 6 00:20:01 swi-mdm9x28 user.warn Legato: -WRN- | posDaemon[917]/le_pa_gnss T=unknown | pa_gnss_qmi.c PositionHandler() 1359 | Bad position indication
Jan 6 00:20:01 swi-mdm9x28 user.warn kernel: [ 481.779591] PSM: Modem oprt mode - 1
Jan 6 00:20:01 swi-mdm9x28 user.warn Legato: -WRN- | posDaemon[917]/le_pa_gnss T=unknown | pa_gnss_qmi.c PositionHandler() 1359 | Bad position indication
Jan 6 00:20:01 swi-mdm9x28 user.warn kernel: [ 481.779591] PSM: Modem oprt mode - 1


@mallets, thanks - good point. Sorry for the confusion - the WP7608 is actually GCF certified and Release 9 is valid:

The upgrade should work - what version are you upgrading from? Can you run a few diagnostic commands after the attempt, to try to narrow it down?

Regarding the log, unfortunately it just shows that state changing, so it’s not much help so far. Let’s see if we can get your device updated first though.


Yeah, seems like you are correct. It did update fine (the original firmware was something 0X.14.0X afaik). Didn’t solve the main issue, but seems like there is no error now with +CFUN=1, with persist on and off (the radio switching off after a few seconds is still there). +CFUN on first run, radio switches off immediately within 0.2secs. Run it immediately after, will stay on for 2-3secs. AT!PCINFO? always shows LPM persistence - User:1 as the cause. No apps, other than devMode, installed. Did a factory reset from developer studio after upgrade.

Results of all the requested commands, with release 9 firmware:

Manufacturer: Sierra Wireless, Incorporated
Model: WP7608
Revision: SWI9X07Y_02.16.02.00 000000 jenkins 2018/04/19 19:59:02
FSN: XG814285121610

FW 1 GOOD 3 0 0 ??
FW 2 GOOD 4 0 0 002.032_000
FW 3 EMPTY 0 0 0
Max FW images: 3
Active FW image is at slot 2

PRI FF GOOD 0 0 0 002.032_000
Max PRI images: 50

PRI Part Number: 9907762
Revision: 001.002
Customer: Qualified

Carrier PRI: 9999999_9907152_SWI9X07Y_02.16.02.00_00_GENERIC_002.032_000

preferred fw version:
preferred carrier name: GENERIC
preferred config name: GENERIC_002.032_000
current fw version:
current carrier name: GENERIC
current config name: GENERIC_002.032_000

Thank you


@mallets, thanks, everything looks fine there. The Legato log doesn’t show an issue, and I still don’t see a reason that the device has entered LPM, other than “User”, which means some client has requested LPM, and that could be Legato app or on a host platform via USB. Legato logs show the transition event, but no request, though it might be hidden by the debug level. Could you first try narrowing down the software interfaces to the modem, to try to locate this client? Disabling the USB driver (eg. disable the Network interface and Modem interface in Windows) would prevent a Windows client from requesting LPM. You could similarly try disabling apps in Legato ("app stop " from console). I’ve not seen this behaviour before, so sorry I don’t have a better idea yet.



Thanks for the reply. Got it working, unexpectedly. Left it running for a more than 24 hours and fiddled with getting other stuff working (Ethernet IoT card, wifi etc). The modem (WWAN) led lit right around the time the Wifi AP was successfully configured. Don’t know exactly what part of the software configuration enabled it, but all I remember was that it happened while following this guide: (maybe while setting up the UART??). Maybe anyone with more technical knowledge about this can figure out what it was… or if it was completely unrelated.

Tried to recreate the problem again by re-flashing the firmware and clearing the user data partition, but the modem has been working as it should since then (no more user LPM switching automatically during boot). Thank you for the replies though, learned a lot more about debugging this module.


So this was it! I didn’t disable the USB driver, but turning off flight mode was the solution. The Windows driver is automatically shutting down the modem whenever I put my dev Laptop into Flight mode (which is almost always). The module “magically” switched on during wifi config part, because I disabled the flight mode to test the WiFi AP. Can’t believe this was the issue, didn’t expect the flight mode of my laptop to affect the module too. :expressionless: Would’ve been more obvious if the logs showed the exact reason/initiator for the LPM.

Hope this helps anyone else, though I am guessing the chances of anyone encountering this scenario is very rare.