[参考译文] AM2431：AM243x CPTS 模块和时间同步路由器问题

尊敬的 Matt：

我观察到、为启用 40kHz Genf 信号、之前与您共享的示例代码存在轻微偏差。 需要通过以下方式更新 IOCTL 调用。  如果您遇到任何链接错误、这应该会修复它。

- status = Enet_ioctl(hEnet, coreId, CPSW_CPTS_IOCTL_SET_GENF, &prms);
+ ENET_IOCTL(hEnet, coreId, CPSW_CPTS_IOCTL_SET_GENF, &prms, status);

关于配置 Timesync 路由器以将输出发送到物理 PIN、请使用以下示例代码。

关于 CPTS 模块的说明如下：AM64x 中有 2 个 CPTS 模块。 一个位于 CPSW IP 中、另一个位于独立模式。 我们需要配置 CPSW 中的 CPTS。 示例代码配置了正确的 CPTS、该 CPTS 位于 CPSW 中。

e2e.ti.com/.../sample_5F00_code_5F00_TSR_5F00_init.c

对于 ISR、我尚待确认这是否起作用。 但这是触发事件的可行途径。 如果启用了 ISR、请注意、由于切换事件将在每个周期发生两次、因此 ISR 将以 40kHz 输出信号频率的两倍触发。

已知 sync0_out 信号是布线到外部的信号、它也与 syscfg 引脚输出内联。 我将在内部请求、以便再次对其进行审核。

如果您对此代码有任何疑问、敬请告知。

尊敬的 Teja：
感谢您的回答。 我将示例代码合并到了 gptp_cpsw_app 示例中。 我们在 J12 引脚 1 处看到 0V (SYNC1_OUT_TP)。 此外、ISR App_cptsEventCb () 不会被调用。 我们还缺少什么？

这是我们所做的:
在 C：\ti\mcu_plus_sdk_am64x_11_01_00_17\source\networking\enet\core\examples\tsn\enetapp_cpsw.c 中：

static void EnetApp_enableTsSync()
{
    ...
-    bitSelect = CPSW_CPTS_TS_OUTPUT_BIT_17;    
+    bitSelect = CPSW_CPTS_TS_OUTPUT_BIT_DISABLED;
    ...
}

static Pinmux_PerCfg_t gCustomPinMux[] = {
    /* ECAP0_IN_APWM_OUT (D18) - set desired mode here */
    {
        PIN_ECAP0_IN_APWM_OUT,
        ( PIN_MODE(1) | PIN_PULL_DISABLE )
    },
    {PINMUX_END, PINMUX_END}
};

void EnetApp_initAppCfg(EnetPer_AttachCoreOutArgs *attachArgs, EnetApp_HandleInfo *handleInfo)
{
    ...
    EnetApp_enableTsSync();

    Pinmux_config(gCustomPinMux, PINMUX_DOMAIN_ID_MAIN);
    int32_t status = SetupGenFWithSync0Out(gEnetAppCfg.hEnet);
}

除了结果之外、我对同一代码还有一些问题：
1.能否详细介绍一下 ConfigureTimesyncRouter () 的工作原理?
看起来示例代码正在将 IR 输入索引值写入多路复用器控制寄存器 (base：Timesync_event_INTROUTER0、offset：(IR 输出索引值* 4))？
这样、我们会将 CPSW0 中的 CPTS_genf0 路由到 TIMESYNC_EVENT_INTROUTER0_OUTL_24 (PINFUNCTION_SYNC0_OUTOUT)？
这个多路复用器控制寄存器是否为 10.3.2.3.1.2.1 中的“TIMESYNC_INTROUTER0_INTR_MUXCNTL 寄存器“？
但我似乎没有找到在 TRM 中说明工作原理的说明。

对于 ISR、尽管我们没有看到任何中断（可能是由于其他原因）、但您能否解释为什么使用 CPSW_CPTS_EVENTTYPE_TS_COMP？

尊敬的 Matt：

我已经与专家确认,来自同一 Genf 的事件回调不能触发事件,因此没有 ISR 和它一起。 因此、我们必须将其路由到 H/W 推送事件、以便我们可以使用该事件处理中断。 这也将帮助我们在此阶段验证 Genf 的创建。

为了在内部进行检查以确定是否正确生成了 Genf 信号、我们可以通过将信号路由到 H/W 推送事件来进行验证、然后使用 IOCTL“CPSW_CPTS_IOCTL_REGISTER_HWPUSH_CALLB“将回调链接到它。 如果正确配置了 Genf、我们将不时地命中这个 ISR。  

另一方面、我们的硬件团队会研究引脚排列的详细信息、我们预计会在 1-2 天内做出响应。  

下面、我附加了一个示例代码、用于配置 SCI 客户端、以便通过 SCI 客户端配置 Timesync 路由器。 我无法从我的角度验证这一点 我将在接下来的 3 天内尝试在我的设置中运行此程序。

static void EnetApp_setTimeSyncRouter()
{
     int32_t                             retVal;
    struct tisci_msg_rm_irq_set_req     rmIrqReq;
    struct tisci_msg_rm_irq_set_resp    rmIrqResp;
    rmIrqReq.valid_params           = 0U;
    rmIrqReq.valid_params          |= TISCI_MSG_VALUE_RM_DST_ID_VALID;
    rmIrqReq.valid_params          |= TISCI_MSG_VALUE_RM_DST_HOST_IRQ_VALID;
    rmIrqReq.global_event           = 0U;
    rmIrqReq.src_id                 = 6U;
    rmIrqReq.src_index              = 21U; // cpsw_genf0
    rmIrqReq.dst_id                 = 6U;
    rmIrqReq.dst_host_irq           = 25U; // SYNC1_OUT pin // 24 for SYNC0_OUT
    rmIrqReq.ia_id                  = 0U;
    rmIrqReq.vint                   = 0U;
    rmIrqReq.vint_status_bit_index  = 0U;
    rmIrqReq.secondary_host         = TISCI_MSG_VALUE_RM_UNUSED_SECONDARY_HOST;


    retVal = Sciclient_rmIrqSetRaw(&rmIrqReq, &rmIrqResp, SystemP_WAIT_FOREVER);
}

