2355433_ja-JP

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

2355433_ja-JP

2355433_ja-JP

i.MX93 電源オフシーケンス

こんにちは、

現在、 i.MX93をベースにしたカスタム基板を設計しており、データシートに記載されている電源オフ要件を満たすために、アクティブ放電回路の開発に取り組んでいます。

私の理解を検証するために、 i.MX93 EVK (ボードリビジョン:700-51961 Rev B、SCH-51961 Rev B5、SOM B2)で測定を行いました。

i.MX93のデータシートによると、電源オフシーケンスでは、 BBSMレールが最後にオフになるレールである必要があります。

Michaelscott237_2-1776977725760.png

私が遭遇したもの

USB-C電源を抜いたり、ベースボードの主電源スイッチを切り替えたりすると、観測される動作シーケンスがデータシートの要件と一致しないようです。

Michaelscott237_3-1776977797795.png

測定設定:

  • CH1: SOCレール(TP703で測定)

  • CH2: BBSMレール(TP709地点で測定)


質問:

  1. EVKは、突然の電源喪失(例えば、USBケーブルの抜去)時に、管理された電源オフシーケンスをサポートするように設計されていますか、それともこの要件はPMICを介したソフトウェアによるシャットダウン時にのみ厳密に適用されますか?

  2. 私がキャプチャしたデータにおいて、EVKの動作がデータシートに記載されている電源オフシーケンスの要件から逸脱している理由を説明していただけますか?

助けてくれてありがとう!

Re: i.MX93 Power Off Sequence

しかし、ここで話しているのはi.MXであってPMICではありません。PMICがどのような状態になるかは気にしません。私が気にしているのは、電源を供給しているデバイス、つまりプロセッサです。

i.mXのデータシートより:

Screenshot_20260428_004443_Adobe Acrobat.jpg

最悪の場合、損傷を引き起こす可能性があると明記されているようですが、なぜ規定の手順に従わずに電源を切っても問題ないとおっしゃるのか理解できません。

何か見落としているでしょうか?

Re: i.MX93 Power Off Sequence

こんにちは、

これはデバイスに損傷を与えるものではなく、PMICのデータシートに記載されている想定される状態です。

オフモード

PCA9451Aは、VSYSがVSYS_PORしきい値を下回ると、どの状態からでもOFFモードに移行します。このモードでは、すべてのレギュレータがオフになり、すべてのレジスタがリセットされます。

よろしくお願いいたします。

Re: i.MX93 Power Off Sequenceデバイスに損傷を与えない**CASE**もあるのに、そもそもなぜ電源オフの手順が必要なのでしょうか?Re: i.MX93 Power Off Sequence

こんにちは、

情報ありがとうございます。

その通りです。PMICは入力電源を抜いた場合、すべてのレギュレータを同時にオフにしますが、これによりデバイスが損傷することはありません。

よろしくお願いいたします。

Re: i.MX93 Power Off Sequenceなるほど、分かりました。
正しく理解しているか確認したいだけです。
私はTIのこのガイドラインに従うようにしています。
https://www.ti.com/document-viewer/lit/html/SSZTAP3
あなたの説明によると、i.mxはこのような動作(予期しない電源オフ)から保護される必要はないので、その点については心配する必要はありません。ソフトウェアによる電源オフシーケンス以外に特別な考慮は不要です。予期しない電源オフの場合、すべてのレールが同時に遮断されるため、CPUに損傷を与えることはありません。
Re: i.MX93 Power Off Sequence

こんにちは、

この電源シーケンスは、ソフトウェアによってプロセッサがオフにされたときに実行されます。ボードを抜くと、VSYSが最小動作範囲を下回るため、すべてのレギュレータが同時にオフになることが期待されます。

i.MX93 EVKは、突然の電源喪失時にデータシートに記載されている電源遮断シーケンスを保証するものではありません。この要件は、PMICによって管理され、ソフトウェアによって開始されるシャットダウンの場合にのみ保証されます。

よろしくお願いいたします。


