[参考译文] CCS/PROCESSOR-SDK-AM335X：另一个开箱即用故障

尊敬的 Chris：

我在 PRSDK 文档 中看到了这一点：http://processors.wiki.ti.com/index.php/SYS/BIOS_with_GCC_(CortexA)#What_do_I_need_to_do_to_make_the_C_runtime_library_re-entrant_when_building_SYS.2FBIOS_applications_for_Cortex-A_GNU_targets.C2.A0.3F

我还看到了 E2E 主题 ：https://e2e.ti.com/support/processors/f/791/t/640006?RTOS-SYSBIOS-GNU-linker-error-with-SYSBIOS-v06-52-00-12

我注意到 SYSBIOS 6.83.00.18依赖于 XDCTools 3.61.03。 但是、我找不到此 XDCTools 版本的公共位置： http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/rtsc/index.html

6.83.00.18之前的 SYSBIOS 版本是6.82.01.19。 此版本可从上面的链接下载、相关的 XDCTools 版本3.61.0.16位于 CCS 10安装中。

我尝试使用 SYSBIOS 6.82.01.19和 XDCTools 3.61.0.16创建 SYSBIOS"典型"示例。 但是、我看到同样的构建问题：

C：/ti/bios_6_82_01_19/packages/ti/sysbios/rts/gnu/ReentSupport.c：84：未`对 ti_sysbios_rts_GNU_ReentSupport_checkIfCorrectLibrary'的引用

我按照上述 docs/e2e 线程中的说明操作、但仍然看到相同的构建错误。  检查 SYSBIOS 安装、我注意到没有文件夹 \packages/GNU\Targets\arm\libs\install-native\arm-none-eabi\lib\hard。 对我来说、这表明所需的库未包含在安装包中。

我能够使用 PRSDK 6.3随附的 SYSBIOS 和 XDCTools 版本在 CCS 10中获取 SysBIOS"典型"示例编译。 我建议您使用这些版本、因为它们已作为 PRSDK 版本的一部分进行了测试。

此致、
弗兰克

好的、我按照描述安装了软件包、因为没有在任何搜索引擎上找到该页面、只有显示这些软件包的最新版本的页面。

"开箱即用"故障仍然存在：

嗯、我没有较新版本的 Java。  这是先决条件吗？  是否应该在某处解释过？  软件包安装程序是否已检测到并中止或提示用户？

奇怪的是、它实际上会构建一个项目。  但 XGCONG 窗口不会打开。

无论我打开什么"控制台"、我找不到任何位置都没有定义"XDCTOOLS_Java_HOME"。  因此、这是一个我无法控制的环境变量。  在控制其使用的 Java 版本的 IDE 中，我找不到任何设置。

(CCS7现在只能使用"种类"的工作。  它一直为我提供空白屏幕...  我本来想抱怨 CCS 10损坏了其中的一些项目，直到我做出神奇的发现，如果您重新调整窗口大小(强制重新喷漆)，它将显示屏幕)

我是否应该直接访问 Oracle 并安装其 Java，以及所有间谍软件、广告和浏览器附加项？   或者是否应该使用现有版本 (jre6)？  或者 TI 是否有推荐/定制版本？

弗兰克、

星期一快乐！ 将其打开并运行。  XCONF 图形屏幕现在可以工作，我没有安装任何新 Java，等等。  它刚刚 开始自己工作。

非常烦人……

此外、我已经越过了安装软件包步骤。

我无法理解的是：

当项目未选择 SYSBIOS 产品时、它如何添加"C：\ti\BIOS_6_46_05_55"路径？

嗯、您对的解释  

• 选择窗口->首选项
• 选择 Code Composer Studio -> Build -> Variables
• 单击"Show System Variables"(显示系统变量)
• 双击"BIOS_CG_ROOT"

虽然双击对话框中的列表显示"ecLPISE_DYNAMIC_variable"、但它会显示实际路径。

似乎表示 CCS 始终将此用作默认搜索路径、无论您如何操作(除非您执行从不同的软件包添加 SYSBIOS 的步骤来覆盖它)。

现在... 又一个烦恼！！！！  当我告诉它在"c"文件上"构建所选文件"时、为什么编译*。S 文件？   

为什么即使我选择"S"文件并将其标记为“从编译中排除”，它也会这样做？？

Chris、

[引用用户="Christopher Weber"]

现在... 又一个烦恼！！！！  当我告诉它在"c"文件上"构建所选文件"时、为什么编译*。S 文件？   

为什么即使我选择"S"文件并将其标记为“从编译中排除”，它也会这样做？？

[/报价]

我不确定。 您能否打开此主题的新主题？

谢谢、此致、
弗兰克

弗兰克、

我是这样做的。  此处：

e2e.ti.com/.../956849

它具有屏幕截图的链接、显示我可以让它忽略第一个 S 文件、确实如此。

但是、如果我让它忽略第二个 S 文件、它不会。

和... (有人在那里放置了# include -不是我)汇编器尝试编译 XDC "C"代码、并生成了上千行或错误... 这是预期的。   

但这一切都从窗口滚下来了。  因此、我花了几天的时间尝试找出这些误差的来源。  因为错误都是由 XDC 源文件造成的。

如果窗口保持足够的时间、或者刚刚将其记录到一个文件中、我可以在事后打开、我可以看到原始命令行、而不是花几天的时间尝试确定哪个源文件是原因。

尊敬的 Chris：

[引用 user="Christopher Weber"]如果窗口保持足够的时间，或者只是将其记录到一个文件中，那么我可以在事后打开，我可以看到原始命令行，而不是花几天时间尝试确定哪个源文件是原因。

我认为没有方法可以将编译输出重定向到文件。 我只能看到"复制"和"滚动锁定"功能。  这个 e2e 线程中讨论了这个问题： https://e2e.ti.com/support/tools/ccs/f/81/t/87023

一种可能的权变措施是从命令行编译 CCS 工程、并将编译输出重定向到文件。 请查看： http://software-dl.ti.com/ccs/esd/documents/ccs_projects-command-line.html

此致、
弗兰克

弗兰克、

另一个...  (我是否要提出问题？)

当我挖掘并查看 GNU 编译器时、我猜 TI 已经放弃了这个东西中的"SYS_BIOS_path"、现在有一个$｛COM_TI_BIOS_include_path｝。

猜猜猜会怎么样...？ 它是空的。 不仅仅是"尚未填充"、它实际上是空的。 而不是在您描述的首选项中的任何位置定义。

给定以下一组内容：

$｛COM_TI_BIOS_include_path｝
$｛PROJECT_ROOT｝
$｛CG_TOOL_INCLUDE_PATH｝
$｛PROJECT_ROOT｝/ti 

(是的、项目中有一个"TI"文件夹)我的构建命令如下：

C：/ti/gcc-arm-none-eabi-7-2018-q2-update/bin/arm-none-eabi-gcc-7.3.1.exe
-c
-mcpu=cortex-A8
-March =armv7-a
-mtun=cortex-A8
-marm
-mfloat-abi=hard
-i"C：/Source/projects/DnsTest
-i"C：/ti/gcc-arm-none-eabi-7-2018-q2-update/arm-none-eabi/include
-i"C：/Source/projects/DnsTest/ti 

这会从整个命令行中截断、但请注意、列出了4个目录、但命令行有3个目录。 第一个：$｛COM_TI_BIOS_include_path｝甚至未列出。

接下来、我创建了一个快速测试项目、其中包括：

$｛COM_TI_BIOS_include_path｝
$｛PROJECT_ROOT｝
$｛XDC_FIND：GNU/目标/ARM/libs/install-native/arm-no-eabi/include/newlib-nano：$｛ProjName｝｝
$｛XDC_find：ti/posix/gcc：$｛ProjName｝｝$
｛Proj_path｝工具 

真不知道｛XDC_FIND…… ？？

显然、调用的是某种搜索、但会发生什么情况？ 是否在某处记录？ 以及为什么在其后面附加项目名称？

有什么想法吗？

切斯特...  哇哦。

这将很有用。   您是对的、另一种不明显的隐藏行为。

我有一条"global-build.log"的38、000行！  我想知道何时清除它？

尊敬的 Chris：

[引用用户="Christopher Weber">另一个...  (我是否要提出问题？)

是的、我将为这些问题打开一个单独的主题。 这是：

1. 将来、问题与解答的其他人可以更轻松地找到问题与解答
2. 为该线程分配了正确的"专家"。

我现在要关闭这个线程。

此致、
弗兰克

切斯特、

非常感谢非常有用的信息。

此致、
弗兰克