此致、
Teja。

尊敬的 Teja：

因此、您以前的方法似乎不起作用、示例代码则不起作用。

感谢您的回答、但请进一步阐明以下内容：

1. EnetApp_setTimeSyncRouter() 是否替换先前的 ConfigureTimesyncRouter()-以将 CPSW_GENF0 路由到 SYNC_OUT0（现在是 SYN1_OUT）？

• 如果是、请解释以下内容：
  答:我想你提到了 Sciclient 库没有管理这个?
  
  b.您能解释为什么 src_id 和 dst_id 为 6 吗？
  
  c. dst_host_IRQ 应该是 IR 输出索引、还是 MCU_PLUS_SDK_am64x_11_01_00_17\source\drivers\hw_include\am64x_am243x\cslr_intr_r5fss0_core0.h 中定义的中断源？
• 如果没有,请解释 EnetApp_setTimeSyncRouter () 的作用。

2.您能否帮助提供有关如何将 CPSW_GENF0 路由到 CPTS_HW1_PUSH 事件及其 ISR 的示例代码？

感谢您的帮助！

尊敬的 Matt：

EnetApp_setTimeSyncRouter () 是否替换以前的 ConfigureTimesyncRouter ()-将 CPSW_GENF0 路由到 SYNC_OUT0（现在是 SYN1_OUT）？

是的、应该替换它。 但它只是一个示例代码、正确的预期 dst 应是 sync0_out。 我们还确认了 D18 引脚是指硬件组的 sync0_out。 因此、我们必须针对#24 而不是#25 进行配置。

您能否解释 src_id 和 dst_id 为何为 6？

这指的是 在  timesync 路由器的中断管理说明中的中断路由器配置中提到的 IR 设备 ID。

dst_host_IRQ 应该是 IR 输出索引、还是 mcu_plus_sdk_am64x_11_01_00_17\source\drivers\hw_include\am64x_am243x\cslr_intr_r5fss0_core0.h 中定义的中断源？

它应该是 上述文档中给定资源的 IR 输出索引。

我 计划在测试设置中提供一个示例。 由于还有其他活动正在并行进行、因此需要一些时间来节省时间。 请使用 SCI 客户端 API 来配置时间同步路由器。  

通过将生成的信号路由到另一个硬件推送事件、我们可以了解是否正确生成了信号、之后我们可以集中精力输出信号。 如果没有正确生成信号、我们在输出端观察信号的试验将不会有成效。 因此、请使用以下组合检查 Genf 生成。

1. 配置 timesync 路由器以使用 sci API 将 Genf 路由到其中一个硬件推送事件。 (30-37 为 DST_HOST_IRQ)
2. 使用 CPSW_CPTS_IOCTL_REGISTER_HWPUSH_CALLBACK IOCTL 注册 CB
3. 删除设置 tsCompVal 和调用 SET_Genf IOCTL 之间的打印内容

这将确认 Genf 正确生成信号。 同时、我将努力从外部路由信号

谢谢。此致、
Teja。

谢谢你、Teja！

通过以下更改、我能够在 J12 引脚 1 上看到 40kHz 信号：

• 添加了在启用 Genf 之前的 Pinmux_config (gCustomPinMux、PINMUX_domain_ID_MAIN) 调用
• 在 ConfigureGenF () 中将 Genf 频率计算值减半：
  

  -  genFLength = CPTS_RFTCLK_FREQ_HZ / (freqHz * 2U);
  +  genFLength = CPTS_RFTCLK_FREQ_HZ / (freqHz);

另外、使用 Sciclient_rmIrqSetRaw () 和 ENET_IOCTL () CPSW_CPTS_IOCTL_REGISTER_HWPUSH_CALLBACK、我能够在一秒钟内看到回调得到大约 40,000 次调用。
但是、我在将 Genf 同时路由到多个输出 (SYNC0_OUT 和 CPTS_HW1_PUSH) 时遇到了问题。
请查看下面的测试代码：

static int32_t EnetApp_setTimeSyncRouter()
{
    int32_t                             retVal;
    struct tisci_msg_rm_irq_set_req     rmIrqReq;
    struct tisci_msg_rm_irq_set_resp    rmIrqResp;

    // CPSW_GENF0 -> SYNC0_OUT
    rmIrqReq.valid_params           = 0U;
    rmIrqReq.valid_params          |= TISCI_MSG_VALUE_RM_DST_ID_VALID;
    rmIrqReq.valid_params          |= TISCI_MSG_VALUE_RM_DST_HOST_IRQ_VALID;
    rmIrqReq.global_event           = 0U;
    rmIrqReq.src_id                 = 6U;
    rmIrqReq.src_index              = 21U; // cpsw_genf0
    rmIrqReq.dst_id                 = 6U;
    rmIrqReq.dst_host_irq           = 24U; // 24 for SYNC0_OUT
    rmIrqReq.ia_id                  = 0U;
    rmIrqReq.vint                   = 0U;
    rmIrqReq.vint_status_bit_index  = 0U;
    rmIrqReq.secondary_host         = TISCI_MSG_VALUE_RM_UNUSED_SECONDARY_HOST;

    retVal = Sciclient_rmIrqSetRaw(&rmIrqReq, &rmIrqResp, SystemP_WAIT_FOREVER);
    if(retVal != SystemP_SUCCESS)
    {
        return retVal;
    }

    // CPSW_GENF0 -> CPTS_HW1_PUSH
    rmIrqReq.valid_params           = 0U;
    rmIrqReq.valid_params          |= TISCI_MSG_VALUE_RM_DST_ID_VALID;
    rmIrqReq.valid_params          |= TISCI_MSG_VALUE_RM_DST_HOST_IRQ_VALID;
    rmIrqReq.global_event           = 0U;
    rmIrqReq.src_id                 = 6U;
    rmIrqReq.src_index              = 21U; // cpsw_genf0
    rmIrqReq.dst_id                 = 6U;
    rmIrqReq.dst_host_irq           = 30U; // 30 for CPTS_HW1_PUSH
    rmIrqReq.ia_id                  = 0U;
    rmIrqReq.vint                   = 0U;
    rmIrqReq.vint_status_bit_index  = 0U;
    rmIrqReq.secondary_host         = TISCI_MSG_VALUE_RM_UNUSED_SECONDARY_HOST;

    retVal = Sciclient_rmIrqSetRaw(&rmIrqReq, &rmIrqResp, SystemP_WAIT_FOREVER);

    return retVal;
}

第二个 Sciclient_rmIrqSetRaw () 的返回值为–1、不调用回调。 如果我删除第一个 Sciclient_rmIrqSetRaw () 调用,那么我可以看到回调每秒大约被调用 40,000 次,但在 SYNC0_OUT 上没有 40kHz 输出。

您能否提供以下帮助：
1.请检查并进一步解释 ConfigureGenF () 中的 Genf 频率计算。
2.请帮助将 Genf 同时路由到 SYNC0_OUT 和 CPTS_HW1_PUSH。

我们将测试主控器和从控器之间 SYNC0_OUT 的抖动。

谢谢！

尊敬的 Matt：

我能够验证您将基因计数减半所做的更改是否正确、因为我也观察到了同样的事情。 看起来、我对该计算有了错误的理解、其中不是每次切换给出 Genf 频率、而是给出一个完整的周期。 之前的计算基于每个切换所需的节拍数。 电流配置为目标频率信号的整个周期所需的节拍数。 我们的专家昨天证实了这一点。 我能够从我这边再现这一点

当我们需要将 Genf 路由到 SYNC0_OUT 和硬件推送事件时、我还没有尝试配置此项、但我们来检查它的行为。 如果这变得困难,我们可以配置第二个 Genf ,它将与另一个 Genf 同步以触发第二个信号。

我会 随时 向您发布我们的调查结果。

谢谢。此致、
Teja。

尊敬的 Teja：

是的、请帮助提供使用单输入 Genf 创建 2 个输出的解决方案。

2 Genf 实例可能不适合我们,因为我们必须担心如果这些 2 Genf 实例是同步的或不同步的。

感谢您的帮助！

尊敬的 Teja：
我只想向您介绍抖动测量结果。 我们观察到主设备和从设备都在生成 40kHz Genf 信号。 然而、两个 Genf 信号并未锁相。
我的理解是、Genf 信号是根据 CPTS 计时器值生成的。 因此、来自主控器和从控器的两个 Genf 信号应该同相锁定。 我们还观察到 gptp_cpsw_app 从站控制台显示主站的时间差小于 50ns。

问题：

我们如何使两根 Genf 信号锁相？ 请提供帮助。

尊敬的 Matt：  

两个 Genf 信号将同步、因为它们由同一个时钟驱动、并且应获得相同的校正。 我们仍在努力确认时间同步路由器输出一对多映射的行为。  

关于相位锁定信号、我们可以在以后启动时钟来实现、通常是当前时间+（偏移以使其达到一秒整数）。 但它假设电路板在 1 秒的时间差内启动。  

目前、我们正在使用 TS OUT 的现有示例中实施类似的策略。 您也可以参考 Genf 的实现。  

谢谢。此致、
Teja。

嗨、Teja、  

我想直接谈谈、让大家更清楚地谈谈。 Matt 提到过我们已经锁频、但我认为实际情况并非如此。 在我们的电流测试设置中、我们触发领导者 Genf 输出、并在跟随者的 Genf 输出上有第二个示波器探头。 我们可以看到跟随者的 Genf 输出在领导者 Genf 输出之间滑动、这表明我们可能会被锁相、但肯定不会被锁频。 根据我的计算、Genf 的两个参考时钟的频率仅相差约 0.0714Hz、这似乎只是不同 IC 上两个 PLL 输出之间的精确差异

我有一个理论、这是因为我们使用 200MHz PLL 作为领导者和跟随者 Genf 实例的基准时钟。 正如示例代码所建议的、我们也不会对基准时钟应用任何 PPM 调整。  

最终、我们需要在所有节点上提供锁相和锁频 Genf 输出、我相信有两种潜在的方法可以实现这一点。 我希望获得 TI 的一些指导、了解这两种方法中的任何一种甚至都是不错的选择、以及首选哪种方法。  

• 选项 1 — 使用未校正的 200MHz PLL 作为 Genf 实例的基准时钟、但使用 Genf 模块中的 CPTS PPM、梯形和方向值来调节时钟并使其保持锁频
  • 我认为这样做的好处是 CPTS 模块和 Genf 模块都将依靠 200MHz 时钟运行、因此 PPM、Nudge 和方向值可以位于同一个球场、但我认为这不是首选选项、因为我们将根据领导者和跟随者 200MHz 时钟得出的校正应用于领导者和跟随者 PLL 时钟、这些时钟可能会有不同的关闭量。  
• 选项 2 — 使用校正后的 CPTS 计数器作为 Genf 模块的参考时钟、并将 Genf PPM、Nudge 和方向校正值保留为 0、就像我们现在的示例代码中所示。  
  • 我认为这是更好的方法、因为我们使用的时钟与 TSN 网络中任何给定节点上的 Genf 实现尽可能接近。  

假设选项 1 不是一个好选项、我想了解使用在 200MHz 下运行的 CPTS 计数器是否可行、我认为这已经是、以便用作 Genf 的参考时钟。 如果我们无法直接使用 CPTS 计数器、是否有一个从 PTP 协议栈调味品的调节时钟可以用作 Genf 的基准时钟？

您能分享这样做的可行性、以及 Matt 如何在我们的测试设置中实施这一点吗？  

同时、我们将启动 EVM、让网络收敛、然后在未来一次在两个电路板上启动 Genf（当前时间+偏移）、以便我们可以看到 Genf 信号是否同时启动。 这至少表明我们实际上已锁相、然后我们只需要解决锁频的问题！

大家好、  

下面是我们今天测试的更多信息。 我们主要尝试验证我们是否在引导板和跟随板上的两个 CPTS 模块之间保持了同步通信。  

我们所做的第一件事是启用在 ALV U1 上输出的 CPTS0_TS_SYNC 信号。 我们在 HSE 扩展板的 J3 引脚 11 上以 3.184kHz 的频率测量了此信号。 当 GENF0 正在运行时、此信号看起来没有在两个板之间同步。 他们开始同步、然后跟随者板开始漂移。 在最坏的情况下,跑了大约 2 分钟后,它关闭了 40us。 它看起来并不像抖动、看起来只是不断增加主器件的偏移、直到离主器件有 40 μ s 的时间。  这表明、当 Genf 配置并运行时、一些东西正在中断 PTP 堆栈、或 CPTS 内部的某种东西、这使我们失去 CPTS 校正

我们做的下一件事是确保我们在调试过程中不会中断 CPTS 模块并将 Genf 添加到我们的项目中。 我们基本上只是注释掉了 Genf 配置、并重新运行了相同的实验。 两个电路板上的 CPTS0_TS_SYNC 信号实际上彼此校正、并且我们观察到的抖动限制在 100ns 以下。  

Genf 在我们的项目中的一些实现是打破 CPTS 同步。 如果您对导致此行为的原因有任何建议、那将是非常好的。 另一点需要注意的是、从器件电路板上一旦发生 Genf 配置、从器件电路板就会尝试成为主板。  

请帮助我们解决此问题、因为我们可以在任何节点上调用 Genf 并获得所需的相位和频率锁定选通至关重要。  

尊敬的 Calvin：

我已经设置了测试台来查找 Genf 的频锁和相锁问题。 我能够确认您在 Genf 上下文中看到的频锁问题、但确切的频率不匹配仍有待确认。 这是因为 AM64x 版本的 Enet 驱动程序当前未对 Genf 计数器应用校正。 这可在使用 Enet 驱动程序的其他平台上实现。 我们目前正在努力确认 Genf 频率和锁相的测试结果。

关于您的测试中提到的漂移问题、我在测试运行中没有观察到。 但是、由于我们尚未专门运行这些测试、因此我希望在测试设置中进行验证、以便重现此问题并找出根本原因。 我将在一天结束时更新此测试结果。

一旦我们可以验证 Genf SYNC 是否稳定、我将共享补丁以在您正在使用的 SDK 上启用它。

此致、
Teja。

尊敬的 Calvin：

我能够测试两个电路板之间的 Genf SYNC、并能够验证频率和相位锁定。 这是用于启用相同功能的补丁。

e2e.ti.com/.../0001_2D00_Add_2D00_genf_2D00_corrections_2D00_to_2D00_cpts_2D00_corrections.patch

我能够通过在 4 小时的测试中验证、我们看到了大约 +/–75ns的差异。

如果以 1 秒差分启动两个输出、则贴片的 genfArgs.compare 输入也会发生变化、以使两个输出进行相位对齐、并且 SYNC 信号将在实现适当的同步（在本例中为大约 20 秒）后开始输出到输出  

这仍然使用 2 个 Genf 信号、但通过应用 Genf 校正 的方式、两个 GenF 将保持同步。

 这显示、当 Genf 配置并运行时、PTP 协议栈或 CPTS 内部的某种东西正在中断、这使我们失去 CPTS 修正

我无法在我们的测试设置中重现问题。 能否请您在末尾阐明测试设置并进行同样的验证？

由于 Genf 信号将保持同步、因此我 当前不是针对所看到的 TS SYNC 问题。 如果您在设置中仍看到此问题、并且需要此 TS 同步输出信号 (3.184kHz)、那么我们将查看此问题。  

请告知我们您的观察结果、以便我们能够规划后续步骤。

谢谢。此致、
Teja。

嗨、Teja、  

感谢您的支持。 我们能够锁相 Genf 信号、并在今天锁频、大约 2 小时后、我们看到总累积抖动约为 80ns。 我们仍然需要两方面的帮助：  

1.生成具有 Genf 上升沿的 ISR 事件 — 我知道 TI 团队已经在努力实现该目标、只想重申、这仍然是一个优先事项。 我知道有人建议以 40kHz 实例化第二个 Genf 输出、并通过 TSR 将其路由到 ISR、但我们至少要验证该 Genf 与第一个 Genf 的输出完全相同、我认为这不可能、因为我们必须将第二个 Genf 路由到 CPSW 同步引脚、但我认为没有更多可用的。  

