[参考译文] 编译器/MSP430F2618：错误#10099-D：程序将不能放入可用内存中、段&quot；.cinit 和 quot 的对齐位置失败。 将编译器从 TI v4.0.0 B1更改为 TI16.9.3.LTS 后

[引用 user="Rishit Borad"]当我使用较旧的编译器(v4.0.0.B1)并且在将编译器(更改为 v6.9.3.LTS)[/quot]时，该操作正常。

这些编译器版本相隔6年。  编译器版本和链接器命令文件(名为 lnk_msp430f2618.cmd 的文件)之间存在相关性。  我们努力使它们尽可能独立。  但6年的时间有点长。  您遇到问题并不奇怪。

最好的选择是升级整个 Code Composer Studio 环境。  这会升级编译器和链接器命令文件、并且工作的可能性大大提高。  这对您来说是否实用？

谢谢、此致、

乔治

感谢乔治的答复。

我已将 CCS V5更改为 CCSv7.2.0。 当我将我在 CCS v5中使用的项目导入到 CCS v7xx 时、它附带了旧的.cmd 文件。 是否有方法可以生成/使用.cmd 文件并根据我的需求进行更改？ 或者、我能否从实际授予的 TI 示例项目中复制它？

请告诉我、这是否不是您提出的建议。

此外、编译器 V4.0.0的输出格式为 COFF、而 V16.9.3的 ELF 的输出格式为 COFF。 它是否改变了整个系统的工作方式？ 我现在正试图弄清这一点、希望我能找到一些东西。

谢谢、此致、
Rishit

CCSv7附带一些默认链接器命令文件。 它们可在 CCS 安装程序的\ccsv7\ccs_base\msp430\include 目录中找到。 您可以找到适合您所使用的特定器件的器件、将其复制到您的项目中并根据您的需求进行定制。

