当社の製品の1つ、つまりu-blox IRIS-W10モジュールに搭載されたRW612をベースとしている製品が、表向きはディープスリープ状態に入っていますが、実際には~60mAを消費し、バッテリーを急速に消耗しているという問題に直面しています。
これが深い眠りに入ろうとしている私たちの関数です。
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 は PM_LP_STATE_PM4 として定義され、APP_PM_CONSTRAINTS は 0 です。 電源モードと制約を選択し、クリティカル セクションに入り、GPIO を既知の状態にし、電源管理ドライバーを有効にして、低電力モードを呼び出します。当社のボードは、GPIO[24]でウェイク信号が発生したとき、または1時間が経過したときにウェイクアップし、PM4 Deep Sleepに入った後に予想されるように、すぐに再起動します。
ほとんどの場合、この状態ではシステムは <1mA を消費します。しかし、断続的にこの状態になり、スリープサイクル(このアプリケーションでは最大1時間)の期間中、~60mAを消費します。言うまでもなく、これは充電間のバッテリー寿命を破壊します。(電力はデータシートによると<10uAになるはずですが、それは別の日のトピックです。
Wi-Fi ドライバーの起動と停止が複雑になるのを避けるために、スリープ状態になりたいときに NVRAM にフラグを設定し、 __NVIC_SystemReset() を呼び出してシステムを再起動し、Wi-Fi サブシステムはそのままにして低電力モードに入るようにシステムを設計しました。スリープから目覚めると、再起動し(PM4から抜け出すため)、Wi-Fiを開始し、テレメトリをクラウドにアップロードします。
あなたの "power_manager_test" SDK の例は baremetal 用に書かれました。FreeRTOS を実行するときに、PM4 に入ると本当に低電力状態になることを確認するために取るべき追加の予防措置はありますか?他にどのような条件が誤ったPM4状態を引き起こす可能性がありますか?
ダナ・M
問題を見つけたと思います。当社のシステムは、低電力モードになる直前に再起動を実行します。これにより、電源切断前にWi-Fi + TCP/IPスタックのグレースフルシャットダウンを実装する必要がなくなります。(Wi-Fi API を使用して Wi-Fi スタックをシャットダウンする最初の試みは信頼性が低かったため、再起動のアプローチに切り替えました。NVRAMのフラグを使用して、Wi-Fiを起動せず、ウェイクアップピンを正しい極性にすぐに構成して電源を切るようにシステムに信号を送ります。当社のボードは、ディープスリープ時に~1mAを消費します。
過剰な電流引き込みの原因は、メインCPU(Cortex-M33)をリセットすると、Wi-Fi CPU/無線がアクティブ状態のままになり、~56mAが消費されることがあるからだと思います。睡眠/チェックインの間隔は1時間なので、バッテリーからの消費電力は56mAhです。CPUと無線がどのようにリセットされるかについてNXPに具体的に尋ねたところ、__NVIC_SystemReset()はCortex-M33のみをリセットし、他のプロセッサはそのままにしておくことが確認されたようです。今朝、私はボードのスタートアップ関数に 2 行のコードを入れました。
/* 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();アプリケーションを再構築し、LED 懐中電灯を使用してボードがスリープ状態になるたびにウェイクアップするように、~40 分間実行しました。テスト中にユニットを約50回起こしましたが、50/50で低電力になった、つまり過度の電流を消費しませんでした。以前は、システムを高電流のスリープ状態にするのに数回の試行しか必要としませんでした。この時点で、問題は解決したと考えています。
まとめると...Wi-Fi スタックや BLE スタックが初期化されて実行されており、システムがリセットまたはウォッチドッグされている場合は、起動時に POWER_PowerOffWlan() や POWER_PowerOffBle() を呼び出して、Wi-Fi と BLE の CPU/ラジオの電源がオフになっていることを確認する必要があります。NXPスタックを使用してWi-Fiを開始する場合、最初のステップの1つはWi-Fiプロセッサの電源をオフにしてから電源を入れることです。したがって、起動時にラジオの電源を明示的にオフにしても、後でWi-Fiスタックを初期化するのを妨げません。
ダナ・M
どのSDKバージョンを使用していますか?
SDK v2.16.1を使用してプロジェクトを生成しました。SDK 24.12(2025-01-15)をプルダウンしましたが、MCUXpressoがコンポーネントを追加またはアップグレードするときにプロジェクトを使用できなくするのが好きなため、このプロジェクトにはまだ適用しようとしていません。
この動作は、変更なしのSDKの例で見られますか?
SDKの例で行った非常に限定的なテストでは、いいえ、発生しませんでした。
この動作を SDK の例で再現できますか?
おそらくそうではないでしょう。
どのような変更を行う必要がありますか?
FreeRTOS、Wi-Fi ドライバー、lwIP ネットワーク、AWS クライアントスタックを例に追加します。
この動作はFRDMで確認できますか?
FRDMボードをカスタムボードと同じように機能させるにはかなりの労力がかかりますが、それは可能です。
ダナ・M