Re: i.MX93 Power Off Sequence「最悪の場合、漏電やプロセッサ/PMICへの不可逆的な損傷を防ぐため、電源オフの手順に従うことを推奨します。」
私が理解できないのは、先ほど示したEVKではその推奨事項に従っていないことです。
では、EVKソリューションに従うのはなぜ問題ないのでしょうか?
あるいは、電源プラグを抜く場合、手順に従う必要はないと宣言するのですか?おかしいと思うけど、そもそもなぜそれに従う必要があるの?
ソフトウェア的には、PMICを正しいシーケンスに設定するのは簡単ですが、私が知る限り、あなたはすべてのケースでそのシーケンスを指定した理由があるはずです...
Re: i.MX93 Power Off Sequence

こんにちは、

1.最悪の場合、漏電やプロセッサ/PMICへの不可逆的な損傷を防ぐため、電源オフの手順に従うことをお勧めします。電源が切断されても、何の損傷も生じないケースを数多く見てきました。

2. ソフトウェアに実装する必要はありません。

3. 当社のEVK電源管理ソリューションに従うことで、長期にわたる正常な動作が保証されます。

消費電力に関しては、1つの投稿につき1つのトピックのみを扱っているため、別のコミュニティ投稿を作成することをお勧めします。ご提出いただいたチケットで確認できます。

よろしくお願いいたします。

Re: i.MX93 Power Off Sequence

ご説明いただきありがとうございます。EVKの動作は「深刻な」停電時に想定されるものなので、いくつか追加の質問があります。

1. では、電源オフシーケンスの要件は、データ/RTC/セキュリティ状態の完全性のみを目的としたものなのでしょうか、それとも、電源レールが同時に冷却された場合、長期信頼性の問題やSoCへの物理的な損傷のリスクがあるのでしょうか?(つまり、EVKの電源を頻繁に切ると、すぐに故障してしまうということですか?)電源スイッチを使うのはごく一般的なことだから。あるいは、BBSMが崩壊した状態でSOCが高いままの場合、内部ダイオードのバイアスやラッチアップ状態が発生するリスクはありますか?

2. どちらでもないとしたら、この要件をソフトウェア経由で満たす本当の目的は何なのでしょうか?

3. 信頼性に関する要件が重要な場合、NXPは、PMICがシーケンスシャットダウンを実行するのに十分な「ホールドアップ」時間を確保するために、入力レール上の特定の総容量を推奨していますか?

そして、そこから別の疑問が生じます。現在、アクティブ放電プロセスの消費電流を削減するために、i.MXを可能な限り低い電力に設定する方法を調べているのですが、例えばサスペンドモードでNXPが測定した結果と同じ結果が得られないようです(echo memコマンドでサスペンドモードに入ると、SOCレールで12mA、VSYS_5V [PMIC INPUT]で85mAになりますが、これはかなり多いように思えます)。



Re: i.MX93 Power Off Sequence

こんにちは、

この要件は、PMICを介したソフトウェアによるシャットダウン時にのみ厳密に適用され、USB-C電源ケーブルを抜くと、すべての電源レールが同時にシャットダウンされます。

あなたが目にしている現象は想定内のものです。

よろしくお願いいたします。

Re: i.MX93 Power Off Sequence

こんにちは、

社内チームと再度検討した結果、「不可逆的な損傷(最悪のシナリオ)」に関する記述は、主に電源投入シーケンスの逸脱に適用されることが判明しました。電源投入時に、電源供給順序が間違っていると、過電流や逆給電が発生し、プロセッサが電気的に損傷する可能性があります。

電源オフの場合は状況が異なります。すべての電源はすでに有効なレベルにあり、電源が切断されると(たとえば、ケーブルを抜くと)、レギュレータとプロセッサは単純に0Vに低下します。この場合、同様の電気的ストレスメカニズムは存在しないため、電源オフ手順を厳密に守らなくてもi.MXは損傷を受けません。

そのため、ソフトウェア制御によるシャットダウンが推奨されます(実行中のタスクを完了させ、アプリケーションによってはデータ破損が発生する可能性があるため)。ただし、プロセッサを保護するための電気的な要件ではありません。ハードウェアの損傷を回避するための重要な要件は、正しい電源投入順序を維持することである。

よろしくお願いいたします。

Tags (1)
No ratings
Version history
Last update:
‎04-29-2026 02:38 AM
Updated by: