NXPメンバーの皆様へ
このチケットは以下のトピックに関連する場合があります:
SJA1110-Qbv-AdminBaseTime-Configuration
S32G-VNP-RDB3ボードにあるSJA1110スイッチでQbvの設定中、NXPのS32GのSJA1110 SDKを使ってgPTP/Qbvパラメータの設定、新しい sja1110_uc.bin ファイルのコンパイル、そしてAコアLinux BSPのファームウェアフォルダにデプロイしています。
最初は、PFE0インターフェース(SJA1110スイッチポート4)をgPTPグランドマスターとして使い、ADMINBASETIMEを0に設定していました。いくつかのテストや検証を行いましたが、すべて期待通りに動作しています。
しかし、プロジェクトの進行中に役割を再割り当てし、gPTPグランドマスターはポート3に接続された外部デバイスから出力されるようになりました。
この外部デバイスを接続した瞬間から、Qbvのパフォーマンスが非常に不安定になった。
例えば、大きなサイクル値から始めていくつかのテストを行いました。
Cycle = 1 sec -> 125000000
CycleExt (12.5%) = 15625000
segment 1 = 0.25 sec TCs 0 and 1 GATESTATUS 1 and 0
segment 2 = 0.25 sec TCs 2 and 3 GATESTATUS 6 and 7
segment 3 = 0.25 sec TCs 4 and 5 GATESTATUS 2 and 3
segment 4 = 0.25 sec TCs 6 and 7 GATESTATUS 4 and 5
port 3: TRIGGER_TIME = 1250000 (2x625000)
port 4: TRIGGER_TIME = 3125000 (4x781250)
ports 5...: TRIGGER_TIME = 125000テストのために、クライアント(S32G PFE0インターフェース)から同じネットワークにコネクテッドされた別のLinuxデバイスへUDPパケットを送信しています。
サーバー側でtcpdumpツールを使用してパケットをキャプチャし、結果を分析します。
この場合、送信は数秒後に開始されますが、一度開始すると正しく振る舞います(1秒サイクル、指定されたトラフィック優先度の25%)。
次に、GATESTATUSを4つのセグメントに分割しましたが、サイクルタイムを200msに短縮しました。
Cycle = 200ms -> 25000000
CycleExt = 3125000
segment 1 = 50 ms TCs 0 and 1 GATESTATUS 1 and 0
segment 2 = 50 ms TCs 2 and 3 GATESTATUS 6 and 7
segment 3 = 50 ms TCs 4 and 5 GATESTATUS 2 and 3
segment 4 = 50 ms TCs 6 and 7 GATESTATUS 4 and 5
port 3: TRIGGER_TIME = 250000
port 4: TRIGGER_TIME = 625000
ports 5...: TRIGGER_TIME = 25000うまくいくはずだったが、パケットの送信開始まで30秒から2分の間に開始する必要があった。
その後のテストでも、同じパターンが観察された。
- サイクルタイムを100ミリ秒に短縮すると、送信が開始されるまでに2分から4分待たなければなりませんでした。
- サイクルタイムが50ミリ秒に短縮された場合、送信が開始されるまでに5分から6分待たなければなりませんでした。
などなど。したがって、 サイクルの長さが短いほど、Qbvが実質的に始まるまでの待ち時間が長くなります。それまで、交通は遮断されていた。
しかし、以下の設定を行った際に、別の奇妙な動作が観察されました。
Cycle = 0.5 ms -> 62500
CycleExt = 7812
segment 1 = 30 μsec TCs 0, 1, 2, 4, 5, and 7: GATESTATUS 0, 1, 2, 3, 5, 6, and 7
segment 2 = 300 μsec TC 6: GATESTATUS 4
segment 3 = 170 μsec TCs 0, 1, 2, 4, 5, and 7: GATESTATUS 0, 1, 2, 3, 5, 6, and 7この場合、TC6以外のすべてのトラフィックは通過します。
設定を反転すると：
Cycle = 0.5 ms -> 62500
CycleExt = 7812
segment 1 = 30 μsec TC 6: GATESTATUS 4
segment 2 = 170 μsec TCs 0, 1, 2, 4, 5, and 7: GATESTATUS 0, 1, 2, 3, 5, 6, and 7
segment 3 = 300 μsec TC 6: GATESTATUS 4この場合、TC6のトラフィックのみが送信され、他のTCはブロックされます。
私の見解では、これは時刻同期の問題を示唆している。
S32DSでgPTPを設定した方法を以下に示します。
また、この外部gPTPグランドマスターは、現在のUnixエポックに基づいた同期タイムスタンプを提供する点も特筆すべきである。
PFE0がグランドマスターとして使用された場合、同期タイムスタンプは0から始まる。
この行動を説明できるものは何だろうか？
サポートありがとうございます!
よろしくお願いいたします。
ギレルメ
こんにちは、 @GuilhermeS32G さん、
はい、アクセスを待ってください。NDAに加えて、自動車用イーサネットは輸出管理政策に属しています。
私の意見では、ECTツールはスイッチの動的再構成に関連する優れたコードソースです。
はい、UnixエポックgPTPタイムスタンプをADMINBASETIME[0:31]とADMINBASETIME[32:63]に分割するのが正しい方法です。
よろしくお願いいたします。
パベル
こんにちは、 @PavelL さん。
ご返信ありがとうございます。
確かに、このECTツールは正しい方向性のように思えます。
しかし、まだダウンロードのアクセス権はありません。そこには「標準ソフトウェアSJA11XX - リクエストフォームが受領されました」と表示されます。アクセスできるかどうか、しばらく待つ必要があるかもしれません。
念のため、現在のUnixエポック（ナノ秒単位）を以下のように定義します。
1784013205012345678
これはUTCで表すと次のようになります。
2026年7月14日（火）午前7時13分25秒
このタイムスタンプをADMINBASETIME[0:31]とADMINBASETIME[32:63]に分割する正しい方法は何ですか？
よろしくお願いいたします。
ギレルメ
こんにちは、 @GuilhermeS32G さん、
フォローアップスレッドを作ってくださりありがとうございます。CASEの明確さを保つ助けになりました。
詳細情報と検査結果を一度に共有していただき、ありがとうございます。
ご提供いただいたデータを確認したところ、gPTPの設定は正しいようです。
したがって、このユースケースでは、現在の同期PTP/gPTP時間に基づいて動的にADMINBASETIMEを設定することをおすすめします(静的設定では固定値の0を使い続けます)。
典型的な手順は次のとおりです。
1. gPTPを起動し、スイッチが外部グランドマスターと同期するまで待ちます。
2. スイッチから現在のPTPクロックを読み取る。
3. ADMINBASETIMEを将来の時間値に設定します。例えば、現在のPTP時間+十分なセーフティマージン。
4. TAS/Qbvの管理パラメータを記述します。
5. TAS/Qbvの設定変更をトリガーします。
よろしくお願いいたします。
パベル