組み込みHMIは正常に起動し、インターフェースを表示し、タッチに応答する。アイドルタイムアウト後、画面が暗くなる。次のウェイクイベントでシステムは復帰するが、LCDは黒いままである。デバイスを再起動すると映像が復元される。.
この障害は誤解されやすい。コールドブートの成功は、ある起動条件下でシステムが映像を生成できることを示すにすぎない。パネル、ディスプレイコントローラ、バックライト、およびソフトウェアがすべての低電力状態から復帰できることを示すものではない。.
有用な問いは次のとおりである： ディスプレイシステムのどの部分が動作状態への復帰に失敗したのか？ LCDを交換したり、ドライバに遅延を追加したりする前に、この問いに答えること。本ガイドは、TFT LCDモジュールをLinuxまたはAndroidベースのHMIシステムに統合するOEMチーム向けに、実践的な調査手順を提供する。.
1. ディスプレイが正常に起動してもレジューム後に失敗する理由
コールドブートとレジュームは異なる条件から開始される。起動時には、ブートローダーとオペレーティングシステムが段階的にハードウェアを初期化する場合がある。レジューム中には、一部のコンポーネントは状態を保持するが、他のコンポーネントは復元が必要となる場合がある。レジュームパスはその差異を考慮しなければならない。.
例えば、ブートローダーがカーネルに制御を渡す前にパネルを初期化する場合がある。カーネルがその初期構成に依存しているが、電力損失後にそれを復元できない場合、初回起動は正常に見えても、その後のウェイクが失敗することがある。これは実際のブートローダー、パネルドライバ、およびボードサポートパッケージ（BSP）に対して確認すべき仮説として扱うこと。.
Linuxはシステムスリープとランタイム電力管理を区別する。システムスリープはマシン全体の状態を変更する。ランタイム電力管理は、システムがアクティブなままで個々のデバイスが低電力状態に入ることを可能にする。システムスリープが開始される前にディスプレイデバイスが既にサスペンドされていた場合、それらの相互作用が重要となる。.[1]
調査は2つのキャプチャから開始する：正常起動時とウェイク失敗時である。両者の動作が分岐するポイントを比較すること。レギュレータの遷移欠落、パネルコマンドの失敗、またはディスプレイ更新の欠如は、「レジュームが機能しない」という記述よりも有用な証拠である。“
2. 実際に何がスリープ状態に入ったかを特定する
“「スリープ」は製品仕様において、しばしばいくつかの異なる動作を指す。ユーザーには同じ暗い画面が見えるが、エンジニアリング要件は大きく異なる場合がある。.
| 状態または動作 | 確認すべき事項 | 重要な理由 |
|---|---|---|
| アプリケーションによるブランキング | アプリケーションは黒いコンテンツを描画したのか、それともインターフェースを非表示にしたのか？ | ディスプレイハードウェアは依然として正常に動作している可能性がある。. |
| バックライトオフ | LED照明のみが停止したのか？ | 映像生成は可視照明なしで継続している可能性がある。. |
| パネル低電力状態 | どのパネルコマンド、電源変更、およびリセット動作が発生したか？ | パネルには定義された終了シーケンスが必要な場合がある。. |
| ディスプレイサブシステムのランタイムサスペンド | どのコントローラ、ブリッジ、クロック、および電力リソースが変更されたか？ | CPUがアクティブなままで映像パスの復元が必要な場合がある。. |
| システムサスペンド | どのプラットフォームスリープ状態に入り、何がウェイクさせたか？ | 障害はディスプレイを超えたシステム復旧に関わる場合がある。. |
Linuxはsuspend-to-idleやsuspend-to-RAMを含む複数のシステムスリープ状態を文書化している。利用可能な状態とその動作はプラットフォームサポートに依存する。製品のスクリーンタイムアウトは、それ自体ではマシンがいずれかの状態に入ったことを証明しない。.[2]
実際のトリガーを記録すること：アプリケーションタイムアウト、オペレーティングシステムの電力ポリシー、物理ボタン、スケジュールされたイベント、または手動エンジニアリングテスト。ウェイクソースも記録すること。タッチイベントがシステムをウェイクできないが、物理ボタンはウェイクできる場合、その結果を映像復旧障害として扱う前にウェイク設定を調査すること。.
この区別はテスト計画も変更する。バックライトのみの調光、パネル電源断、およびシステムサスペンドには個別のテストケースが必要である。それらを1つの「スリープ/ウェイク」チェックボックスにまとめると、失敗している遷移を隠す可能性がある。.
3. バックライト障害と映像障害を分離する
ファームウェアを変更する前に、画面とデバイスの残りの部分が何をしているかを分類すること。ホストがシリアルコンソールやシステムハートビートなど、適切な独立チャネルを通じて復帰したことを確認すること。ネットワークも復旧が必要な場合、ネットワークアクセスだけでは結論が出ない可能性がある。.
| 観察された症状 | 最初の確認事項 | 保持すべき証拠 |
|---|---|---|
| 可視照明なし | バックライト電源、イネーブル信号、輝度コマンド、PWM出力、および利用可能な場合はドライバ障害ステータス | スリープ前とウェイク後の電源および制御測定値 |
| バックライトはオンだが、映像が表示されない | パネル電源、リセット、初期化、アクティブディスプレイモード、および映像出力 | パネルドライバログおよび関連する信号キャプチャ |
| 古い映像がフリーズしたまま | アプリケーション更新、コンポジタアクティビティ、スキャンアウト状態、およびサポートされている場合はフレーム保持モード | タイムスタンプ付きコンテンツ変更およびディスプレイ更新の観察記録 |
| 映像は戻るが、タッチが機能しない | タッチコントローラ電源、バス通信、割り込み動作、ドライバ復旧、および入力配信 | 入力イベントおよびタッチドライバログ |
| ホスト側の復旧を示す独立した兆候がない | システムウェイクおよびデバイスの電源管理エラー | 失敗した遷移時のシリアル出力または保持されたログ |
これらのチェックは調査分岐を特定するものであり、根本原因を証明するものではない。バックライトが点灯していることは、LCDが初期化されたことを証明しない。画像が固まっていることは、アプリケーションが停止したことを証明しない。古いコンテンツと正常な更新を区別するために、意図的に変化するテスト画像を使用すること。.
透過型LCDの場合、バックライト消灯時に外部照明下で注意深く検査すると、かすかな画像が確認できることがある。肯定的な観察結果は、照明経路の切り分けに役立つ。画像が確認できない場合は、光学スタックと視認条件が可視性に影響するため、結論を出せない。.
Linuxはバックライト制御を独立したサブシステムとして扱う。そのドライバインターフェースには、輝度更新およびオプションのサスペンド/レジューム処理が含まれる。したがって、ソフトウェアの輝度値は、照明の証明として受け入れるのではなく、ハードウェア出力と比較する必要がある。.[3]
4. 電源、リセット、およびパネル初期化のレビュー
次の問題は、パネルが有効な復旧シーケンスを受信したかどうかである。正確なLCDモジュールおよびリビジョンのデータシートと統合手順を使用すること。すべてのTFT LCDに共通する遅延やコマンドシーケンスは存在しない。.
測定された動作を必要なシーケンスと比較する
障害イベント前後の関連するパネル電源レール、リセット信号、およびバックライトイネーブルをキャプチャする。それらのレベルと順序をモジュール要件と照合する。メーカーが指定する最小オフ時間または放電要件を含めること。.
次に、ドライバの意図する動作と測定された信号を比較する。「電源有効」と記録されたログは、ソフトウェア動作が要求されたことを確認するものであり、パネルコネクタの電圧を立証するものではない。遷移中にローカルレールが異なる挙動を示す一方で、上流電源が安定して見えることがある。.
どの状態が維持されたかを特定する
パネル電源が除去された場合、電源復帰後にモジュールが必要とする初期化を判断する。電源が維持された場合、パネルがコマンドされたスリープ状態に入ったかどうか、およびその状態からどのように抜け出す必要があるかを特定する。パネル要件を確認せずに、レジュームシーケンスの代わりにコールドスタートシーケンスを代用しないこと。.
Linux DRMパネルヘルパーは、準備、有効化、無効化、および準備解除を区別する。この分離は、パネル電源と可視出力が関連するが別個の操作としてレビューされるべき理由を示している。ベンダーBSPはこれらの責務を異なる方法で実装する場合があるため、製品で使用されているコードを検査すること。.[4]
遅延変更を使用して仮説を検証する
追加された遅延は、原因を特定することなく障害を低減する場合がある。遅延が有効と思われる場合、それを測定されたイベント（レール安定化、リセット解除、コマンド完了、またはその他の文書化された要件）に関連付けること。以前に障害を引き起こした条件でテストを繰り返すこと。.
エンジニアリング目標は、十分なマージンを持つ正当化されたシーケンスである。1回のベンチテストに合格した遅延は、量産修正の証拠として不十分である。.
5. ディスプレイリンクとソフトウェア復旧パスを確認する
電源とリセットの動作を理解したら、ホストからパネルまでの画像パスを追跡する。そのパスの各部分を復元する責任を持つコンポーネントを特定する。設計がアクティブブリッジまたはコントローラボードを使用している場合はそれらを含める。.
MIPI DSI：初期化と送信を比較する
MIPI DSI設計の場合、文書化されたパネル初期化と、復旧中に実際に発行されたコマンドを比較する。BSPに適用可能な場合、コマンドエラーおよびDSIホストとPHYの復元をレビューする。ウェイク後に期待される表示モードがアクティブであるかどうかを確認する。.
有用な実験は、コマンド復旧とコンテンツ復旧を分離する。パネルコマンドが完了しても変化するテスト画像が表示されない場合、残りの画像パスを調査する。コマンドが失敗する場合、まずパネルとホストが通信可能な状態にあるかどうかを確認する。タイムアウトをLCDの欠陥の証明として扱うことを避けること。.
LVDS：レジューム後の出力設定を確認する
LVDSの場合、復元されたタイミング、クロック、レーン配置、およびデータマッピングを既知の動作設定と比較する。また、中間コントローラがある場合はそれを検証する。コールドブートが機能するため、すべての初期選択決定を再検討する前に、遷移中に何が変化するかを調査すること。.
ブリッジが存在する場合、その設定が選択されたスリープ状態を経ても維持されるかどうかを確認する。ダウンストリームデバイスが未設定のままである一方で、ホストの復旧が成功する場合がある。.
eDP：接続の復旧を検査する
eDPの場合、利用可能な場合はソースドライバのAUX通信およびリンクトレーニング結果を保持する。失敗した復旧試行と成功した復旧試行を、パネル電源およびリセット測定と並べて比較する。必要な復旧動作は、パネル、ソース、および状態遷移に依存する。.
RJYの eDP TFT LCDパネル互換性ガイド をより広範な統合レビューに使用すること。本調査は、既に動作している設定がスリープに入った後に何が失敗するかという、より狭い問題を扱うものである。.
アプリケーション復旧の前にドライバ復旧を確認する
コマンドプロンプトに戻ったボードが、必ずしもグラフィックスパスを復元したわけではない。逆に、動作するディスプレイテストパターンは、通常のアプリケーションが正しく再開されたことを証明しない。これらのレイヤーを個別にテストすること。.
Linuxデバイス電源管理は、コールバックを使用してデバイスの遷移と依存関係を調整する。システムがレジュームしたからといってすべてのデバイスが復旧したと仮定するのではなく、実際のドライバ実装におけるエラーと順序をレビューすること。.[5]
Androidの場合、提供されたソフトウェアイメージ上で、ディスプレイサービス、コンポジタ、アプリケーション、およびタッチ入力の動作も比較する。必要な変更はボードリビジョンとBSPに依存する。一般的なインターフェースの一致は、ソフトウェア互換性を立証できない。.
6. 再現可能なサスペンド–レジュームテストマトリクスを構築する
間欠的な障害は、その条件が再現可能であれば有用な証拠となる。1つの固定されたハードウェアおよびソフトウェア構成から開始する。障害の境界がより明確になるまで、一度に1つの変数のみを変更する。.
| テスト変数 | 推奨カバレッジ | 記録 |
|---|---|---|
| 遷移 | バックライトオフ/オン、パネルスリープ/ウェイク、サポートされているランタイムサスペンド、およびサポートされているシステムサスペンド | 実際に入った状態と復旧結果 |
| スリープ期間 | 製品使用に関連する短期および長期の間隔 | 正確な期間と観察された電源挙動 |
| ウェイクソース | 製品が要求する各ソース | システムがウェイクしたかどうか、および画像とタッチが復帰したかどうか |
| 輝度 | 検証済み範囲内の低、中、高設定 | 要求された輝度と測定された制御出力 |
| アプリケーションアクティビティ | 静的UI、変化するグラフィックス、および代表的なワークロード | 最初の更新された使用可能なフレームまでの時間 |
| 繰り返しサイクル | プロジェクト検証計画に基づく定義された実行長 | 試行、失敗、サイクルインデックス、および失敗タイプ |
| 製品条件 | 承認された電源および環境条件と意図された筐体 | 条件および構成の差異 |
テスト実行前に合格基準を定義すること。意図された画像、継続的な更新、必要な箇所での使用可能なタッチ、正確な輝度、および製品の合意された時間制限内での復旧をカバーする必要がある。その制限は、別のディスプレイから数値を借用するのではなく、ユースケースから設定すること。.
サイクルが失敗した場合にはログを保存すること。対応している場合、Linuxの電源管理デバッグ機能はシステムサスペンドの段階を特定するのに役立つ。その可用性と適合性は、カーネル構成とプラットフォームに依存する。.[6]
観察された結果を正確に報告すること。失敗のない実行はその実行中に何が起こったかを確立するものであり、失敗率がゼロであることを確立するものではない。提案された修正を元の再現手順および関連する製品条件に対して再テストすること。.
7. ブラックスクリーンレポートを有用なエンジニアリング証拠に変える
“「画面が時々黒いままになる」では、サプライヤーは推測するしかない。有用なレポートは、症状を既知の構成と再現可能な遷移に関連付ける。.
例示的なレポート形式であり、製品テスト結果ではない： LCDはコールドブート後に正常に動作する。指定されたシステムサスペンド間隔の後、物理ウェイクボタンでシリアルコンソールが復元される。バックライトは点灯するが、変化するテスト画像は戻らない。失敗回数とサイクルインデックスを記録すること。正確なパネルモデル、ボードリビジョン、BSPバージョン、遷移ログ、および同期された電源/リセットキャプチャを添付すること。アプリケーションの再起動、サポートされているディスプレイリセット、またはデバイス全体の再起動で動作が復元されるかどうかを注記すること。.
復旧実験は別途記録すること。アプリケーションの再起動、ディスプレイパスの再初期化、およびパネル電源の再投入は、それぞれ異なる境界に影響を与える。成功した実験は調査を絞り込むが、何が変わったかを理解せずに恒久的な修正とすべきではない。.
ディスプレイおよびコントローラのレビューには、LCDデータシート、コネクタ定義、タッチコントローラの詳細、ボード構成、ソフトウェアバージョン、および意図された低電力動作を提供すること。RJYの TFT LCDおよびAndroidコントロールボードのマッチングガイド は、より広範な選定要件をカバーしている。.
最も強力な引き継ぎには、動作するベースラインと失敗した復旧の両方が含まれる。その比較により、パネル、ボード、およびソフトウェアチームが「スリープ」の異なる解釈をテストするのではなく、同じイベントを調査するのに役立つ。“
8. FAQ
コールドブートの成功は、LCDがサスペンドとレジュームをサポートしていることを証明するか？
いいえ。コールドブートは1つの起動パスを検証するものである。サスペンドとレジュームは、製品に必要な正確なパネル、ボード、ソフトウェアイメージ、および低電力状態についてテストする必要がある。.
デバイスの再起動でブラックスクリーンが修正された場合、問題は間違いなくソフトウェアか？
いいえ。再起動はソフトウェア状態を変更し、ハードウェアをリセットし、電源または初期化を復元する可能性がある。これは有用な診断観察であるが、それ自体で根本原因を特定するものではない。.
LCD画像が戻っても、レジューム後にタッチが失敗する可能性はあるか？
はい。タッチには独自のコントローラと復旧依存関係がある。その電源、通信インターフェース、割り込み動作、ドライバ復旧、および入力イベントを画像パスとは別に確認すること。.
すべてのTFT LCDがウェイク後に同じリセット遅延を使用すべきか？
いいえ。正確なモジュールとドライバICの要件を、ボード実装とともに使用すること。普遍的な遅延を適用するのではなく、ドキュメントと測定を通じてシーケンスを確認すること。.
OEMはディスプレイ復旧レビューにどのような情報を提供すべきか？
パネルモデルとデータシート、ボードリビジョン、ソフトウェアバージョン、実際のスリープ状態、ウェイクソース、再現手順、失敗回数、ログ、および利用可能な電源、リセット、バックライトの測定値を提供すること。.
RJYとディスプレイ復旧要件について相談する
RJY Displayは、コントローラボードの適応とプロジェクト依存のファームウェアサポートを伴うTFT LCDプロジェクトを支援している。組み込みHMIについては、, ディスプレイおよびコントローラボードの要件を提出し、 期待されるスリープおよびウェイク動作とともに提出すること。互換性と適応範囲は、特定のパネル、ボード、タッチ構成、およびソフトウェア環境についてレビューする必要がある。.
参考文献
以下のLinuxソースはアップストリームフレームワークを説明している。製品で使用されているカーネルバージョンおよびベンダーBSPへの適用可能性を確認すること。診断表とレポート形式は提案されたエンジニアリング手法であり、報告されたRJYテスト結果ではない。.