This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[参考译文] 编译器/TMS320C5504:无法在 Code Composer 10上为 TMS320C55x 生成有效的 A00文件。

Guru**** 2533840 points
Other Parts Discussed in Thread: OMAP5912

请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/tools/code-composer-studio-group/ccs/f/code-composer-studio-forum/907055/compiler-tms320c5504-unable-to-produce-working-a00-file-for-tms320c55x-on-code-composer-10

器件型号:TMS320C5504
Thread 中讨论的其他器件:OMAP5912

工具/软件:TI C/C++编译器

我们正在尝试将以前在 Code Composer v3.3上构建的工程迁移到 Code Composer v10.0上构建的工程。 该项目生成一个 A00 ASCII 十六进制文件、该文件被放置在 OMAP5912上的 TMS320C55x DSP 中。 该工程使用 TI 提供的 C5500代码生成工具3.3.2成功编译、但会生成一个与 Code Composer v3.3上生成的二进制文件不同的二进制文件。 此外、最重要的是、这种新生成的二进制文件无法在 DSP 上运行。

我们从 Code Composer v3.3安装中复制了 C5500编译器工具、并在使用 C5500代码生成工具3.3.2时在 Code Composer v10.0上生成了相同的结果。 因此、我们认为这 排除了编译器工具作为问题的根源。

目前、Code Composer v.10.0.10项目使用 XDAIS v6.24.1.6、而 Code Composer v3.3项目使用 XDAIS v2.24.x (我不记得次要版本、但如果有用、我可以获得)。 XDAIS 版本差异是否是我们遇到的二进制生成问题的根源? 在 Code Composer v10.0中生成 A00二进制文件时、还有哪些其他工具(如果有)发挥作用?

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    我不清楚这两者之间的区别,但失败了...

    [引用 user="Levi Amens"]该项目确实使用 TI 提供的 C5500代码生成工具3.3.2成功编译了 Code Composer v10.0,但该项目生成的二进制文件与 Code Composer v3.3生成的二进制文件不同。

    这起作用...

    [引用 user="Levi Ameina">我们从 Code Composer v3.3安装中复制了 C5500编译器工具,并在 Code Composer v10.0上生成了相同的结果,即使用 C5500代码生成工具3.3.2时。 [/报价]

    在这两种情况下、都使用 CCSv10.0和编译器工具版本3.3.2。  但您会得到不同的结果。  还有什么不同?

    谢谢、此致、

    乔治

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    [引用用户="George mock"]

    在这两种情况下、都使用 CCSv10.0和编译器工具版本3.3.2。  但您会得到不同的结果。  还有什么不同?

    谢谢、此致、

    [/报价]

    也许我的措辞不好。 在这两种情况下、CCSv10.0产生完全相同的结果(二进制)、没有不同、这就是我们认为编译器工具不是问题的原因。 但是、从 CCSv10.0生成的二进制文件与 CCSv3.3生成的二进制文件不同。 CCSv3.3生成的二进制文件有效、CCSv10.0生成的二进制文件无效。

    正如我的帖子中所述、我们在设置之间发现的一个差异是 CCSv10.0使用 XDAIS v6.24.1.6、而 CCSv3.3使用 XDAIS v2.24.x 不过、我们不确定 XDAIS 版本的差异是否是影响因素。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、Levi、

    您是否正在使用 DSP/BIOS? 如果是、是哪个版本?

    Todd

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    [引用 user="ToddMullanix"]

    您是否正在使用 DSP/BIOS? 如果是、是哪个版本?

    [/报价]

    不、我们不是。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    作为测试、我们从项目和 CCSv10.0中完全删除了 XDAIS。 有趣的是、该项目仍然构建良好、没有额外的错误或警告、因此 XDAIS 既不是依赖项、也不是问题。

    我深入研究了正在生成的.map 文件、我注意到了一些有趣的东西...

    左半部分是从 CCSv10.0编译生成的.map 文件、右侧是从 CCSv3.3生成的.map 文件。

    rts55x 库对象(特别是 boot.obj)的放置以及_c_init00符号中的相应差异对我来说很重要。 因此、我更改了链接器配置、在  ${inputs}模式之前添加了--library=rts55x.lib 并在 CCSv10.0中重建了项目。 生成的映射文件与 CCSv3.3生成的映射文件匹配、生成的.A00文件在 TMS320C55x 上成功运行。
    我将承认、我不太确定为什么更改链接顺序、因此 rts55x.lib 中的 boot.obj 在存储器地址0x00010000处设置解决了我们的问题。
    我接下来将尝试使用较新的编译器版本 v4.4.1、并查看该二进制文件是否仍在 DSP 上运行。 将报告反馈结果。