• 状态 Resolved
  • 已锁定 已锁定
  • 回复 7 回复
  • 订户 1 订户
  • 视图 430 视图
  • 用户 0 会员在此处
选项
选项
相关

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.

[参考译文] CCS/TMS470MF06607：是否有方法在生成的文件(.hex/.out)的末尾附加固定数据

admin
Guru**** 2587345 points


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

https://e2e.ti.com/support/tools/code-composer-studio-group/ccs/f/code-composer-studio-forum/786369/ccs-tms470mf06607-is-there-a-way-to-append-fixed-data-at-the-end-of-the-generated-files-hex-out

器件型号：TMS470MF06607

工具/软件：Code Composer Studio

我想在生成的文件的末尾附加四个字节的数据(0x01 0x02 0x03 0x04)。  

内存位置未固定。 要使用的存储器位置将是生成的文件结束位置的下一个位置。

如果使用 CCS 版本 5.2.0.00069、请告诉我这一点是否可行  

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

    无法在十六进制实用程序中执行该操作。  它仅转换输入可执行文件中的内容。   

    我认为可以在链接器命令文件中执行该操作、以便十六进制转换器输出这4个字节。  我以前从未做过、但我相信我可以明白。  我怀疑这会有点丑。  你有兴趣吗？

    谢谢、此致、

    乔治

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

    感谢您的快速回复。

    是的、我想知道是否有任何通过链接器文件的方式。

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

    我找到了一种实现它的方法。  但它相当难看。  您可能会认为这不值得。

    请首先查看文章 链接器命令文件入门的第一部分。  清楚地了解术语输入部分、输出部分和存储器范围。

    在当前链接器命令文件中、使用分配给已初始化输出段的最高地址来标识存储器范围。  在此帖子中、我将存储器范围称为 HIMR (最高初始化的存储器范围)。  将分配给 HIMR 的所有初始化输出段放入一个组中。  然后添加一个用所需值填充的额外存储器范围。  看起来就像这样... 

    组
｛
.text
.const
.pinit
.cinit
Last4
｛
。 += 4；
｝ 填充= 0x01020304
｝ > HIMR

    输出段在 last4之前的顺序无关紧要。  在您的情况下、初始化段的列表可能会有所不同。  仅为在当前链接器命令文件中分配给 HIMR 的已初始化输出段命名。  第7行创建名为 last4的输出段。  它不包含输入段。  第9行在输出段中创建了一个4字节的孔洞。  第10行用显示的值填充该孔。

    由于.cinit 段是 GROUP 的一部分、因此必须添加链接器选项 -cinit_compression=off。  默认情况下、.cinit 段被压缩。  此选项禁用压缩。  为什么必须禁用压缩？  不幸的是，答案很长。  不压缩.cinit 可避免 此论坛主题中讨论的问题。    这意味着.cinit 段比以前占用更多的存储器。  这可能是项目的问题、也可能不是。

    谢谢、此致、

    乔治

  • 0
    TI__Guru**** 2587345 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    非常感谢您的创意！！

    我尝试过它、它似乎正常工作。 我只需要分析任何副作用。
    我比较了更改前后生成的文件。 在这些文件中、.hex 和.map 文件看起来不错。 但.out 文件中似乎有很多更改、我不确定如何验证.out 文件。


    我使用了以下代码段。 如果您认为存在任何相关风险、请告知我、以便我对此进行背景检查。
    部分
    ｛
    .intvecs：{}>向量
    vim_table：{}> VIM_TABLE
    .text：palign (1)｛｝> FLASH0
    .bss ：{}> RAM
    .data :{}> RAM
    .sysmem：{}>RAM

    .stack： /*软件系统堆栈 *
    ｛ /*初始堆栈指针值 *
    。 += 0x00000400；_Stack_Table_Pointer =.；
    。 += 0x00000400；_Stack_Handler_Pointer =.；
    }>堆栈

    组
    ｛
    .const
    .cinit
    .pinit
    Last4
    ｛
    。 += 4；

    }填充= 0xABCDEF00
    }> FLASH0 | FLASH1
    ｝
  • 0
    TI__Guru**** 2587345 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    我有一个小建议需要考虑。  将组的分配更改为... 

    }>> FLASH0 | FLASH1 /*将>更改为>>*/

    要了解差异、请参阅 链接器命令文件入门文章的此部分。

    谢谢、此致、

    乔治

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

    感谢您的建议。

    但是从基本工程中、预期.text/.const/.cinit /.pinit 不应拆分。

    请找到以下快照。

    ".text：{}> FLASH0

    .const： {}> FLASH0| FLASH1

    .cinit：{}> FLASH0| FLASH1

    .pinit：{}> FLASH0 | FLASH1"

     

    我无法在小组内部提供该信息。

    >>表示拆分、因此我没有使用它、因为我担心.const 的一半在 FLASH0中、而另一半在 FLASH1中。 这与预期行为相违背。

    我们是否可以在 GROUP 中单独分配存储器？

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

    很抱歉、我不应该告诉您拆分组分配。  您的组包括输出段.cinit、无法拆分。   

    [报价用户="Kavya Ramachandra"]我们是否可以在组中单独分配内存？

    否

    谢谢、此致、

    乔治