2118582_ja-JP

[#1]

マルチ管理者モードでのコミッショニング中に応答がないため JN5189 RCP で OTBR エージェントがタイムアウトする

問題の概要

JN5189 RCP で OTBR を使用してマターマルチ管理者コミッショニング中に障害が発生しています。CHIPTool Android APK を使用したプライマリコミッショニングが正常に完了しました。ただし、CHIP Tool CLI を使用した二次コミッショニングは失敗します。

このプロセス中、otbr-agent ログには RCP との通信時にタイムアウトが繰り返し発生したことが記録され、エージェントが応答しなくなります。回復する唯一の方法は、エージェントを手動でリセットするか、RCP を再接続することです。

---

セットアップの詳細

コンポーネント: バージョン/説明
-----------------------------|--------------------------------------------------------
プライマリコミッショナー：CHIPTool Android APK
セカンダリコミッショナー: CHIP ツール CLI (Linux)
Thread デバイス：Nanoleaf A27バルブ
RCP プラットフォーム: UART 経由の NXP JN5189
RCPファームウェアコミット: dfbe12280af4a87cb9ae0c0c1d90d71de3372d82 (ot-nxpから)
OTBR プラットフォーム: Ubuntu 22.04 (x86_64)
カーネルバージョン: Linux 6.8.0-60-generic ##63~22.04.1-UbuntuSMP プリエンプトダイナミック
OTBRコミット: b8bab1babcb040251b51a69ccb4008fb4b9e2d3f
CHIP ツール CLI コミット: 9af93fd3e9eab4315e1097b19112ebac01d1ad94

---

再現手順

1. JN5189 RCP をコネクテッドして初期化した状態で OTBR を起動します。

2. CHIPTool Android APK を使用してプライマリコミッショニングを実行します (成功)。

3. APK を使用して、複数管理者のコミッショニング ウィンドウを開きます。

4. CHIP ツール CLI を使用して二次コミッショニングを試みます。

5. otbr-agent の動作とログ出力を観察します。

Re: OTBR Agent Timeout with JN5189 RCP During Commissioning in Multi-Admin Mode Due to No Responseこんにちは、ルイス。

1) ボーレート「1000000」を使用してみましたが、通信中にフレーミング エラーが発生します。

UART_DRIVER と SERIAL_MGR の両方でテストしました。これら 2 つのうち、より信頼性が高く、好ましい選択肢としてどちらをお勧めしますか?

さらにデバッグするために、ログを有効にして、USART FIFO オーバーフロー レジスタの値を確認しました。FIFOSTAT に RXERR ビットが設定されていることに気付きました。

参考までに、USART0 は 32 MHz (XTAL から供給) でクロックされ、メイン クロックは 48 MHz で動作しています。

BR、
ヴィカシュRe: OTBR Agent Timeout with JN5189 RCP During Commissioning in Multi-Admin Mode Due to No Response

こんにちは、ヴィカシュ

ボーレートはホストが確立したものに依存します。アドバイスとして、「1000000」を試してみるとよいかもしれません。参考までに、このボーレートは K32W の例ではデフォルトです。

JN5189 では USART0 と USART1 を使用してソフトウェア フロー制御がサポートされていますが、ハードウェア フロー制御の方が信頼性が高く、データに干渉しません。決定は各お客様に委ねられます。UM11138 23.6.5.2 章に記載

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

ルイス

Re: OTBR Agent Timeout with JN5189 RCP During Commissioning in Multi-Admin Mode Due to No Responseこんにちは、ルイス。

ご返信ありがとうございます。

私は、nRF52840 DK を搭載した Raspberry Pi 4B を使用してセットアップをテストしましたが、その構成では RCP TX タイムアウトやリセットは発生しませんでした。このことから、この問題は JN5189 の RCP イメージまたは UART 構成に関連している可能性が高いと考えられます。

最終的なハードウェア セットアップでは、RTS/CTS ハードウェア フロー制御はサポートされていないSO、フロー制御のない UART に制限されます。次の制約を考慮すると:

1) ハードウェア フロー制御が利用できない場合に JN5189 RCP に推奨される UART ボー レートは何ですか?

2) データ損失のリスクを軽減するために調整する必要があるバッファ サイズ、タイミング パラメータ、またはドライバ レベルの設定はありますか?

3) このシナリオではソフトウェア フロー制御 (XON/XOFF) はサポートまたは推奨されますか?

よろしくお願いします
ヴィカシュRe: OTBR Agent Timeout with JN5189 RCP During Commissioning in Multi-Admin Mode Due to No Response

こんにちは、

UART クロックはタイミング精度に影響します。UART クロックが不安定な場合は、ホストと RCP 間の同期が失われる可能性があります。

デバイス間のボー レートを慎重に一致させ、許容マージンをテストして、より低いボー レートを試すこともできます。

あるいは他の選択肢として、FRO32Kの代わりに、より正確なクロック周波数を提供するXTAL32K発振器に切り替えることもできます。詳細については、ユーザーマニュアル[UM11138]の4.4.4章を参照してください。UM11138

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

