[参考译文] AWR2243：用于 MMWCAS-RF-EVM 更换的兼容 DSP 板列表

尊敬的 Sakshi：

要替换与 MMWCAS-RF-EVM 配合使用的 EOL MMWCAS-DSP-EVM、您需要符合以下要求的设备：

• 4 个 CSI2 RX 实例
• 4 个 SPI 接口
• 足够的 GPIO 用于配置
• 能够处理信号的处理器（例如 C75）

• TDA4AEN (J722S) 处理器
• AWR2243CAS_TDA4_ADAPTER（专为此连接设计的适配器板）

尊敬的 Amar：

感谢您提供兼容板的列表。 在我们开始采购之前、我需要找出导致当前问题的根本原因、从而确保我们不仅仅是再次遇到同一个问题。

我有两组主要的问题：

1、当前硬件的根本原因和恢复是否确实没有让我们当前的硬件工作的余地? 此设置之前没有出现问题地执行了 400 多个连续循环、但现在已经降级为间歇性故障（有时早在环路 2 中）。

• 它是怎么“坏“的?  什么软件或固件状态会导致以前稳定的脚本突然触发“帧周期响应“超时？

• 为什么它停止运行？ 我们尝试将环路间延迟增加至 7s 但没有成功。 如果 TDA 挂起在 ARM 命令上、我们是否可以使用特定的低级重置或缓存清除过程将主板恢复到原始性能？

2.建议的 TDA 更换的可靠性您正在推荐另一种基于 TDA 的硬件解决方案来替代我们当前的 EOL 板。

• 预防复发:我们如何能够确定新的 TDA 板不会走同样的道路? 如果“帧周期“超时是已知的体系结构限制或 TDA 捕获固件中的错误、则硬件更换可能只是临时修复。

我们需要了解我们是否要处理硬件磨损问题、或者 TDA 集成中的基本稳定性缺陷、然后才再次承诺使用相同的架构。

提前感谢、

Sakshi

尊敬的 Sakshi：

按以下顺序解决您的问题：
1.根本原因和当前设置的恢复
一个可能的解释是、捕获脚本依赖于在循环运行之间隐式清除 TDA 捕获状态、而不是显式停止捕获会话。 早期运行可能已成功、因为内部清理操作（SSD 文件关闭，缓冲区释放和状态重置）在可用的时序裕度内完成。 随着时间的推移、系统条件的变化（如文件系统延迟或热效应）可能会增加清理延迟、从而导致在 TDA 完全准备就绪之前发出后续捕获启动命令。 这可能会导致观察到的“捕获卡超时的帧周期响应“行为。
根据我们的经验、这种行为通常与时序和状态相关、而不是硬件永久性降级。 但是、由于 TDA2 上的调试可见性有限、这仍然是合理的解释、而不是已确认的根本原因。

2.推荐的基于 TDA4 的解决方案的可靠性
虽然我们目前没有 TI.com 上公开发布的适用于 TDA4 的雷达信号链 SDK、但我们已使用 AWR2243 在内部验证了基于 TDA4 的信号链、并且尚未观察到传统设置中出现的间歇性捕获行为。 TDA4 解决方案受益于改进的系统架构、并且在遵循正确的捕获开始/停止时序时、预计不会出现与状态相关的相同限制。
公共 SDK 推出后、我们将能够就长期可靠性和最佳实践提供更具体的指导。