[参考译文] TDA4VP-Q1：XDS560v2 PRO TRACE 接收器和放大器；调试探针支持

纠错、我们拥有的硬件器件是 XDS 110-U、而不是 XDS560v2 PRO

您好 Alan Longardener、

在 CCS 中捕获内核跟踪的步骤

• 将引导模式配置为无引导模式。
• 使用以下命令启动初始化脚本：
  js：> loadJSFile (/home/sivadeepr/Documents/psdk_rtos/ti-processor-sdk-rtos-j784s4-evm-11_01_01_01/pdk_j784s4_11_01_00_17/packages/ti/drv/sciclient/tools/ccsLoadDmsc/j784s4/launch.js)
• 在 Debug 视图中、右键点击所需的 C7x 内核、然后选择 Connect Target。
• 将可执行文件加载到所选的 C7x 内核中。
• 从菜单栏中、导航至：
  Tools→Code Analysis→Core Trace、然后根据需要配置跟踪设置。
• 运行 C7x 内核。
• 执行完成后、暂停内核、然后停止从“Core Trace“窗口中进行跟踪捕获、以分析收集的跟踪数据。
• 

此致、

Ben

在姊妹线程 (  TDA4VP-Q1：[CEER] C7x 优先级处理 — JTAG 调试器 — 将关闭该线程并指向此线程）上添加 Shabary  的响应：

尊敬的 Ross：

Ross S.说：

我们需要确定 c7x 在有负载时没有及时响应高优先级请求的原因 

应该具有低优先级。

客户是否会同时在内核上运行任何 TIDL 推理？ 是否有任何其他任务同时处于活动状态？ 这一点很重要、因为 TIDL 可能会故意调用 Hwi_disable() 较长的处理块以防止中断。

此致、
Shabary S Sundar

你好。

我们已确定问题的根源。
它是 TIDL 的中断禁用、实际上在默认情况下 TIDL 会在整个操作期间禁用中断。

我们发现、如果 TIDL 配置 为 maxPreEmpptDelay 设置为 0、则问题会消失（高优先级负载会在截止日期内调度，因此所有内容都将按中的方式进行处理，FPS 返回到 30）。

我们想问 TI、为什么 TIDL 在默认情况下会禁用中断、以及是否可以安全地将 maxPreEmpptDelay 设置为 0。

感谢您为我们指向 TIDL 抢占示例：
github.com/.../preemption_example

我们已经过审核、它符合我们的观察结果。 特别是在 maxPreEmptDelay = FLT_MAX （‑）模式下、TIDL 可以将占先推迟到优化的网络点、从而产生较长的不可抢占执行窗口、同时 maxPreEmptDelay = 0 允许在层边界立即占先并恢复 C7x 响应能力。

这说明了为什么我们看到默认配置下从所需的 30 FPS 下降到~15 FPS、以及为什么设置 maxPreEmptDelay = 0 会恢复 30 FPS。

我们剩下的问题是混合工作负载支持的使用问题。 该示例‑在 TIDL‑之间实现抢占、而我们的系统与其他延迟敏感型非 2 μ s TIDL 工作负载共享 C7x。

我们使用 C7x 作为通用 DSP、以便快速对帧缓冲区运行操作。 操作本身需要大约 600 微秒、但必须以低延迟执行 、否则其他位置的处理无法满足实时要求。

‑、C7x‑‑脉冲‑是非 4 μ W TIDL、延迟 Δ T 敏感型工作负载共享同一个 C7x 内核的另一个示例、并且可能会在计算机视觉流水线中的其他地方增加具有类似延迟要求的非 3 μ W TIDL 级。

尊敬的 Dale、Nikita、

将此主题重新分配给相应的主题专家以获得进一步帮助。

此致、

Ben

是否有任何更新？

尊敬的 Devin：

很抱歉、此主题有任何待处理的问题？  

此致、

Brijesh

您好、Brijesh、

是的、  ‑在会议上讨论的一个问题、您在其中确认了在与非 Δ Σ TIDL 共享的 C7x 上运行 TIDL、延迟 Δ‑敏感型工作负载被 TI 视为一种预期且受支持的架构。

特别是、 我们正在寻求确认、该 TI 框架本身就支持 TIDL 与非 TIDL 任务之间的 L2 SRAM 同步和共享。   maxPreEmpptDelay 独立于此同步机制。

此致、

Devin

尊敬的 Devin：

我们正在下面的主题中讨论这个问题、因此我们能否关闭此主题、仅在下面的主题中讨论？  

(+) TDA4VP-Q1：由于 TIDL 抢占和中断处理而导致的 C7x 调度性能下降 — Aptiv Jacinto 论坛 — APTIV - EP 汽车 — TI E2E 支持论坛

此致、

Brijesh

并非所有对该主题感兴趣的人都可以访问私人 E2E

尊敬的 Devin：

当然、  

关于这个问题、如果 我理解正确、 非 TIDL 任务本质上是在 FreeRTOS 或 SAFERTOS 上运行的任务。 因此、除非该 RTOS 提供 L2 一致性（我认为这样做并不可取）、否则非 TIDL 任务不会与 TIDL 任务进行 L2 一致性、不是吗？  

当 TIDL 任务因其他高优先级任务而被抢占和切换时、TIDL 将保存上下文（这需要 TIDL 团队进行确认，我会检查是否存在）。 但是、当非 TIDL 任务因更高优先级的任务而被抢占和切换时、很可能的非 TIDL 需要保存自己的上下文、并在重新切换回上下文时将其恢复。  

有一个问题是、更高优先级的非 TIDL 任务是否可以被抢占？ 还是始终在不抢占的情况下运行至完成状态？   

此致、

Brijesh

非 μ‑TIDL 工作负载是在 C7x 上运行的标准 FreeRTOS/SafeRTOS 任务。 我们没有假设 RTOS 提供 L2 一致性、并且我们当前没有在应用程序级别执行任何显式 L2 SRAM 分区或一致性管理。 ‑向‑澄清的一个问题是、当 TIDL 与非 I ² C TIDL 任务共用一个 C7x 内核时、是否需要任何 L2 级约束或管理。

在占先‑：预计 TIDL 会被一个更高的 2 μ s 优先级任务抢占。

是否可以抢占更高优先级的非 TIDL 任务？

感谢您确认非 μ‑TIDL 任务上下文处理。 澄清一下、根据任务上下文、我们指的是 CPU/DSP 执行状态（寄存器，栈等）、它不同于 L2 SRAM 数据正确性。 ‑这一区别、关于在 TIDL 与非 I ² C TIDL 任务共享 C7x 内核时是否需要显式 L2 SRAM 分区或同步、还有一个待处理的问题是这样吗？

尊敬的 Devin：

我已经回答了另一个问题。  

此致、

Brijesh