2.我们需要找到一个更好的方法来真正开始 Genf。 目前、我们有两个 EVM 通过板上的 CPSW 端口相互连接、它们都连接到运行两个 CCS 实例的 PC、因此我们可以从这两个 EVM 获取串行输出。 我们一次只能对一个板进行编程、此外、我们一次只能有一个 EVM。 这意味着我们基本上必须将 Genf 的开始时间配置为大约 2 分钟、这样才能实现这一目标。 这可以证明 Genf 足够稳定、可以成为我们的频闪灯、但是、如果有更好的 Genf 应用入门方法、我们希望 TI 提供一些指导。 我们希望等到 TSN 网络收敛并保持稳定、然后以锁相的方式自动启动 Genf。  

如果您有任何建议、请告诉我！

谢谢、  
Calvin Manesh

尊敬的 Calvin：

我们在几纳秒内对 CPTS 应用校正时、同时对 Genf 模块应用校正。 因此,与 CPTS 相比,精度会略有下降,但 Genf 将保持同步。 尽管只有一个 SYNC_OUT 引脚可用、但我们可以将一个电路板配置为 Genf_0（对应 sync0_out 引脚）、将另一个电路板配置为 sync0_out 引脚、并验证这两者之间的 SYNC 行为。 它们将表现出与之前相同的行为。

要初始化 SYNC 信号、我们必须实施基于第 2 层的应用来在电路板之间交换信息以识别 SYNC、并发送握手消息来传达一个公共起点、以便所有信号都从同一个点开始。 或者、我们可以使用不同的引导模式将最后一个示例刷写到 OSPI 闪存中、然后将它们一起上电。 这将启动所有连接在一起的电路板。 对于您的当前概念验证、我们可以使用 OSPI 引导模式选项、因为这样做要容易得多。

拨打示例后、您可以在 OSPI 中刷新示例并将其加电。 这将确保示例开始时彼此很近、并且可以将开始时间从 2 分钟缩短到接近 15-20 秒、以便建立同步。 您可以参阅本文档以使用 OSPI 引导模式并刷写到 OSPI 中。： https://software-dl.ti.com/mcu-plus-sdk/esd/AM243X/latest/exports/docs/api_guide_am243x/GETTING_STARTED_FLASH.html

谢谢。此致、
Teja。

谢谢 Teja。

我还有两个与此相关的问题：

1.在 timesync 路由器上进行任何更新以输出一对多映射（如何将 GENF0 路由到 sync0_out 和 CPTS_HW1_PUSH）？

2.为什么 Genf 需要在主设备和从设备之间的 1 秒内启动,而不是 TS 同步? 在 CPSW PTP 示例中、我们可以随时启动主站和从站。 您能否解释一下在这种特定行为上使用 Genf 和 TS SYNC 有什么区别？

谢谢！

尊敬的 Matt：

1. 我们正在审查我们平台上的硬件行为、并从 DM 方面检查以确定根本原因。 我们的测试将于明天结束、并将让您随时了解测试结果
2. 额外的时间是实现锁相。 我们也可以立即开始生成选通信号。 但是、由于我们正在验证平台是否存在抖动、因此我们希望它们具有相位对齐。

谢谢。此致、
Teja。

尊敬的 Teja：

我们刚刚进行了一个实验来测试 ISR 的延迟：在 ISR 开始时将 TEST_LED2 (MCU_GPIO0_5) 设置为高电平、在 ISR 结束时将 TEST_LED2 设置为低电平。

我们观察到 Genf 周期开始之间的时间、TEST_LED2 变为高电平的时间通常约为 4 - 7 微秒。 然而、偶尔这段时间约为 22 微秒。 这将导致我们的应用中出现潜在问题。

这是 ISR：

static void App_cptsEventCb(void *hwPushNotifyCbArg, CpswCpts_HwPush hwPushNum)
{
    GPIO_pinWriteHigh(g_gpioBaseAddr, g_pinNum);
    my_count++;
    GPIO_pinWriteLow(g_gpioBaseAddr, g_pinNum);
}

前排：祖母的天才
第 2 行：从器件的正弦
第 3 行：ISR 中生成的 TEST_LED2 脉冲（在从器件上）
您可以看到左侧的第二个脉冲在从 Genf 启动后大约 22 微秒。


我的理解是从中断上下文调用 CPSW_CPTS_HWPUSH_1 回调。 此外、ISR 中除了 GPIO 切换外几乎没有其他内容。 是否知道导致 22 微秒延迟的原因以及我们如何消除该延迟？


感谢您的帮助！

尊敬的 Matt：

请让我在测试台上运行测试、尝试识别问题。 22 μ s 延迟位于比预期高的一侧。 我假设在导致此问题的周期性任务中执行了一些关键部分。 请允许我重现此问题以作进一步分析。 由于星期五是 TI 印度度假、因此此活动将在星期一上进行。  

谢谢。此致、
Teja。

尊敬的 Matt：

通过以下更改、我能够略微改善 ISR 的行为。

1. 在 Enet 中禁用统计模块。 （如果您对正在接收的数据包的确切计数不感兴趣，则无需执行此操作）
2. 改进 CPTS ISR 事件处理、以缩短从触发到 ISR 的时间。
3. 将应用程序从 DDR 移动到 MSRAM

请使用以下补丁启用 (1) 和 (2)、并将应用程序空间从 DDR 区域移动到 MSRAM 以改善存储器访问问题。 我们发现、大多数时间的范围在 1.5us 到 5us 以内、抖动在 30 分钟内分布在+1.5us 到+15us 以上。  

请告诉我们您的容差范围是多少、我们可以探索其他可能的方法来减少 ISR 计时的差异。 我们还可以微调 Genf 时钟、这样我们就可以使 ISR 处理 Genf 相移、以便更好地与您的收费目标保持一致。  

请告知我们您的测试结果、我们可以据此跟进。

e2e.ti.com/.../ISR_5F00_jitter_5F00_improvement.patch

谢谢。此致、
Teja。

