请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
器件型号：TMS320F28035 客户 在代码中遇到一个奇怪的问题，我不确定到底是什么是根本原因。
- 附件是我的链接器文件： e2e.ti.com/.../F28035_5F00_issue.zip
- 我有“.ebss ：>> M0M1_DRAM | L0_DRAM | L1_DRAM， PAGE = 1”
- 将我的变量拆分为可用 RAM
- F2_APP_RLS_NoNewVar.Map à 这是一切正常工作时的“以前”状态。
- 我通过单步执行以下代码来确认工作：ptrBboxRam =(uint16 *)(&sBboxRam)；
- 在映射文件中、请参阅第766行。 sBboxRam 位于0x8540 (在 L0 SARAM 中)。 当我单步执行代码时、我可以看到 ptrBboxRam=0x8540、因此我可以确认指针的值是正确的。
- F2_APP_RLWithNewVar à 这是出错时的“后”状态。
- 我添加了一个新变量 sSnapLocal、一个包含62个字的数组。 这个新变量位于0x8840 (在 L1 DPSARAM 中)
- 添加此新变量还会导致 sBboxRam 重定位到0x8900 (在 L1 DPSARAM 中)
- 当我单步执行代码时、我得到 ptrBboxRam=0xC1A1C7F7。 它是存储器范围中的一个非常高的数字、因此我知道有什么问题。
- 如果我注释掉 sSnapLocal 的声明、重新编译并运行、则代码会再次运行、因为 ptrBboxRam 获得了正确的值。
- 因此、我已经确认该误差与该新变量有关。 我怀疑这是因为 sBboxRam 已从 L0_SARAM 迁移到 L1_DPSARAM。 我的印象是，除了 L0是双存取外，此 DSP 中的所有 RAM 内存都“相似”。
- 随附的还是我的 Makefile 文件、因此您可以查看编译器/链接器设置。
目前，我正在努力了解原因可能是什么，可能是编译器选项中的一个简单复选框，也可能是更复杂的。 我目前正在添加一项称为“黑盒”的功能，它占用了大量的内存。 sBoxRam 本身具有672个字。
但是，如果我将 Mo、M1、L0、L1组合在一起，仍然有足够的空间可以移动，因此我知道我没有空间用完(还没有)，所以这可能只是一个设置问题。
客户 尝试比较"Disassembly"代码、请参阅下面的图片。 代码看起来非常相似、除了不同的存储器地址和 DP 值。
“之前”状态 sBboxRam @ 0x8540
“后”状态 sBboxRam @ 0x8900
我希望您能在这个问题上为我提供指导。
此致、Bernd
