• 状态
  • 已锁定 已锁定
  • 回复 8 回复
  • 订户 1 订户
  • 视图 348 视图
  • 用户 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.

[参考译文] TMS320F28069：闪存占用问题

admin
Guru**** 2553260 points
Other Parts Discussed in Thread: LAUNCHXL-F28069M

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

https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1020588/tms320f28069-flash-occupying-question

器件型号：TMS320F28069
主题中讨论的其他器件：LAUNCHXL-F28069M

您好！

我的客户发现、有时这些段不 会连续占用闪存。

在下图中、左侧显示.cinit (在003dfe52处结束)和.econst (在00edfe54处开始)之间将有一个孔洞。

而右侧不存在此类问题。

他们通过在代码中添加"switch case"函数来解决此问题、而在一个函数中存在许多情况。

例如、

"开关 A、

案例1、案例2、案例...、案例 N." N>10。

他们发现、如果.cinit 段和.econst 段不连续占用闪存、代码无法正确运行。

我们不知道为什么会发生这种情况。

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

    链接器没有强制两个输出段(如.cinit 和.econst)相邻的功能。  在大多数情况下、.cinit 段无需对齐、而.econst 段需要2字(32位)对齐。  在这种情况下、当.cinit 后跟.econst 时、 大约有一半的时间存在一个1字孔洞。  换而言之、在其他构建中必须定期出现类似的漏洞。

    [引用 userid="2766666" URL"~/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1020588/tms320f28069-flash-occupying-question "]他们通过在代码中添加"switch case"函数来解决此问题[/quot]

    请忽略此详细信息。   这会导致.switch 段更大、进而导致.cinit 段在与其他地址不同的地址上启动、并最终导致.cinit 和.econst 之间出现空洞。  但是、如果不是这个细节、其他一些细节将导致孔洞。   

    [引用 userid="2766666" URL"~/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1020588/tms320f28069-flash-occupying-question "]如果.cinit 段和.econst 段不连续占用闪存，则代码无法正确运行

    您确定这是问题的根本原因吗？  许多其他编译在初始化段之间具有类似的孔洞、这些编译可以正常工作。

    谢谢、此致、

    乔治

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

    Mock、

    我们还发现、有时存储器映射不会对齐：

    我们有2 个项目、唯一的区别如下所示 ：  

    通过查看存储器映射、左侧的最后占用地址为3e01eb、3e01e8

    但是、它不与 IQMath 最后地址对齐：

    左侧为3e01ec>3e01eb (这应该是由我在上一篇文章中提到的孔引起的)，右侧为3e01e8=3e01e8

    左侧工程无法正确运行、因此我们怀疑它是由占用的闪存导致的、与 IQMath 中显示的最后一个地址不匹配。

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

    Howard、

    正如乔治所说的那样、定位孔本身不应导致问题。  当代码大小发生变化时、链接器将动态更正函数调用等的地址。

    当代码失败时、您能评论 C2000上的操作吗？  是否调用了非法 ISR、WD 超时或错误的计算？  

    我们是否还可以查看两种情况下为堆栈保留的存储器、并确保它在第一种情况下不会溢出？

    最棒的

    Matthew

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

    Matt、

    刷写器件后点击"Run"时、代码因卡在 DSP28x_usDelay 中而失败：

    无法运行的代码的内存映射为：

    e2e.ti.com/.../N2002ACAPP_2D00_NotRun.map

    可以运行的代码的存储器映射为：

    e2e.ti.com/.../N2002ACAPP.map

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

    Howard、

    当 CPU 寄存器处于此功能中时、客户是否能够捕捉到它的内容？  具体来说、我想查看 SP (栈指针)和 RPC 寄存器的值。  我不确定代码如何卡在这个环路中、一旦 ACC = 0、它最终将退出。

    最棒的
    Matthew

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

    Matt、

    当代码无法运行时、堆栈指针大于0x400、如下所示：

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

    Howard、

    查看映射文件、我认为对于这两个构建、堆栈都从0x400开始、并为此保留0x300。  因此、我认为 SP 在这里是合理的(远低于0x412)。

    客户是否可以将这两组代码/源代码从论坛发送出去？  我是否能够在 LAUNCHXL-F28069M 独立运行并观察故障？  我认为我们必须向后追溯、以了解导致问题的原因。  我不认为空穴是问题、但导致映射变化的任何因素在这里都有某种关联。

    最棒的

    Matthew