• 状态 Resolved
  • 已锁定 已锁定
  • 回复 5 回复
  • 订户 0 订户
  • 视图 244 视图
  • 用户 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.

[参考译文] TMS320C6748：存储器中的存储器段顺序的影响

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

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/678005/tms320c6748-memory-sections-effects-of-order-in-memory

器件型号：TMS320C6748

大家好、

我遇到了一个奇怪的情况，我想得到一些建议。

我有一些自定义存储器段(.crc_tables 和.variable_data)、它们之前的大小为0x800、而.sysmem 段也是0x800、 我想增加.variable_data 段中数组的大小、这种大小的增加改变了存储器映 射中的顺序、使其以前是.crc_tables、.sysmem、.variable_data、现在是.variable_data、.crc_tables、.sysmem。 我的软件崩溃、当我尝试暂停调试器时、我收到以下错误。

C674x_0：停止目标 CPU 时出现问题：错误0x00000020/-1060错误在执行期间、一个未知错误阻止了仿真器及时访问处理器。

我找到了一个解决此问题的方法、就是将三个部分分组以保持其顺序、所有内容都按预期工作、但交换3个部分中的任何2个会导致崩溃。

是否有人对存储器中段的顺序会影响程序有任何想法？

正如我所说的、我找到了问题的解决方法、但我对问题首先出现的原因感到好奇。

此致、

Graham。

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

    您使用的是哪个 RTOS 版本？

    此致、
    Yordan
  • 0
    TI__Guru**** 2974170 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    我不使用 RTOS、我有一个小型自定义写入任务调度程序。
  • 0
    TI__Guru**** 2974170 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    总结、工作顺序

    .crc_tables
    sysmem
    .variable_data

    非工作订单

    .variable_data
    .crc_tables
    sysmem

    顺序无关紧要。 sysmem 段用于 malloc。

    我想有些代码是在其指定部分之外编写到下一部分中的。 在工作顺序下、仍会发生错误写入、但会损坏不会导致崩溃的内容。

    另一个可能的情况是、重新排序会更改段的对齐方式。 sysmem 段在代码中对齐。 它的尺寸为2^n。 它将强制对齐以下段。 需要对齐 variable 数据吗？ DMA 缓冲器需要对齐。
  • 0
    TI__Guru**** 2974170 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    谢谢 Norman、

    我从公式中删除了.crc_tables、因为在您的评论之后经过一些调查后、我发现它完全是.sysmem 和.variable_data 的顺序至关重要。

    下面的操作正常。

    将 C6748.cmd 链接器文件中的.sysmem 和.variable_data 进行分组

    组:>SHDSSPL2RAM

    ｛

      sysmem

      .variable_data

    ｝

    这导致了来自 projects .map 文件的以下片段

    .sysmem  0  11830000  00000800  未初始化

             11830000  00000008  rts6740.lib：memory.obj (.sysmem)

             11830008  000007f8  --孔--

    .variable_data

    *      0  11830800  00000800  未初始化

             11830800  000007e8  tcp_protocol.obj (.variable_data)

             11830fe8  00000018  ip_protocol.obj (.variable_data)

    以下内容已损毁。

    在 C6748.cmd 链接器文件中对.variable 和.sysmem 进行分组

    组:>SHDSSPL2RAM

    ｛

      .variable_data

      sysmem

    ｝

    这导致了来自 projects .map 文件的以下片段

    .variable_data

    *      0  11830000  00000800  未初始化

             11830000  000007e8  tcp_protocol.obj (.variable_data)

             118307e8  00000018  IP_protocol.obj (.variable_data)

    .sysmem  0  11830800  00000800  未初始化

             11830800  00000008  rts6740.lib：memory.obj (.sysmem)

             11830808  000007f8  --孔--

    我在应用程序中不使用任何动态内存分配、因此不应使用.sysmem。

    在工作和非工作情况下，地图中的以下部分都是

    .cinit 0 11831000 00000d14

    在这两种情况下、.variable_data % 8和.sysmem % 8的地址都为0、因此对齐方式没有不同。

    这会将代码写入指定的段之外、我目前看不到这些段、但我将进一步研究这些段。

    谢谢、

    Graham

  • 0
    TI__Guru**** 2974170 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    我同意对齐看起来很好。 几个猜测：

    有人正在使用 malloc。 对.variable_data 的写入太大、会溢出到.sysmem 中。 破坏 malloc'ed 存储器。 如果您使用的是第三方库、则很难判断它们是否使用的 malloc 而不使用。

    有人在.variable_data 之前写入该段。 在工作情况下、假设未使用 malloc、错误写入将进入未使用的 malloc 空间。 在崩溃原因中、错误的太大写入将进入.variable 段。 这些问题部分之前的部分是什么？