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

链接器没有强制两个输出段(如.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 段不连续占用闪存，则代码无法正确运行

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

谢谢、此致、

乔治

Mock、

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

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

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

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

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

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

Howard、

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

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

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

最棒的

Matthew

Matt、

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

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

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

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

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

Howard、

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

最棒的
Matthew

[已删除]

Matt、

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

Howard、

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

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

最棒的

Matthew