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.

[参考译文] 编译器/TMS320F2.8377万D:HEX工具似乎未对齐闪存映射

Guru**** 2585275 points
Other Parts Discussed in Thread: CONTROLSUITE

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

https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/641085/compiler-tms320f28377d-hex-tool-seems-to-misalign-flash-memory-mapping

部件号:TMS320F2.8377万D
主题:controlSUITE中讨论的其他部件

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

 我在发行后不久就为f2.8377万D DSP编写了一个引导加载程序,该加载程序将采用CCS工具链生成的ASCII十六进制(带有选项“--boot --sci8”),并使用TI提供的FlashAPI将其写入闪存。 现在,突然我无法写入特定的闪存范围。

 我确保在写入时尊重每个组的宽度,但在某个时候, 并且它始终在闪存扇区F的地址范围内,与正在上载的图像无关。闪存API返回"Fapi_Error_ABHIncorrectDataBufferLength",并且无法写入位置,但位置+4个字再次写入,+8个字不写入。

例如:

0x0091FFE:0000 0000 0000 0000                    //fails

0x9.2002万:0123 4567 89AB CDEF                 //成功

0x9.2006万:0000 0000 0000 0000                   //fails

0x0.92万A:0123 4567 89AB CDEF                 //成功

这表示正在写入的数据未对齐。(?)

我已验证数据是否从自定义SCI前端发送到设备。 我已经验证了十六进制文件的解析。

我在多个其他主板上试用过,它总是可重现的!

没有重写前端来解析文件并将其预分段到库中并添加填充,我想在这里询问是否有人知道这里发生了什么/曾经经历过这种情况/有什么建议?

最佳,

Ron先生。

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

    Ron,

    程序的起始地址加上长度(16位字的数目)不应超过128位对齐的内存。

    例如:

    1. 0x0091FFE:0000 0000 0000 0000                    //失败

    在这种情况下,0x0091FF8到0x0091FFF是128位对齐的地址范围。  当您尝试对以0x0091FFE开头的4个16位字进行编程时,它会失败,因为您在该128位对齐的内存中只有2个字(0x0091FFE和0x0091FFF)的空间时,尝试对4个字进行编程。   

    2. 0x9.2002万:0123 4567 89AB CDEF                 //成功

    在这种情况下,0x9.2万到0x9.2007万是128位对齐的地址范围。  当您尝试从0x9.2002万开始对4个16位字进行编程时,它会成功,因为当 该128位对齐的内存中还有6个字(0x9.2002万到0x9.2007万)的空间时,您尝试对4个字进行编程。   

    有关详细信息,请参阅SPNU629文档。   

    谢谢,此致,
    Vamsi

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

    >程序的起始地址加上长度(16位字的数目)不应超过128位对齐的内存。

    是的,我知道。 主要的问题是,我假设TI工具链会根据需要对齐数据,并且我总是写4个字,从内存部分的0偏移,它应该始终是64位内存的顶部部分,然后是128位对齐的64位底部。 在链接或十六进制生成过程中,似乎添加了另外2个单词。

    我的问题是,在某个时候(在示例之前的某个位置),十六进制图像中似乎存在对齐问题,这显然是因为程序要将4个字写入0x0091FFE。
    作为一项附加测试,我使用了controlSUITE示例中的CopyData()函数,但它有相同的问题。
    这是我对问题的原因是在ASCII十六进制生成中或在链接过程中的映射过程中。


    因此,问题是是否有人遇到过这种情况-如果没有,我必须分析十六进制文件并在需要时添加填充更正。


    相关

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

    Ron,

    好的,我明白了。  是否使用 align(4)在64位边界上对齐链接器命令文件中的所有部分?

    谢谢,此致,
    Vamsi

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

    正如大家所知,我在奥地利,所以我们有一些时间上的转变。


    对于align (4),是,它全部对齐。

    此致
    Ron先生
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    十六进制工具不会对齐内存或将内存插入内存。 这需要在链接时完成。 十六进制工具不能重新链接代码和符号,需要执行这些操作才能对齐或填充内存。 十六进制工具只需将.out转换为十六进制文件格式。

    此致,
    SAL
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    所以我可以假设,不管COFF包含什么,十六进制工具只是盲目地将它转换成任何十六进制格式?

    因此,问题是在链路时间内产生的?

    我花了一整天的时间检查我们所有的链接器配置,所有cmd文件都没有逐行检查COFF,我已经验证了所有配置和.map文件都是正确的。

    由于我目前使用的是最新版本的CCS工具链,我将尝试使用较旧的CCS v6工具链作为最后手段。

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

    Ron,

    我请我们的编译器团队进一步帮助您。  他们可能需要查看链接程序命令文件和映射文件。  

    谢谢,此致,
    Vamsi

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

    瓦姆西

    谢谢。 我花了相当多的时间来浏览我们的所有配置和设置以及所有链接器选项。  

    在将链接器命令文件发布到此处之前,我必须先清理它。

    谢谢

    Ron先生   

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

    没关系。 我们的编译器团队将在您将其发布到此处时进行查看。

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

    编译器团队Vamsi,

    请查找附件,我们用于链接的.cmd和生成的.map文件。

    此致

    Ron先生

    e2e.ti.com/.../uCOS_2D00_II_5F00_F2837xD.map.txt

    e2e.ti.com/.../F2.8377万D_5F00_uCOS_5F00_link.cmd.txt

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

    Ron,

    是否可以在链接程序cmd文件中尝试PALIGN(4)而不是align(4)?  这将填充任何不完整的64位。

    我们的编译器团队今天正在研究它。

    谢谢,此致,
    Vamsi

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

    瓦姆西

    回到办公室后,我会尝试一下。

    编辑:我试过。 相同的确切行为没有区别。 C2000平台是否支持此关键字? 我只能在基于ARM的平台上找到文档?


    谢谢,此致,
    Ron先生

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

    不幸的是,我不明白发生了什么。

    如果您将链接程序生成的.out文件发送到您的系统中,我将不胜感激。  将其拉链拉紧,并将其附到下一帖子中。  同时还准确显示如何通过CCS控制台视图中的copy-n-paste调用十六进制实用程序。  然后显示十六进制实用程序输出中未对齐的第一行。  解释为什么它未对齐。

    ron 说:
    C2000平台是否支持此关键字?

    C2000链接器支持palign功能。  请参阅  C28x装配工具手册中标题为"与填充对齐"的部分。

    谢谢,此致,

    -George

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

    George,

    如果没有NDA或类似协议,我无法发布二进制文件。

    我不知道在哪个地址发生错位,这似乎完全是任意的。

    请给我几天时间为您编辑信息。

    >古色古色

    谢谢-应该更新我的本地版本

    此致

    Ron先生

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    既然已经有一段时间了,我想你已经解决了这个问题。 如果您能解决这个问题,我将不胜感激。

    谢谢,此致,

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

    George,

    很抱歉耽误了我的时间,我在度假,没有网络!

    我没有解决这个问题。

    我已经决定 重写分析文件的前端以执行自适应填充以修复误调,因为此问题是您的产品的"显示限值"。

    完成后,我将向您发送一个包含收集的数据的PM,以便您可以调查这是否是工具链的问题。

    换言之,我将此线程标记为已解决。

    感谢所有的帮助,

    此致

    Ron先生