USB suspended Idle mode not working in WP series

IoT Modules WP Series
1

Hi,

I am trying to put the WP module (tried WP7502, WP7504, WP7603, WP7607, WP8548, all not working) into idle mode with USB suspended (so that, power consumption can come to a few mA, product spec of WP series claim it can down to 4mA or so with USB suspended). But it doesn’t work on all the WP modules I tested.

I do have success on all HL modules (HL7549, HL7648, HL7688, HL7692, etc) and the current consmption go dead low and keep stable.

So I presume my test set up is ok. (Actually, nothing but just have the USB connected to my Ubunto PC and necessary and correct power supply goes to the module, seriesly conntact to an amp-meter.

So any one can help and tell what is missed and differences between WP and HL? Is the AP inside the WP doing something unknown to me (just use stocked WP module without any custom Legato App downloaded there)?

My Ubunto command lines to put the PC’s USB to suspend:

~$ udevadm info -q path -n /dev/ttyUSB0
(to check which USB port the module is attached, below assume 1-1)

~$ echo “0” | sudo tee /sys/bus/usb/devices/1-1/power/autosuspend
(put USB bus to auto suspend)

-$ echo “auto” | sudo tee /sys/bus/usb/devices/1-1/power/level
(activate USB auto suspend, wait for a few seconds and USB will go suspend)

-$cat /sys/bus/usb/devices/1-1/power/runtime_status
(check the USB is really go suspend, if so, with echo back with “suspended”, which it does)

Thanks.

2

@bwong23hk,

So if you unplug the USB from your system does the current drop to the low level you are expecting?

Regards

Matt

3

Hi,

USB disconnection isn’t exactly equals to USB suspend.
So disconnecting the USB (and causing USB bus not in a suspended state), doesn’t reflect anything in above question of current consumption.

Besides, I use the USB’s power to derive the VBAT to the module, so I cannot disconnect it.

Thanks.

4

@bwong23hk,

So you are running this on a mangOH board? The WP generically is not powered by the USB, only by the external circuitry feeding the Vbatt lines which might come from the USB on the given board. My suggestion is to disconnect USB and look at the power consumption to make sure it is the USB and not something else, the WP is an infinitely more complex unit than the HL.

Regards

Matt

5

Hi,

I am not using the MangOH Red (which I have one). I my simple test set up as in attached picture.

WP%20Idle%20current%20test%20setup
WP Idle current test setup.jpg1440×1080 106 KB

This is the most instinct setup resembling real case embedded situation. No other fancy things in the MangOH Red, just the module with USB connected to the host (PC). In real case the host USB might not be able to be detached from the module, nor the power could be supplied elsewhere from the USB (imaging, if I am making a USB dongle type application).

Anyway, I did try the MangOH Red with the following results:

  • With single USB (CN304) supplying the power and Power Sel jumper CN804 on the CN801 side), current over the CN304 is about 180mA (and jumping) when USB is in active state, bouncing between 120mA to 140mA when USB put in suspended state.

  • With console USB (CN305) supplying the power and Power Sel jumper CN804 on the other side, the current flow through the CN305 is prettey the same as above (USB CN304 in active or suspended state)
    Unplugging the CN304 doesn’t change the current as like CN304 in suspended state.

The argument point are:

  1. There are other electronic circuitry in the MangOH Red which consume powers, so whether the whole board is responding and compiling the USB suspend requirement is unknown.

  2. The USB suspend doesn’t by definition equal to unplugging the USB. In USB suspend the D+ and D- must be still supplied by 1.5K pull up resister (which should be done inside the module circuitry).
    There is explicit specification of idle current max. 4mA for USB suspended idle mode, within WP or HL’s product specifications. But there is no specification with USB unplugged (Hi-Z at all USB pins).

6

@bwong23hk,

My point as that by making the USB completely inactive then you can eliminate USB from the equation as to whether it is actually this that is stopping the unit from going to sleep.

Regards

Matt

7

Dear Matt,

I understand your intention for checking but I still hold my point that:

USB suspension is a standard USB feature that all low power USB devices (e.g. USB mouse, USB keyboard, etc) must comply. The Sierra module (WP or HL) is supposed to work as a low power USB device so it should comply to the USB suspension mechanism as well. That is USB could be leave unplugged under USB suspension mode.

The product specification of WP (and HL) actually state as expected that the module can be a low power USB device. The module only goes to low power (4mA) with USB suspended and, by USB definition, NOT when USB is unplugged / Hi-Z. And real world testing of many (if not all) HL series members exhibits the exact expected behavior. Only the WP doesn’t work that way.

I have diffuclty to perform your intended test as my PCB has the VBAT and VBUS tied together within the inner layer of the PCB. So it will take a huge effort to separate the two, in the mind that (in theory) it shouldn’t be the root cause.

Moreover, the WP behaves strangely (in my hardware setup) that sometimes (normally in the morning of my work), it might go down to very low (tends to a few mA) for a good period of time, occasionally bounce up. But in the late afternoon usually the current will bounce vigorously.

Many WP modules in same and different SKU are tested so it won’t be a particular module’s failure.

8

WP Series are Smart modules, meaning there is Legato application environment running in the module. Therefore WP Series could behave differently from HL Series in terms of USB-SS.

The module will get into USB-SS mode once the specific requirements are met:

If the module is in IDLE or ONLINE mode:

  • module is registered on the network
  • no active data or voice session
  • USB disconnected or in Selective Suspend mode (SS mode must be supported by the Host CPU USB driver, otherwise SS mode will not work)
  • Legato dev mode disabled
  • wake_lock file has no active locks (cat /sys/power/wake_lock)
  • no GPIO’s configured to wake up the source (see “Wakeup Interrupt (USB-SS Mode)” chapter of Product Technical Specification document)

If the module is in Low Power Mode (you can check the status with at!gstatus? command):

  • USB disconnected or in Selective Suspend mode (SS mode must be supported by the Host CPU USB driver, otherwise SS mode will not work)
  • Legato dev mode disabled
  • wake_lock file has no active locks (cat /sys/power/wake_lock)
  • no GPIO’s configured to wake up the source (see “Wakeup Interrupt (USB-SS Mode)” chapter of Product Technical Specification document)

If you only remove USB, but do not assure other listed points, the module will not enter USB-SS mode…

I would suggest to contact your Sierra Wireless local support team for the assistance, since this is not a trivial topic to test…

Hope this helps…

Regards,
Vitaly

9

Hi Vitaly,

Your comments are with much senses. Sierra local support actually couldn’t give too much useful hints to this case. That’s why I turned to this Forum and see if some experienced user could enlighten this mist.

As I mentioned in my first post, I am using the stock WP directly purchased from Sierra, and I am not touching anything related to the Legato. My suspicion is also lean towards that something in the AP / Legato hinder the module going to USB suspend mode.

I did just run a check on your mentioned points (I just need module in IDLE mode, 4mA):

  • Host (actually a Ubunto PC) definitely has standard USB driver that could go to USB-SS, see those command lines I posted before.
  • No data / voice session, actually I tried to suspend the USB once the WP finished network registration, and not connecting to anything
  • Legato devMode app even not installed
  • I even tried once, killed and deleted all Legato apps (in user app space and Legato framework space) in the module via the Sierra Development Studio
  • /sys/power/wake_lock is blank
  • I did made sure those wake up sources are inactive, GPIO actually are all leave open, and proper AT+WWAKE. AT+WAKESET, AT!POWERSET, etc disable all wake up interrupts.

However, still, the behavior of the module is not as it should be. I still wonder is there any unseen app / services in the AP kernel being running that keep waking up the USB?

Rgds.

10

I probably ask the obvious here…have you connected main antenna and confirmed module registration status? The setup picture does not present antennas connected…
What is the module’s response on at!gstatus? command when you expect to see USB-SS mode active? What current consumption do you measure? (is it 90 mA)

Regards,
Vitaly

11

