topic Re: RW612 - PM4 deep sleep intermittently draws high current in Wi-Fi® + Bluetooth® + 802.15.4

RW612 - PM4 deep sleep intermittently draws high current

dmarks_ls — Wed, 05 Mar 2025 15:01:26 GMT

We are encountering an issue where one of our products, based on an RW612 in a u-blox IRIS-W10 module, is ostensibly entering deep sleep but in reality is drawing ~60 mA and rapidly draining the battery.

Here is our function that is entering deep sleep:

void PowerManager::EnterPowerDown(uint32_t duration_secs) { auto &board = Board::GetInstance(); debug_.Info(kTopicGeneral, "sleeping for %lu secs (max)", duration_secs); os_self_sleep_ms(500u); auto sleep_ticks = SecsToRtcTicks(duration_secs); PM_SetConstraints(kLowPowerMode, APP_PM_CONSTRAINTS); auto base_priority = os_enter_critical_from_isr(); board.InitPins(); PM_EnablePowerManager(true); PM_EnterLowPower(sleep_ticks); /* Should never get here, PM4 Deep Sleep requires a cold boot. */ PM_EnablePowerManager(false); os_exit_critical_from_isr(base_priority); PM_ReleaseConstraints(kLowPowerMode, APP_PM_CONSTRAINTS); }

kLowPowerMode is defined as PM_LP_STATE_PM4, and APP_PM_CONSTRAINTS is 0. We select our power mode and constraints, enter a critical section, put our GPIO into a known state, enable the Power Management driver, and invoke low power mode. Our board does wake up when a wake signal occurs on GPIO[24], or when one hour has elapsed, and it does immediately restart, as one would expect after entering PM4 Deep Sleep.

Most of the time the system draws <1 mA in this state. But intermittently, it enters this state and draws ~60 mA for the duration of the sleep cycle, which is a maximum of one hour in our application. Needless to say, this destroys our battery life between charges. (The power should be going to <10 uA per the datasheet, but that's a topic for another day.)

To avoid complications with starting and stopping the Wi-Fi driver, I've engineered the system such that when we want to go to sleep, I set a flag in NVRAM, reboot the system by calling __NVIC_SystemReset(), and then enter low-power mode, while leaving the Wi-Fi subsystem untouched. When we wake from sleep, we reboot (because we're coming out of PM4), start Wi-Fi, and upload telemetry to the cloud.

Your "power_manager_test" SDK example was written for baremetal; are there additional precautions that one must take when running FreeRTOS to ensure that entering PM4 will genuinely yield a low-power state? What other conditions could cause a false PM4 state?

Dana M.

Re: RW612 - PM4 deep sleep intermittently draws high current

Ricardo_Zamora — Wed, 05 Mar 2025 18:42:45 GMT

Hello,

Hope you are doing well. What SDK version are you using?

Are you seen this behavior with the SDK example without modifications?

Can we reproduce this behavior with the SDK example? What changes need to be done?

Are you able to see this behavior in our FRDM?

Best Regards,

Ricardo

Re: RW612 - PM4 deep sleep intermittently draws high current

dmarks_ls — Thu, 06 Mar 2025 19:18:46 GMT

What SDK version are you using?

I generated our project using SDK v2.16.1. I have SDK 24.12 (2025-01-15) pulled down but I have not yet attempted to apply it to this project, given how MCUXpresso likes to render projects unusable when adding or upgrading components.

Are you seen this behavior with the SDK example without modifications?

In the very limited testing we did with the SDK example, no, it did not occur.

Can we reproduce this behavior with the SDK example?

Likely not.

What changes need to be done?

Add FreeRTOS, Wi-Fi driver, lwIP networking, and an AWS client stack to the example.

Are you able to see this behavior in our FRDM?

It would take considerable effort to rig up a FRDM board to work the same as our custom board, but it could be done.

Dana M.

Re: RW612 - PM4 deep sleep intermittently draws high current

dmarks_ls — Wed, 19 Mar 2025 16:09:32 GMT

I believe I’ve found the issue. Our system performs a reboot immediately prior to engaging low-power mode. This removes the requirement to implement a graceful shutdown of the Wi-Fi + TCP/IP stack prior to power-down. (My initial attempts at shutting down the Wi-Fi stack through the Wi-Fi API were unreliable, so I switched to the reboot approach.) We use a flag in NVRAM to signal the system not to bring up Wi-Fi but instead immediately configure the wakeup pin for the correct polarity and go into power-down. Our board pulls ~1 mA in deep sleep.

I believe the cause of our excessive current draw is that sometimes when we would reset the main CPU (Cortex-M33), the Wi-Fi CPU/radio would be left in an active state, pulling ~56 mA. Since our sleep/check-in interval is 1 hour, that’s 56 mAh of draw from the battery. I asked NXP specifically about how the CPUs and radios are reset, and that seemed to confirm that __NVIC_SystemReset() only resets the Cortex-M33, leaving the other processors alone. This morning, I put two lines of code into our board startup function:

/* Ensure that the radios are powered off at startup. Thus, if we go * directly into power-down, this should eliminate the possibility that * the radios are still powered and thus pulling current. */ POWER_PowerOffWlan(); POWER_PowerOffBle();

I rebuilt the application and then ran it for ~40 minutes, using an LED flashlight to wake up the board every time it went to sleep. I woke the unit up likely about 50 times during the test, and 50/50 it went into low power, i.e. it did not draw excessive current. Previously, it would take me only a few attempts to get the system into a high-current sleep state. At this point, I consider the issue solved.

In summary… if the Wi-Fi and/or BLE stacks are initialized and running, and the system is reset or watchdogged, it is necessary to call POWER_PowerOffWlan() and/or POWER_PowerOffBle() at startup to ensure that the Wi-Fi and BLE CPUs/radios are powered off. When starting Wi-Fi using the NXP stack, one of the first steps is powering down and then powering up the Wi-Fi processor, so explicitly powering down the radio at startup does not interfere with a later initialization of the Wi-Fi stack.

Dana M.