[引用 user="Rishit Borad">此外，编译器 V4.0.0的输出格式为 COFF，而 V16.9.3的输出格式为 ELF。 它是否改变了整个系统的工作方式？

从 COFF 迁移到 ELF 时、需要考虑一些因素。 此 wiki 页面 介绍了迁移详细信息。 该页面是为 C6000器件编写的、因此并非所有方面都与 MSP430相关、但所有主要概念也将适用于 MSP430。

您可能已经意识到、CCSv7.2 (16.9.3.LTS)中的编译器版本不支持 COFF。 支持的 COFF 的最新版本为4.4.x 理想的长期解决方案是让您的项目使用最新的编译器/ELF。 但是、如果您处于短期紧缩状态、则可以在 CCS 7.2中安装和使用编译器版本4.4.x。 要进行安装，请按照 本节中的步骤操作 ，然后选择最新的4.4.8版。 然后、您可以将项目设置为使用版本4.4.8进行编译。  

Aarti 您好！

感谢您的回复。

AarticG 说：

CCSv7附带一些默认链接器命令文件。 它们可在 CCS 安装程序的\ccsv7\ccs_base\msp430\include 目录中找到。 您可以找到适合您所使用的特定器件的器件、将其复制到您的项目中并根据您的需求进行定制。

这真的很有帮助、除了下面的警告之外、我还能摆脱警告：  

系统无法找到指定的路径。
srec_cat：.\CSAC_CC4.txt：3954：警告：为 CRC 计算提供的数据
至少有一个空穴。 这很糟糕。 这意味着内存中
您的嵌入式系统执行的计算将与不同
计算。 强烈建议您使用--fill 0xFF
过滤*Before *此 CRC 过滤，以确保两个计算都使用
相同的字节值。 有关如何查看孔洞的信息、请参阅 srec_info (1)。 

wiki 页面显示"COFF 向符号名称添加了前导下划线、但 EABI 不会添加。 对符号的汇编文件引用需要特殊处理。"。

(正如我在最初的问题中提到的)当我使用最新的编译器 v16.9.3 LTS 并在  链接器命令文件中编辑".cinit：{}> FLASH | FLASH2"时，它可以编译，但会在应用程序代码在运行时开始之前中断。  

实际上、我的 BSL 会跳转至 ISR31()、其中写入符号"_c_init00"以启动固件。 由于 ELF 格式没有下划线、BSL 可能无法找到该符号(我正在假设)和中断。 我还观察到、当输出格式为 ELF 时、编译器 V4.4.8和 V16.9.3 LTS 中存在原始问题。 当输出格式为 COFF 时、在编译器 V4.0.0 B1和 v4.4.8中都可以编译。  

是否有方法可以更改 ISR31()中的符号？

我的最终目标是提供双精度浮点支持、编译器 V16.9.3 LTS 提供该支持。 将编译器更改为 V4.4.8将没有帮助。  

如果您能为我提供有关此方面的任何信息、我将不胜感激。

此致、

Rishit

 

它是_c_int00、只有一个"i"。 此名称是常规规则的例外情况、即 COFF 名称具有额外的下划线、而 EABI 名称不具有；符号_c_int00在 COFF 和 EABI 中具有相同的链接名称。 如果您的程序无误地链接、则 EABI 查找符号_c_int00时不会出现问题；这肯定是其他问题。

[引用 user="Rishit Borad"](正如我在原始问题中提到的)当我使用最新的编译器 v16.9.3 LTS 并在  链接器命令文件中编辑".cinit：{}> FLASH | FLASH2"时，编译良好，但会在应用程序代码在运行时开始之前中断。  [/报价]

我不确定您是否已经解决了这个问题、但我想提一下刚刚想到的另一件事。 在初始化例程期间、看门狗是否可能会触发并复位器件？ 如果有大量变量需要初始化、从而导致初始化代码运行时间更长、则会发生这种情况。 这种情况的症状是无法成功到达 main()函数。

我提到这一点是因为这最初是一个 COFF 项目、它是使用非常旧的编译器版本创建的。 使用 COFF 时、未初始化的变量不会自动初始化为零(这由用户自行完成)、但是在 ELF 中、变量会由工具自动初始化、这可能会增加启动时间。

使用较新的编译器工具、可以选择在自动初始化期间保持看门狗计时器。 请参阅此 常见问题解答主题 、并确保在您的项目中启用此选项。

Aarti、

感谢您的回复。

由于时间限制、我推迟了对编译器的更改、并使用浮点双精度解决了旧版编译器上的问题。

但是、在您在这里回答后、我打开了我的项目以检查您所讨论的选项的状态、它确实编译正确、无需进行任何其他更改、并且可以在不中断的情况下运行。 事实上、当我上周关闭此项目时、在从您之前的回答中了解到您的建议后、我对.cmd 文件进行了一些更改："CCSv7附带了一些默认的链接器命令文件。 它们可在 CCS 安装程序的\ccsv7\ccs_base\msp430\include 目录中找到。 您可以找到适合您所使用的特定器件的器件、将其复制到您的项目中并根据您的需求进行定制。" 它是为我编译的。 但是现在、我似乎对 PostBuild 文件有一些问题、因为在运行时、我的板不会对我在编译之前在项目中进行的任何更新做出反应。 由于我的时间越来越短、我将推动这项工作一周、但我肯定需要在不久的将来将我的系统移至新的工具链。 我将在一周左右的时间内向您提供更多信息。

[报价用户="Aarticg"]请参阅 此常见问题解答主题 ，并确保在项目中启用此选项。

此选项已为我启用、但您提供的信息很好了解。  

此外、我非常感谢您花时间。

此致、

Rishit

Aarti、

我对我的 BSL (辅助引导加载程序)和固件项目进行了一些更改编译器的实验、下面是我找到的内容。

1) BSL 可与编译器版本16.9.3 (eabi)和4.8.8 (COFF)配合使用

2)固件仅适用于编译器 v4.4.8 (COFF)、而不管 BSL 编译器的版本是什么。

3) BSL (编译器 v16.9.3或 v4.4.8)跳转到 ISR31、其中有固件的起始地址。