Yes I did connect antenna and insert proper SIM during testing (not shown in my picture), and confirmed network registration in AT!GSTATUS? or AT+CREG? sort of things…
I could even send out SMS to my mobile phone number using Minicom and AT commands.

But in fact, the power consumption behavior is not affected by the network registration status, during different tests on HL and WP. For HL, USB-SS idle is always good. In WP, strange things keep happening.

When WP is not going to USB-SS idle (4mA), the current consumption bounce mostly between 40mA and up to 120mA occasionally.

12

Hi,

I just test with MangoGreen dev-kit / WP7603 and WP7607 / Win10 USB 2.0 host controller / EHCI HS Electrical Test Tool (USBHSET) / USB cable is connected:

No SIM inserted (Hardware issue with my dev-kit) and set “cm radio off”

when I send USB SUSPEND command, the current is around 50mA,
when I send USB RESUME command, the current is around 135mA.

13

@bwong23hk,

Check the following steps and see if this helps you achieve USB_SS current.
The below examples are using WP7504.

Identify the device number for your device:
Ex:

Bus: 02
Port: 1:
Child Port: 5

$ lsusb -t
/: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 5000M
/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 480M

/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M
__ l__ Port 1: Dev 2, If 0, Class=hub, Driver=hub/8p, 480M
____ l__ Port 4: Dev 3, If 0, Class=HID, Driver=usbhid, 1.5M
____ l__ Port 5: Dev 76, If 19, Class=comm., Driver=cdc_ether, 480M
____ l__ Port 5: Dev 76, If 20, Class=data, Driver=cdc_ether, 480M
____ l__ Port 5: Dev 76, If 0, Class=vend., Driver=GobiSerial, 480M
____ l__ Port 5: Dev 76, If 2, Class=vend., Driver=GobiSerial, 480M
____ l__ Port 5: Dev 76, If 3, Class=vend., Driver=GobiSerial, 480M
____ l__ Port 5: Dev 76, If 4, Class=vend., Driver=GobiSerial, 480M
____ l__ Port 5: Dev 76, If 8, Class=vend., Driver=GobiNet, 480M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M
l Port 1: Dev 2, If 0, Class=hub, Driver=hub/6p, 480M

Bus: 2
Port: 1
Child Port: 5

DEV_NUM: - = 2-1
CHILD_DEV_NUM: <DEV_NUM>.<child_port> = 2-1.5
Kernel poweroff control pre-requisites
(depending on your kernel version not all of these files will exist):

$ cd /sys/bus/usb/devices/DEV_NUM
$ sudo sh -c “echo 0 > power/pm_qos_no_power_off”
$ sudo sh -c “echo 0 > peer/power/pm_qos_no_power_off”
$ sudo sh -c “echo auto > power/control”
$ sudo sh -c “echo auto > power/level”
$ sudo sh -c “echo 0 > power/autosuspend”
$ sudo sh -c “echo 0 > power/autosuspend_delay_ms”
$ sudo sh -c “echo auto > CHILD_DEV_NUM/power/control” //<---- This is likely the setting you were missing
$ sudo sh -c “echo 1 > CHILD_DEV_NUM/power/persist”

When complete --if no other blocking condition exists, the module current consumption should drop from “normal” Idle current to USB-SS current specified in the PTS. Note: linux may reset sysfs values with port re-enumeration (i.e., image switch, modem reboot, or power cycle).

14

Hi Ben

Let us check it step by step.

  1. what is the !custom setting? Please show them all(enabled in your module).
  2. make sure “Allow the computer to turn off this device to save power” in ALL port.
  3. disable network driver “Sierra Wireless Mobile Broadband Network Adapter”
  4. test again with attached network.

Wish to hear your voice soon.

15

Hi, let me enter into this thread with the very similar issue.

We are testing WP7702 with Release 9.1 firmware.
No SIM. No MangOH additional hardware and software.

With the wake lock (/sys/power/wake_lock) and USB disconected. GNSS off.
We are able to reach power consumption around 10 mA.

Without the wake lock, when the module attempts to enter USB-SS
the power consumption increases to about 50 mA.

The serial console log displays “freezing” messages:

[ 300.532183] Freezing of tasks aborted after 0.108 seconds
[ 300.561953] Freezing of tasks aborted after 0.006 seconds
[ 300.585047] Freezing of tasks aborted after 0.006 seconds
[ 300.752433] Freezing of tasks aborted after 0.140 seconds
[ 301.531858] Freezing of tasks aborted after 0.751 seconds
[ 301.587555] Freezing of tasks aborted after 0.017 seconds
etc.

dmesg

118.740401] PM: Wakeup pending, aborting suspend
[ 118.740535] active wakeup source: [timerfd]
[ 118.741036]
[ 118.741063] Freezing of tasks aborted after 0.094 seconds
[ 118.745439] Restarting kernel threads … done.
[ 118.746743] Restarting tasks … done.
[ 118.755789] sierra_pm_resume
[ 118.756139] sierra_pm_resume, sleep time = 0
[ 118.756175] Abort: Pending Wakeup Sources: [timerfd]

Are the “freezing … aborted” messages sign of normal behaviour?

Why power consumption significantly increases instead of decreases?

Is the installed SIM necessary for successful USB-SS in “Airplane Mode”?

We are not able to reach the <2mA Idle USB-SS power consumption.

16

Hello,
I must confirm similar behaviour previously described by mrjoso, even with functional SIM card.

17

Thank you mirekther for validation.
Is there any way to report this serious issue to Sierra Wireless?

18

Hello,

I posted some information back on October, 30 2018. Please review the earlier post and note some additional requirements for the module to enter USB-SS mode:

All applications must be waiting on events (e.g., not actively executing code)

No kernel wake locks set
Check with command: # cat /sys/kernel/debug/wakeup_sources |sed -e s/"^ "/"unnamed"/ | awk ‘{print $6 "\t" $1}’ | grep -v "^0" | sort -n

Suspend will be blocked if any wake-up timers are set to trigger within 2 seconds, so all user application wake-up timer intervals must be sufficiently large to allow suspend to occur
Check running timers with command: # cat /proc/timer_list
clock 1 lists the CLOCK_REALTIME & CLOCK_REALTIME_ALARM clocks
clock 2 lists the CLOCK_BOOTIME & CLOCK_BO
OTTIME_ALARM
The ALARM clocks are the wake-up timers.

To debug suspend issues, you can redirect the kernel log read to a file, for example: # logread -f > suspend.log &

You can then disconnect USB, wait for device to enter suspend, then re-connect USB to wake back up and check the log with #cat suspend.log. You can see in log if the device actually entered USB-SS mode, and if not, what part of the system prevented it from being suspended.

If the module is entering suspend, then it is in the lowest current mode. If the product’s current consumption is still higher than expected, then you should verify that GPIOs are not being driven and look at any external sensors or chips to ensure they are powered-off or in sleep/suspend mode.

To summarize: the USB-SS mode was verified to be properly operational with WP Series of modules. If you still experience the issues, it would be recommended to contact your distributor’s technical support team, or Sierra Wireless support team for the direct accounts.

Regards,
Vitaly

19

Hi Vitaly,
Thank you for valuable information. We are following your instructions.
Can you, please, confirm if fresh installed FW without any additional apps should work correctly with USB-SS mode?
Or should we take care about system services delivered with FW?

I am asking because we cannot reach 1.8 mA consumption as described at USB-SS mode even if using “clean” newly installed system without any applications installed.
(we are working on WP7702, FW Release 9.1)

Thanks,
Best regards.
Mirek

20

Hi Mirek,

There are some apps running on the module by default, so you might need to stop them.
You would also need to to check that wake_lock file has no active locks (cat /sys/power/wake_lock)
If you still can’t achieve documented current consumption values, you should closely look at your board electrical design to verify that GPIOs are not being driven and look at any external sensors or chips to ensure they are powered-off or in sleep/suspend mode…

Regards,
Vitaly