尊敬的恩智浦半导体成员们：
此工单可能与以下主题相关：
SJA1110-Qbv-AdminBaseTime-Configuration
在配置 S32G-VNP-RDB3 板上的 SJA1110 交换机的 Qbv 时，我一直使用 NXP 的 S32G SJA1110 SDK 来设置 gPTP/Qbv 参数，编译新的sja1110_uc.bin文件，并将其部署到 A-core Linux 电路板支持包 的固件文件夹中。
最初，我使用 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 分成四个段，但将周期时间缩短至 200 毫秒：
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 ，
是的，请稍候，您将获得访问权限。除了保密协议外，汽车以太网还属于出口管制政策的范畴。
我认为，ECT 工具是交换机动态重配置相关代码的绝佳来源。
是的，将 Unix epoch 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 ，
感谢您创建后续讨论帖——这有助于我们了解案件的最新进展。
感谢您一次性分享所有细节和测试结果。
我已检查所提供的数据，您的 gPTP 配置似乎是正确的。
因此，对于此用例，我建议根据当前同步的 PTP/gPTP 时间动态配置 ADMINBASETIME（并在静态配置中仍然使用固定值 0）。
典型的序列如下：
1. 启动 gPTP 并等待交换机与外部主控交换机同步。
2. 从交换机读取当前的 PTP 时钟。
3. 将 ADMINBASETIME 设置为未来的时间值，例如当前 PTP 时间 + 足够的安全裕度。
4. 编写 TAS/Qbv 管理参数。
5. 触发 TAS/Qbv 配置更改。
顺祝商祺！
帕维尔