尊敬的 Teja：
当前的 4 - 7 微秒延迟很好。 偶尔会有 22 微秒的延迟、这就是问题所在。 我们需要更一致的延迟。 我认为当前的方法改善了这种情况、但偶尔出现的较大延迟的行为仍然没有变化。 如果您可以帮助确定导致这 22 微秒延迟的原因、并希望有一个解决方案来使延迟更一致（例如 4 - 10 微秒）、那么这将很有帮助。  

您之前提到过这可能是“在定期任务中执行了一些关键部分“造成的。 我想知道是否有其他更高优先级的 ISR 抢占了 CPSW_CPTS_HWPUSH_1 回调？

您能帮助提供一种提供更一致延迟的方法吗？

感谢您的帮助！

尊敬的 Matt：  

您是否也尝试了将存储器位置移动到 MSRAM？ 将 FreeRTOS、Enet 和 TSN 库放置在 MSRAM 中有助于缩短存储器访问时间、从而改善抖动。 我们也在另一个项目中看到了类似的改进。 同时、让我来看看驱动程序是否有任何可能的进一步优化。  

我记得、Enet 驱动程序实现了优化以减少关键部分。 但是、让我检查一下是否有任何其他运行时关键段在驱动程序中占用了更多时间。 考虑到我将要离开一天、这需要一些分析、可能需要 2-3 天的时间。  

如果此时间表与您的 PoC 时间表不一致、请告诉我。 我们可以尝试找到一些中间接地。  

谢谢。此致、
Teja。

尊敬的 Teja：
是的、请帮助确定哪些段导致了偶尔出现的长延迟。 3 天还可以。 这将需要更多的时间,但我认为这是值得的。

我没有尝试将代码放入 MSRAM 中。 您能建议如何操作吗？

我知道这将改善情况。 但我更希望我们了解根本原因、然后相应地加以解决；而不是在不知道确切原因的情况下解决问题。 此外、我更希望尽量减少 TI SDK 的更改。 所以我想把它作为我们的最后手段。

感谢您的帮助！

尊敬的 Teja：

只是想与您核对、是否有任何关于长延迟问题的更新？ 谢谢！

尊敬的 Matt：

我们在将抖动降低到 15us 方面取得了一些进展。 但根据您的要求、这可能不足以满足您的用例。 我在内部 与其他专家进行了检查、并构思了一个新的算法、使用 Genf 作为计时器的源时钟、该计时器将具有更低的软件开销、并且可以独立配置为更高优先级的中断、这有助于结束抖动分布。

我将在周末与您分享详细信息。 如果您想查看当前可用的更改、请告知我。 我可以将它们分享给您进行测试。

谢谢。此致、
Teja。

尊敬的 Teja：

感谢您的更新。 我将在本周结束时等待您的完整解决方案。

现在、您能否详细介绍一下所发现的哪些因素会导致服务中断偶尔出现更长的延迟？

谢谢！

尊敬的 Matt：

您的测试台与我们当前设置之间的主要差异如下：

1. 应用程序放置在 MSRAM 中
2. 大多数运行时打印被抑制
3. CPSW 驱动程序进行了细微优化、以更好地处理触发中断

由于 MSRAM 的访问速度更快、因此将应用程序移至 MSRAM 可改善操作系统级别应用程序的总体延迟和抖动。 在当前应用中、通过 UART 打印基于中断、对其进行抑制极大地减少了抖动的传播、并在运行示例 15 小时以上后明确了抖动的上限。 CPSW 驱动程序优化通过略微优先处理来自 Genf 的触发中断、使抖动的上限略微降低。 最终结果使总展频限制为在触发后 15us。

新方法将中断与 CPSW 完全隔离、并使用由 Genf 输出驱动的专用计时器、从而可以提供更好的中断处理特性。

谢谢。此致、
Teja。

谢谢 Teja。

您是否意味着新方法将 Genf 输出用作中断源（而不是 cpsw_cpts_hwpush）、从而绕过时间同步路由器？ 这一新中断源的优先级高于中断我们当前 cpsw_cpts_hwpush 中断的中断源的优先级？

如果没有、请详细说明和澄清。 谢谢！

尊敬的 Matt：

我们能够实现新方法、其中断优先级高于当前的 CPSW 中断。 因此、我们能够观察到抖动路径的显著改善、展频限制在 5us 以下、同时还包含其余优化。 一旦我们的内部测试完成、我将共享补丁以在您的系统中启用该补丁。

完整测试大约需要 1-2 天。 我可以在一天的时间内分享这个补丁。

谢谢。此致、
Teja。

尊敬的 Teja：

感谢您的说明和更新。 准备好解决方案后、请告诉我。 谢谢！

尊敬的 Teja：

就这一点与您核对、补丁现在的状态是什么？ 谢谢你。

尊敬的 Matt：

以下是用于启用以下功能的补丁：  

1. 基于计时器的 ISR 触发、以获得更好的抖动性能 (< 5us)
2. ISR 之间的锁相

该补丁会禁用进入外部引脚的 SYNC OUT 信号。 若要进行验证、您可能需要使其同步输出、您可以删除基于事件的计时器启动序列、并直接在 timerP_init API 结束时调用计时器启动 API。 这将导致失相锁定、但会确保抖动测量设置正确。

e2e.ti.com/.../tsn_5F00_stack_5F00_remove_5F00_print.patch

e2e.ti.com/.../ISR_5F00_low_5F00_jitter_2800_1_2900_.patch

谢谢。此致、
Teja。

尊敬的 Teja：
关于补丁的几个问题：
1. 我假设补丁与前一个补丁不同、而不是与原始 TI SDK 不同。 这是正确的吗？
2.在 isr_low_jitter (1).patch (enetapp_cpsw.c) 的第 168 行中、 为了将 Genf（同步输出）连接到外部引脚、我们应保留之前的实现方式、而不应用以下 diff、正确吗？ 如果是、这是否也会导致 eventISR () 每 25 微秒被调用一次？

         genFArgs.index = GENF_INDEX_2;
