[参考译文] TMS320F28335：eCAN 存储器覆盖问题

非常感谢您的回复。  

存储这些"其他变量"的 RAM 的哪个部分？

不幸的是，我不太确定如何确定这一点。

我确认已损坏的变量之一是在头文件中定义的恒定字符串数组。 检查.asm 输出我认为数据位于.econst 段中、定义为：

 .econst          ：>闪存，        PAGE = 0

在存储器中定义的闪存块

闪存       ：origin = 0x30000c，length = 0x037FF0

这对我来说很合适(ECAN 模块位于0x6100和0x63ff 之间、与规范文档中描述的布局相匹配)。  

查看链接器命令文件、我可以确认没有存储器块与 ECAN 块重叠。

但是、我注意到为 PAGE 0和 PAGE 1定义了一些区域。 例如、  

第0页：  
Ramm：origin = 0x000000，length = 0x000800

第1页：  
Ramm：origin = 0x000000，length = 0x000800

在第0页和第1页中以相同的方式定义了另外5个或6个区域。  

可以吗？ F28335.cmd 文件警告"不应为 PAGE 0和 PAGE 1定义相同的存储器区域"。  

非常感谢。

如果您可以找到损坏的变量的地址、则可以检查存储器映射输出(xxxx.map 文件)或链接器命令文件以确定段分配。

闪存存储器不能像 RAM 位置那样"损坏"。 必须执行一个非常具体/精确的低级命令序列来擦除/编辑一个闪存位置。

如果一页内有内存的重叠部分、CCS 会在编译/链接过程中提供错误。 能否使用作为 C2000ware 一部分发布的链接器命令文件？ 您是否能够在帖子中复制/粘贴文件的内容？

关于问题2 (在第0页和第1页中映射的区域)、不允许这样做。 很遗憾，链接器无法检测到这一点，因此 CCS 不会抱怨。 请注意、28x 遵循统一存储器模型。 即没有单独的程序/数据/ I/O 存储器、就像我们在一些较旧的(24x/24xx) C2000器件中使用的那样。

非常感谢您的宝贵帮助。 我不确定是否允许我在这里发布整个.cmd 文件-如果可以、我很乐意这样做。  

>>闪存存储器不能像 RAM 位置那样"损坏"。 必须执行一个非常具体/精确的低级命令序列来擦除/编辑一个闪存位置

这很有意思。 常量字符串本身在头文件中定义、并由应用程序中 的指针沿的行引用

[.h 文件] 
const char strings1[n1][n2][n3]=｛...｝、... ｛...｝｝； 

[.c 文件]

const char (* pStrings1)[n1][n2][n3]；

pStrings1 = strings1；

(笑声)

因此、如果我正确理解您的注释、那么被破坏的数据更有可能是指针 pStrings 的值、而不是数组 string1本身的内容。 是这样吗？ 这对于找出问题的根本原因非常有帮助。  

>>关于您的问题#2 (在 PAGE 0和 PAGE 1中映射的区域)、不允许这样做

据我了解、这意味着在两个页面中定义相同的区域可能会导致将不同的数据映射到同一地址。 我可以说的是、在我们的.cmd 段定义中、每个页面始终链接到 PAGE 0或 PAGE 1、但不能同时链接到这两个页面；例如、没有示例

.cinit：> FLASH，page = 0
.pinit：> FLASH，PAGE = 1.

据我了解、这是真正开始出现问题的地方。 我还彻底检查了.map 和 linkInfo.xml 文件、在内存映射中找不到任何冲突、因此我开始认为问题在其他地方、而不是在.cmd 文件中。  

尽管如此、我认为没有任何充分的理由在两页中定义相同的区域、并建议我们针对安全问题进行修复。 如果我在这里错了、请更正我的问题。  

>> 28x 遵循统一存储器模型。 即没有单独的程序/数据/ I/O 存储器、就像我们在一些较旧的(24x/24xx) C2000器件中使用的那样

因此，这基本上意味着页码不重要，而且页0和页1中的分隔主要用于文体/清晰目的？  

我注意到、相对于示例文件 DSP2833x_Headers_nonBIOS.cmd、我们的代码中.CsmPwlFile 部分已从第1页移动到第0页、即我们有

CsmPwlFile        ：>CSM_PWL、       PAGE = 0

我觉得有点奇怪，但根据你所说的话，我认为这本身没有任何结果。

再次感谢、祝您愉快的假期、

Laurent Badel

因此、如果我正确理解您的注释、那么被破坏的数据更有可能是指针 pStrings 的值、而不是数组 string1本身的内容。 是这样吗？ 这对于找出问题的根本原因非常有帮助。  

答案-->如果字符串存储在闪存中，则可能是这样。 如前所述、闪存内容仅通过在精确序列(擦除后执行程序)中执行闪存 API 来改变。 应用程序代码无法像写入 RAM 那样"随意"写入闪存。 指针损坏不能以损坏 RAM 的方式改变闪存内容。

尽管如此、我认为没有任何充分的理由在两页中定义相同的区域、并建议我们针对安全问题进行修复。

答案-->正确。

感谢您的回复；遗憾的是、问题尚未解决、但可能根本不是由 CAN 总线引起的。 结果我们有两个不相关的问题、其中一个是处理特定 CAN 消息时的简单错误；另一个仍然是一个谜。

我现在正在研究堆栈溢出的可能性、与此相关、我想知道 ISR 的堆栈框是否直接推入当前堆栈、或者是否可能存在单独的堆栈。

谢谢你

只有一个堆栈。 有关堆栈的更多信息、请参阅 SPRU430。 http://www.ti.com/lit/an/spra820/spra820.pdf 提供了解决堆栈问题的有用提示。

请关闭原始帖子。 如果发现新问题/不同问题、请打开新帖子。