[参考译文] CCS/CC1310：目标和#39的配方；../src/sysbios/sysbios.aem3和#39；失败

您好 Jan、

您使用的 XDC 工具、SDK 和 CCS 版本是否与以前相同？ 如果不是、我将首先重新创建与项目以前运行的环境相同的环境。

如果工作环境与以前相同、我将确保主工程指向正确的 TI RTOS 工程作为依赖项。 这可以通过右键单击“属性”->“生成”->“依赖项”来完成。

如果这也是正确的、下一步应该是在 ti-RTOS 工程中导入一个新副本并重新编译。

我希望这对您有所帮助、
AB

谢谢你。 原始帖子正在回复中、请参阅 ：e2e.ti.com/.../2485031。

>您使用的 XDC 工具、SDK 和 CCS 版本是否与以前相同？

原则上是的，因为原始项目安装了最新版本。 但这显然并不意味着工程正在使用它们、因为它在新 PC 上打开时尝试使用不存在的 xdctools_3_50_03_33_core。 因此、根据我的理解、它随后尝试使用3_50_04_43_core。 奇怪的是、我们不允许将其修改为3_50_04_43_core (不尝试 xdctools_3_50_03_33_core)。 它会不断恢复。 只有在设置为 xdctools_3_32_00_06_core、然后返回到3_50_04_43_core 后、设置才会继续。

稍后我将按照您的说明进行操作、因为我必须完成整个过程：更新原始项目、发现涉及的机密、提交、签出、新建工作区、导入。 我喜欢生活的所有东西都没有，这很容易产生新的诗篇。

在给定上述图像的情况下、您是否无法说出 IDE 是如何失败的？ 这样、我就可以了解失败的原因(如果不是错误)。

--


我敢打赌、如果您能访问我的机器、这是一个很容易解决的错误。 即将到2020年：为什么 IDE 不下载并重新创建其依赖项？ 如果它无论如何都必须造成问题、为什么没有用于检查不一致性并解决它们的工具？ 如果我们必须有一个论坛、为什么没有一个收集信息支持需求的工具、以便它能够正确分析情况并提供补丁？ 最后、它将有一个增补程序工具箱、我将能够运行它们。

我在这里看到(并且参与了)一个谬论：你用我作为一个与系统的最不可靠的接口、你可以使用代码以一种精确可靠的方式对系统进行评估。 似乎有恶意想用我代替...？？ 支持人员似乎没有意识到应该向计算机说出这些内容、这是我的要求。 如果确实如此，很容易：它获得它想要的信息，然后它可以发出它想要的行动，请我应用它们。 问题已解决、案例已关闭、已学习课程。 从问题发生到解决、90%的案例中最多花费3分钟。 我可以继续工作。

为什么事情如此艰难？ 为什么坚持以错误的方式行事？ 这是你的工作吗？ 如果您编写了代码，则一定要确定并描述问题。 它还可以生成出色的错误报告。

好的、谢谢。