当 v4.4.8编译的固件加载到闪存中并且从 BSL 运行时我在 ISR31()放置一个断点时、我看到 固件的入口点符号地址(0x5a8a)存储为地址 ISR31 (0x3148)上的数据。 *(0x3148)= 0x5a8a；

当编译的 v16.9.3加载到闪存中并检查地址 ISR31 (0x3148)处的数据、其全部为'F'。 *(0x3148)= 0xFFFF；

注：要使用 v16.0.3编译我的固件、我必须对.cmd 文件进行一些修改、请参阅上面的原始问题、其中我将讨论.cinit 问题。

我的问题是、

存储在 ISR31()中的数据不是固件的第一个地址，而是所有 FS，这是什么问题？？

cinit 编译程序是否会导致覆盖其他段？

为了获得这些问题的答案、我应该寻找什么？

提前感谢、

此致、

Rishit

封装：

1) 1)固件映射和 CMD 文件

2) 2) BSL 映射和 CMD 文件

3)固件构建日志。

e2e.ti.com/.../FirmwareBuildingLog.zip

[引用 user="Rishit Borad"]

当 v4.4.8编译的固件加载到闪存中并且从 BSL 运行时我在 ISR31()放置一个断点时、我看到 固件的入口点符号地址(0x5a8a)存储为地址 ISR31 (0x3148)上的数据。 *(0x3148)= 0x5a8a；

当编译的 v16.9.3加载到闪存中并检查地址 ISR31 (0x3148)处的数据、其全部为'F'。 *(0x3148)= 0xFFFF；

[/报价]

固件的入口点地址是如何存储在 BSL 代码中的？  

如果这与 v4.8.8一起使用、也许将4.8.8生成的链接器命令文件和映射文件与16.9.3生成的文件进行比较也会有所帮助。

感谢 Aarti 的回复、

[引用 user="AarticG">固件的入口点地址如何存储在 BSL 代码中？  [/报价]

BSL 在执行一些主校验和检查后调用 ISR31()。 BSL 会跳转至存储器地址0x3148。 0x3148是固件存储器的一部分、固件负责在地址0x3148处写入其起始地址。 在我们的示例中、存储在地址0x3148处的数据是0x5a8a、其中0x5a8a 是固件的起始地址。   

最近、我决定分步执行、而不是直接跳转到 v16.9.3 EABI 格式。 我现在将 v4.4.8 COFF 格式项目转换为 v4.4.8 EABI 格式。 然后更容易进行 v16.9.3转换、因为它们都支持相同的输出格式 EABI。

[引用 USER="AarticG"]如果此操作适用于 v4.8.8，则将4.8.8生成的链接器命令文件和映射文件与16.9.3生成的文件进行比较也可能会有所帮助。[/引用]

如果您查看.cmd/map 文件、则会创建一个名为 Xfer (origin 0x3100、length 0x50)的段、后跟闪存(origin 0x3150、length 0xcab0)。 Xfer 存储器区域由固件处理。 本节在本例中存储 CSAC_applvect.obj。 CSAC_applvect.obj 显然是固件的矢量表。 在 COFF 格式中、使用的 Xfer 大小为0x4c、在 EABI 中、格式为空。 此处需要注意的是、我将只更改输出格式从 COFF 更改为 EABI。 (使用的大小为0x4c、因为该段的前4个字节用于编译后脚本添加的 CRC)

此外、makefile 中提到了两种格式的 CSAC_applvect.obj、以防相关。

问题是、在 EABI 中、没有在 Xfer 段中写入 CSAC_appvect.obj 的情况有何不同？ 或者、如果您能指引我下一步应该去哪里。  

感谢你的帮助。  

此致、

Rishit

已附加：Firmware_COFF 和 Firmware_EABI 的映射文件。

e2e.ti.com/.../Firmware_5F00_map_5F00_EABI.txt

e2e.ti.com/.../Firmware_5F00_map_5F00_COFF.txt