- Forums
- Product Forums
- General Purpose MicrocontrollersGeneral Purpose Microcontrollers
- i.MX Forumsi.MX Forums
- QorIQ Processing PlatformsQorIQ Processing Platforms
- Identification and SecurityIdentification and Security
- Power ManagementPower Management
- Wireless ConnectivityWireless Connectivity
- RFID / NFCRFID / NFC
- Advanced AnalogAdvanced Analog
- Neural Processing UnitsNeural Processing Units
- MCX Microcontrollers
- S32G
- S32K
- S32V
- MPC5xxx
- Other NXP Products
- S12 / MagniV Microcontrollers
- Powertrain and Electrification Analog Drivers
- Sensors
- Vybrid Processors
- Digital Signal Controllers
- 8-bit Microcontrollers
- ColdFire/68K Microcontrollers and Processors
- PowerQUICC Processors
- OSBDM and TBDML
- S32M
- S32Z/E
-
- Solution Forums
- Software Forums
- MCUXpresso Software and ToolsMCUXpresso Software and Tools
- CodeWarriorCodeWarrior
- MQX Software SolutionsMQX Software Solutions
- Model-Based Design Toolbox (MBDT)Model-Based Design Toolbox (MBDT)
- FreeMASTER
- eIQ Machine Learning Software
- Embedded Software and Tools Clinic
- S32 SDK
- S32 Design Studio
- GUI Guider
- Zephyr Project
- Voice Technology
- Application Software Packs
- Secure Provisioning SDK (SPSDK)
- Processor Expert Software
- Generative AI & LLMs
-
- Topics
- Mobile Robotics - Drones and RoversMobile Robotics - Drones and Rovers
- NXP Training ContentNXP Training Content
- University ProgramsUniversity Programs
- Rapid IoT
- NXP Designs
- SafeAssure-Community
- OSS Security & Maintenance
- Using Our Community
-
- Cloud Lab Forums
-
- Knowledge Bases
- ARM Microcontrollers
- i.MX Processors
- Identification and Security
- Model-Based Design Toolbox (MBDT)
- QorIQ Processing Platforms
- S32 Automotive Processing Platform
- Wireless Connectivity
- CodeWarrior
- MCUXpresso Suite of Software and Tools
- MQX Software Solutions
- RFID / NFC
- Advanced Analog
- Neural Processing Units
-
- NXP Tech Blogs
- Home
- :
- Translated Content
- :
- Multi Source Translation Content
- :
- 2407900_ja-JP
2407900_ja-JP
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
2407900_ja-JP
2407900_ja-JP
こんにちは、
KW47リファレンスマニュアルを読んでいるのですが、WDOGの低消費電力モードとシステムの電源モードの関係について混乱しています。
WDOGの章では、制御およびステータスレジスタには次のビットが含まれています。
- 待って：
「チップが待機モードのときにWDOGが動作できるようにします。」
- 停止：
「チップが停止モードのときにWDOGが動作できるようにします。」
WDOGの章には、次のようにも記載されています。
- 選択したWDOGクロックソースは、停止モードでもアクティブな状態を維持する必要があります。
デバッグモードおよび停止モードでは、バスクロック以外のクロックソースを使用する必要があります。
一方、「電源モード」の章では、以下のことが説明されています。
スリープモード:
- CPUの実行が停止しました
- コアクロックゲートオフ
システムクロックとバスクロックは引き続き動作する可能性があります。
ディープスリープモード：
- コアクロックゲートオフ
- システムクロックゲートがオフになっています
バスの時計が閉まっている
これらの記述に基づくと、以下のように解釈するのが妥当と思われる。
- 待機モード ≈ スリープモード
- 停止モード ≈ ディープスリープモード
しかし、リファレンス・マニュアルにはこのマッピングを裏付ける明確な記述は見つかっていません。
私の質問は以下のとおりです。
1. WDOG待機モードはKW47のパワーモードスリープモードに対応しますか?
2. WDOG停止モードはKW47のパワーモードのディープスリープモードに対応しますか?
3. それとも、待機/停止はWDOG特有のCPU状態で、SoCの電源モードとは異なるのでしょうか?
4. この関係を明示的に説明したリファレンス・マニュアルのセクションやアプリケーションノートはありますか?
ご協力ありがとうございます。
こんにちは、お元気でお過ごしでしょうか。
KW47リファレンスマニュアルで使用されている用語は、WDOG制御レジスタのWAITおよびSTOPフィールドを、WDOG固有のCPU状態ではなくチップ/コアの低消費電力状態を参照として解釈するものと一致しています。両者の関係は、厳密な等価関係というよりは、機能的な対応関係と表現するのが適切でしょう。
その意味で、WDOG WAITは待機/スリープクラスの状態に相当し、CPUの実行は停止するものの、システムクロックとバスクロックは引き続き使用可能となる。WDOG STOPはStop/Deep-Sleepクラス条件に対応し、コア、システム、バスのクロックがゲートされており、ウォッチドッグはそのモードでアクティブなクロックソースを使用するように設定されて初めて継続できます。
よろしくお願いします、
ソフィア。
こんにちは、ソフィアさん。
先ほどのご説明、ありがとうございました。
あなたの回答に基づくと、私の理解は以下のとおりです。
- WDOG WAITは、待機/スリープクラスの低電力状態に対応します。
- WDOG STOPは、停止/ディープスリープクラスの低電力状態に相当します。
この関係は、厳密な一対一の対応関係ではなく、機能的な対応関係である。
KW47リファレンスマニュアルを改めて確認したところ、次のセクションを見つけました。
28.4 低消費電力モードでのモジュール動作
表225:低消費電力モードでのCortex M33コアモジュールの動作
WDOGxの場合、表には以下が示されています。
- スリープ：オン
- ディープスリープ：オプション
- 電源オフ：オプション
- ディープパワーダウン：オフ
この表から、WDOGの動作は少なくともディープスリープと電源オフモードで設定可能だと解釈しました。
挙動をよりよく理解するために、KW47-Loc評価ボードを使ってテストを行いました。
試験条件：
- WDOGが有効
- WDOG の更新は vApplicationIdleHook() から実行されます
- PWR_EnterLowPower() は FreeRTOS の vPortSuppressTicksAndSleep() から実行されます。
低電力状態に入った後にウォッチドッグリセットが発生するかどうかを観察する
テスト結果：
CASE 1
待機=0、停止=0
→ ウォッチドッグのリセットは発生しませんでした
CASE 2
WAIT=1、STOP=0
→ ウォッチドッグリセットが行われました
ケース3
WAIT=0、STOP=1
→ ウォッチドッグのリセットは発生しませんでした
私の解釈では、ウォッチドッグリセットが発生した際、デバイスは低電力状態に入り、vApplicationIdleHook()は実行されなくなったものの、ウォッチドッグは実行を継続し、最終的にタイムアウトしたと考えられます。
しかし、ウォッチドッグリセットはWAIT=1かつSTOP=0の場合にのみ発生し、STOP=1の場合はウォッチドッグリセットは発生しなかった。
この結果から、低電力モード時のウォッチドッグ動作において、WAITビットとSTOPビットが実際にどのように適用されるのか理解に苦しんでいます。
以下の点について説明していただけますか?
1.デバイスが PWR_EnterLowPower() によって低電力モードに入った場合、WDOG の動作は WAIT ビットと STOP ビットのどちらによって制御されますか？
2. 観測された結果は、デバイスがディープスリープモードではなくスリープモードに入っていることを示しているのでしょうか、それともディープスリープモードに入っていると解釈すべきでしょうか？
3. STOPビットは、電源モードの章で説明されているディープスリープモードに対応していますか、それとも別の低電力状態を指していますか？
4. 表225の以下の項目は、WDOG WAITおよびSTOP制御ビットに関してどのように解釈すべきですか？
- WDOGx：オプション（ディープスリープ）
- WDOGx：オプション（電源オフ）
再開まで今しばらくお待ちください。
こんにちは、 @hyama さん。返信が遅くなり申し訳ありません。
SDKの例を使ってテストしていますか?デバイスがディープスリープモードに入っていることをどのように確認していますか？
ご説明いただいた動作から判断すると、デバイスは単にスリープモードに入っているだけかもしれません。もしデバイスがディープスリープに入っていたら、結果は逆になります。STOP=1(CASE 3)がタイムアウトを引き起こし、WAIT=1(CASE 2)は影響がないはずです。WAIT=1がリセットをトリガーするという事実は、デバイスがディープスリープではなくスリープモードに入ったことと一致している。
皆様からのご質問にお答えします。
1.デバイスが PWR_EnterLowPower() によって低電力モードに入った場合、WDOG の動作は WAIT ビットと STOP ビットのどちらによって制御されますか？
CS[WAIT]とCS[STOP]は、それぞれ独立したモードを制御する独立した制御装置であり、CS[WAIT]はスリープモードでのWDOGの動作を制御し、CS[STOP]はディープスリープモードでのWDOGの動作を制御します。
デバイスがスリープモードに入る場合、CS[WAIT]がアクティブコントロールとなります。CS[STOP]はここでは効果がありません。なぜなら、ディープスリープには入らないからです。デバイスが代わりにディープスリープに入るように設定されている場合、CS[STOP]がアクティブな制御になります。
2. 観測された結果は、デバイスがディープスリープモードではなくスリープモードに入っていることを示しているのでしょうか、それともディープスリープモードに入っていると解釈すべきでしょうか？
この結果はスリープモードへの移行とは一致するが、ディープスリープとは一致しない。3つのテストケースに基づき、スリープモードに入っています。
3. STOPビットは、電源モードの章で説明されているディープスリープモードに対応していますか、それとも別の低電力状態を指していますか？
ドキュメントによると、CS[STOP]はディープスリープに対応し、テストで観察された挙動はこれと一致しています(ディープスリープが入力されていないと仮定した場合)。
4. 表225の以下の項目は、WDOG WAITおよびSTOP制御ビットに関してどのように解釈すべきですか？
ディープスリープの「オプション」とは、CS[STOP]=1かつバスクロック以外のクロックソースが設定されている場合にWDOGがディープスリープで動作できることを意味します。デバッグモードおよび停止モードでは、バスクロック以外のクロックソースを使用する必要があります。バスクロックを用いることで、ウォッチドッグはアーキテクチャ的に「有効化」できますが、そのクロックは失われており、例えば32K_CLKなど別のクロックソースが選択されない限りは消えています。
よろしくお願いします、
ソフィア。
こんにちは、 @sofiaurueta さん
先ほどのご説明、ありがとうございました。
>SDKの例を使ってテストしていますか?デバイスがディープスリープモードに入っていることをどのように確認していますか？
ご質問についてですが、テストはSDKのサンプルプロジェクトで実施されたものではありません。これはNXP SDKをベースにした私たちのアプリケーションで実施されました。
デバイスがディープスリープモードに入るかどうかを確認するため、追加調査を行ったところ、低電力モードに入る際に以下のパスが実行されることが分かりました。
vPortSuppressTicksAndSleep()
-> PWR_EnterLowPower()
-> PM_EnterLowPower()
-> PM_低電力モードに入る()
-> CMC_EnterLowPowerMode()
CMC_EnterLowPowerMode()では、SDKはWFIを実行する前にSCB->SCRレジスタのSLEEPDEEPビットを設定します。
SLEEPDEEPビットを設定してWFIを実行すると、デバイスがディープスリープモードに入るというのが私たちの理解です。この理解がKW47に対して正しいか確認していただけますか?
私が質問しているのは、WDOGテストの結果がSTOPビットではなくWAITビットに依存しているように見えるからです。
助けてくれてありがとう。