ルイス

Re: OTBR Agent Timeout with JN5189 RCP During Commissioning in Multi-Admin Mode Due to No Responseこんにちは、

ご返信ありがとうございます。

いくつか質問と意見があります。
UART クロック ソースはタイミング精度とデータ サンプリングに大きな影響を与えますか?

現在、システムはクロック ソースとして FRO32K を使用するように構成されています。

観察：
ホストとの通信をテストする場合:

1 Mbps では、10 回中 3 回程度成功します。

115200 では通信が成功することはほとんどありません。

この問題は、低周波数 (32.768 kHz) クロックを使用しているために UART ボー レートの生成が不正確になることに関連している可能性があります。
Re: OTBR Agent Timeout with JN5189 RCP During Commissioning in Multi-Admin Mode Due to No Response

こんにちは、

返事が遅くなり申し訳ありません。JN5189はUSART0のハードウェアフロー制御をサポートしています。詳細については、ユーザーマニュアル[UM11138]の23.6.5.1章をご覧ください。UM11138

ボーレートはホストが確立したものに依存します。

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

ルイス

Re: OTBR Agent Timeout with JN5189 RCP During Commissioning in Multi-Admin Mode Due to No Responseこんにちは、ルイス。

両端のログを確認したところ、RCP 側でデータの破損や損失が発生していることに気付きました。

この特定のCASEにおいて、JN5189 に最適な UART ボー レートを提案していただけますか?Re: OTBR Agent Timeout with JN5189 RCP During Commissioning in Multi-Admin Mode Due to No Responseこんにちは、ルイス。

フィードバックと参考リンクの共有をありがとうございます。

i.MX8M プラットフォームはすでに注文済みで、現在は到着を待っています。その間、既存の JN5189 セットアップを使用してデバッグを継続したいと思います。

その一環として、JN5189 が UART インターフェース上のハードウェア フロー制御をサポートしているかどうかを確認したかったのです。これにより、問題を切り分けながら通信の安定性を評価することができます。

ありがとう
ヴィカシュRe: OTBR Agent Timeout with JN5189 RCP During Commissioning in Multi-Admin Mode Due to No Response

こんにちは、

ファイル nxp_vendor_hook.cpp を確認します。このファイルは、JN5189 と K32W061 の両方に宛てられています。

テスト目的のためだけに、i.MX8M を使用して問題の根本原因を特定することをお勧めします。

以下のリンクは、コンサルティングのためにi.MXでOpen Thread Border Routerを実行する例にリダイレクトします。

ターゲットにOpenThread Border RouterとOpenther Deamonを設定する方法

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

ルイス

Re: OTBR Agent Timeout with JN5189 RCP During Commissioning in Multi-Admin Mode Due to No Response

こんにちは、ルイス。

早急なご対応ありがとうございます。

次の 2 つのプラットフォームでセットアップをテストしましたが、両方で同じ問題が発生しました。
i) ノートPC（Ubuntu）
ii) ルーター（OpenWRT）

1) コミッショニング プロセス中の私の観察では、Thread エンド デバイスは、要求に応じてチップ ツール コミッショナーに一連のメッセージを迅速に送信します。この急激なトラフィックの急増により、RCP が一部のパケットをドロップする可能性がありますが、OTBR はこれを予期して待機している可能性があります2)。

2) 外部委託に関しては、主な制約は PSKd であると考えています。そのため、Thread グループに懸念を表明し、現在は返答を待っています。

3) 次の問題もご覧頂けますでしょうか?
K32W061 プラットフォーム用にビルディングするときに使用される nxp_vendor_hook.cpp ファイルがあります。
JN5189 プラットフォームに同様のファイルが存在するかどうか、またはコンパイル時に DOT_NCP_VENDOR_HOOK_SOURCE マクロを有効にすることで、JN5189 の既存の nxp_vendor_hook.cpp を再利用できるかどうかが疑問です。

Re: OTBR Agent Timeout with JN5189 RCP During Commissioning in Multi-Admin Mode Due to No Response

こんにちは、

コンピューターの代わりに MCU/MPU を使用して OTBR を実行することをテストしましたか?NXP がサポートする例とガイドラインはさまざまなホストのテストを対象としており、それに関する詳細情報があります。

K32W061 のコンパイルは JN5189 にも適用できます。どちらも非常に似ています。

また、これが追加のコミッショニングの問題に当てはまる場合は、 External Commissioning | OpenThreadで確認していただけますか?

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

ルイス

Re: OTBR Agent Timeout with JN5189 RCP During Commissioning in Multi-Admin Mode Due to No Responsenxp_vendor_hook.cppがありますK32W061 プラットフォーム用にコンパイルするときに使用されるファイル。

JN5189プラットフォーム用の同様のファイルはありますか？または、JN5189で再利用するには、

コンパイル中の DOT_NCP_VENDOR_HOOK_SOURCE マクロを含める/有効にすることで可能ですか？
?