+#if(TIMER_ISR_TRIG_EN)
+//        genFArgs.compare = genFArgs.compare - 1000000000ULL;
+        genFArgs.compare = 0;
+        genFArgs.length = (CPTS_RFTCLK_FREQ_HZ /CONFIG_TIMER0_INPUT_CLK_HZ);
+#endif
+

3. 在 isr_low_jitter (1).patch (tsnapp_cpsw_main.c) 的第 412 行中、 是否需要调用 EnetApp_updatePtpMcastAddress ()？ 如果是、您能解释一下吗？

4. 在 ISR_low_jitter (1).patch (cpsw.c) 的第 456 行中、我在 Cpsw_cptsIsr () 中的源代码与您的源代码不同：

static void Cpsw_cptsIsr(uintptr_t arg)
{
    Cpsw_Handle hCpsw = (Cpsw_Handle)arg;
    EnetMod_Handle hCpts = hCpsw->hCpts;
    Enet_IoctlPrms prms;
    int32_t status;

    ENET_IOCTL_SET_NO_ARGS(&prms);
    status = EnetMod_ioctlFromIsr(hCpts, CPSW_CPTS_IOCTL_HANDLE_INTR, &prms);

    /* TODO: Add ISR safe error:
     * ("Failed to handle CPTS intr: %d\r\n", status); */
    ENET_UNUSED(status);
}

只是为了检查我们是否使用相同版本的 SDK、我的 SDK 目录名称为“mcu_plus_sdk_am64x_11_01_00_17“。
在我的例子中、我是否可以这样注释掉这两行：

    //ENET_IOCTL_SET_NO_ARGS(&prms);
    //status = EnetMod_ioctlFromIsr(hCpts, CPSW_CPTS_IOCTL_HANDLE_INTR, &prms); 

请澄清。 谢谢！

尊敬的 Matt：

是的、这是对的。

在 isr_low_jitter (1).patch (enetapp_cpsw.c) 的第 168 行中、 为了将 Genf (SYNC OUT) 获取到外部引脚、我们应该保留之前的实现方式、而不应用以下 diff、正确吗？ 如果是、这是否也会导致 eventisr() 每 25 微秒调用一次？

您也可以获得包含最新更改的 25us 中断。 您必须更新计时器启动配置和前面提到的其他步骤。

在 isr_low_jitter (1).patch (tsnapp_cpsw_main.c) 的第 412 行中、 是否需要调用 EnetApp_updatePtpMcastAddress ()？ 如果是、您能解释一下吗？

这是为了解决另一个问题、以便处理多个以菊花链方式连接的电路板。 这已在我们的测试中找到、并将在未来的 SDK 中修复。

在 isr_low_ditter (1).patch (cpsw.c) 的第 456 行 中、我在 Cpsw_cptsIsr () 中有不同于您的源代码：

您可以忽略该 diff、并按原样保留 cptsIsr 函数。 您注释的两行是应用程序正常运行所必需的。 请勿对此进行评论。

谢谢。此致、
Teja。

尊敬的 Teja：
我有机会尝试解决方案。 很遗憾、CPSW_CPTS_HWPUSH_1 回调（本例中为 eventISR）未被触发。 TimerP_start() 无法在 Genf 信号开始的确切时间调用。 在 TimerP_init () 结束时调用 TimerP_START () 或其他方法会导致 ISR 无法同步到 Genf 信号上升沿。 这是预料之中的吗？ 如果是、我们如何使 ISR 与 Genf 同步？ 如果没有、我可能错过了什么？

感谢您的帮助！

尊敬的 Matt：

预计不会触发 HWPUSH 事件。 这是在 不同电路板上对齐 ISR 触发器所必需的。 但当在 init 函数中调用 TimerP_START 时、预计不会与 Genf 对齐。 您能否共享当前的应用代码以便我可以验证预期的配置？

我们已经对这方面进行了测试、并证实这项工作正常。

谢谢。此致、
Teja。

尊敬的 Teja：

请参阅 下面的 enetapp_cpsw.c。 我相信这相当于您的补丁。

这样、就会调用 CPSW_CPTS_HWPUSH_1 回调。 但是、没有外部同步信号输出。 此外、会不断调用回调（每 25 微秒？） 尽管我们只需要调用一次它就可以触发 TimerP_start()。

如果我换行 432 和 453、这是我之前的情况、

例如

第 432 行：rmIrqReq.dst_host_irq       = TIMESYNC_OUT_SYNC0_PIN；
第 453 行：rmIrqReq.dst_host_irq       = TIMESYNC_OUT_HW_EVENT0；

那么我有外部同步信号输出、但没有 ISR。

这两种方式都无法满足我们的要求：同时需要同步信号和 ISR。

这里仍然有一些东西。 请提供帮助。

尊敬的 Matt：

借助 CPSW 中的可用资源、我们可以使用应用需要的以下任意两种资源：

1. TS SYNC OUT
2. 驱动外部计时器时钟以生成低抖动 ISR
3. 用于在多个板之间对齐 ISR 的硬件推送事件

如果您同时需要 TS SYNC 和低抖动 ISR、我们需要实现不同的方法来同步 ISR、如果可能、这将需要更多的时间和精力来构建序列。 我想检查一下、系统要求是否同时使用 40kHz 选通（同步输出）和 ISR？  

谢谢。此致、
Teja。

尊敬的 Teja：
是的、正如本主题开头所述、我们希望同时提供这些内容：
由 TSN PTP 计数器驱动的 40kHz 同步输出。
2.与同步输出周期开始相关联的 ISR。

顺便说一下、是否可以提高 CPSW_CPTS_HWPUSH_1 中断优先级来消除这种偶尔出现的长延迟？ 我尝试在 cpsw.c 中的 EnetOSAL_registerIntr () 处对 CPTS 中断执行此操作,但它没有帮助。 我想知道限制是否是由于 HWPUSH_1 与其他 CPSW 中断（包括以太网 TX、Rx 等）共享中断源导致的。 所以我们最终只提高了所有 CPSW 中断的优先级？ 此外、处理这些不同类型 CPSW 中断的软件开销大于简单的计时器中断？

谢谢你。

尊敬的 Matt：

在不增加剩余 CPTS 中断优先级的情况下、无法提高 HWPUSH 中断优先级。 减少此处延迟的主要因素是在正常运行期间 CPTS 模块内触发的并行中断。 除此之外、CPTS HWPUSH 事件的 ISR 处理路由比计时器中断更长、因此会获得更好的性能。  

我们在内部正在讨论获得相位对齐和同步信号的可能性。 我正在按计划测试硬件兼容性测试、以便明天进行检查。 如果这种方法有效,我们可以使用序列和示例代码来支持您。 如果结果变为否定、我们就必须寻找替代方法。

我会让您随时公布结果。

谢谢。此致、
Teja。

您好 Silas、

您提到的问题看起来是频率不匹配与锁相问题。 如果一个电路板的输出看起来在一个方向上不断移动、超过多个波长、则可以证实是频率不匹配、这可能是两个时钟不同步的根本原因。

集成上述补丁后、我们就能够同时实现频锁和相锁。 即使只对库进行更改、我们也能够确认是否实现了频锁。  

您能否请确保清理库并再次构建它们、以便库中所做的更改生效？ 如果未重建库、则不会反映源代码。 请告知我们您的调查结果。

谢谢。此致、
Teja。

尊敬的 Matt：

我对我们的方法进行了健全性检查、我们无法实现预期的行为。 让我与我们的系统专家确认这一点、并向您介绍这种做法的可行性。  

为了获得更多背景信息、这两个信号是否存在任何可接受的异相范围？  

谢谢。此致、
Teja。

嗨、Teja、  

只是想后退一步、再次定义我们的目标、以便我们朝着相同的目标努力。  

对于每个 TSN 节点、对于主从节点、我们都希望有两个信号：硬件发生器信号和内部中断。 目标是使主 Genf 信号和从 Genf 信号之间的总差值为 50ns。 这意味着网络上所有节点的任何相位偏移+抖动+延迟不应超过 50ns。  

在您的帮助下、我们能够实现这一目标。 现在、我们需要解决的问题是中断延迟。 请记住、我们需要一个 HW Genf 信号来向网络上的硬件器件发出选通信号。 我们需要一种方法来确保软件知道该信号在信号发出后立即发出。 这就是我们试图对 SW ISR 执行的操作。 基本上、当硬件事件发生时、软件需要开始为下一个事件加载寄存器。  

由于中断将由软件（而不是硬件）处理、因此我们知道这个 ISR 的延迟变化会多一些。 只要 ISR 延迟受合理范围（例如 3 - 10 微秒）的限制、这对我们来说是可以接受的。 目前、我们看到 最坏情况下的 ISR 信号将 Genf 信号滞后约 20 微秒。 在 40kHz 信号（25 微秒）下、这只剩下 5 微秒。 这种巨大的变化不会给我们足够的时间来进行下一次扫描的软件服务,我们基本上会错过一个事件周期。

我们想考虑几点

1. 是否可以使用 Genf 外部输出 (PIN_ECAP0_IN_APWM_OUT) 作为中断源、以在 ISR 和 Genf 之间创建更有界的偏移？
2. 如果没有其他方法、我们能否研究将核心作为轮询循环运行的性能、以便坐在那里观看 Genf 信号、并在该核心上创建最高优先级的中断、以确保我们不会与任何其他进程竞争？

谢谢、  

Calavin Manesh

尊敬的 Calvin：

如果您愿意使用由选通信号本身驱动的外部 GPIO 触发器生成 ISR、我想我们可以这样做。 让我与我们的团队核实、并向您回复最新信息。

我认为我们不需要有专用的 R5 来处理 ISR。 我们应该能够在单个内核中处理它。 在结束时运行设置后、我将与您分享相关代码和结果。

谢谢。此致、
Teja。

您好 Silas、

我们可以使用可用的 API 来处理您的用例、同时保持清晰的恢复特性。 我们需要将触发器从 cpsw_handlelinkup 传递到应用程序上下文、以重新配置 Genf 信号。 借助这种机制、我们不会根据每个电路板的时间开始来设置 Genf 启动时间、而是可以基于链路建立来启动、这将提供更多使相位对齐正确的机会。 但这意味着、我们将有更长的时间从链路断开恢复到生成 Genf。

对于您的用例、Genf 仍然是理想选择、因为 TS_SYNC 在 3.745kHz 的频率下达到最大值。 因此、我们无法 从 TS_SYNC 实现 125µs 信号。

如果您有任何其他疑问、请告知我们。

谢谢。此致、
Teja。

尊敬的 Teja：

是的、正如我之前解释的、虽然当前的解决方案在大多数情况下提供的延迟很低、但问题是最坏情况下 20 微秒延迟的这种非确定行为。 这样、我们就只需 5 微秒（选通周期的 20%）的时间来处理数据。

如果选通信号驱动的 ISR 提供稍高但确定性的延迟（例如最坏情况 7 - 10 微秒）、那么这适用于我们的应用。 这保证了我们至少有 15 微秒的时间进行处理。

谢谢你。