[参考译文] MSP430FR2433：勘误表 CPU40影响 GCC、具体取决于数据中的第一项。 (如果全局变量具有一些值、则生成无效代码)

更改已初始化变量的值对生成的代码没有任何作用。 在调用 memset ()(以清除 BSS )之后对 memcopy ()的调用保持不变。 只有复制的数据才会更改。

我最初的描述有点不准确。 除了数据段中的值之外、实际生成的程序是相同的(基于使用 objdump -ds 反汇编的差异)。

但是、当数据段包含一个"坏"值 memset 时、似乎会断开。 对_crt0_init_BSS 中 memset 的调用从不返回。 经过大约500、000个时钟周期后、PC 最终值为4。 这似乎是一个 memset 错误。

为什么应该为零的 memset 调用会受到数据段中的值的影响、这仍然没有道理、但似乎是这样。 更令人困惑的是、在这个特定值中、高4位为零、低8位为0x40 (位8-11似乎无关紧要)。

为了进一步增加我的困惑：

• 我无法在 FR2355上复制此示例(FR2433特定的问题？)
• 在"myvar"下面的 twi.c 中添加一个具有"良好"值的变量可以防止出现该问题

也许它在某种程度上与0x2000处的值相关(根据反汇编、这是 myvar 位于数据段的位置)。 添加第二个全局变量会将 myvar 下拉至0x2002 (从而防止发生该问题)。

我仍不确定 WDT 中断访问全局变量的关系、但禁用看起来会使一切正常工作、无论是否有数据。

很抱歉回复很快。 只是继续寻找其他的东西,因为我搞错了。 我现在已经在一个简单得多的项目中复制了它。 我目前的理论如下

在以下一组情况下初始化 BSS 时、MSP430FR2433 memset 上不知何故出现错误

• BSS 中必须有某个值才能导致调用 memset
• 数据(0x2000)中的第一个项必须具有值0x0_40、其中_可以是任何数字

0x2002而不是0x2000上的0x0_40不会发生这种情况。

无论0x2000处的值如何、当 BSS 为空时都不会发生这种情况(可能是因为永远不会调用 memset)。

鉴于 memset 应该非常简单、我想知道这是否与硬件相关。

编辑：附加了演示该问题的更简单项目。

e2e.ti.com/.../6102.ReducedExample.zip

您好！

您是否从 GCC 编译器和 TI 编译器输出了.txt 或.hex 文件、并对这两个文件进行了比较？

此致、

现金 Hao

memset 很简单：

0000c404 <__crt0_init_bss>:
    c404:       3c 40 02 20     mov     #8194,  r12     ;#0x2002

0000c408 <.Loc.76.1>:
    c408:       0d 43           clr     r13             ;

0000c40a <.Loc.77.1>:
    c40a:       3e 40 04 00     mov     #4,     r14     ;

0000c40e <.Loc.81.1>:
    c40e:       b0 12 ea c4     call    #-15126 ;#0xc4ea


000c4ea <memset>:
    c4ea:       0e 5c           add     r12,    r14     ;

0000c4ec <.LVL2>:
    c4ec:       0f 4c           mov     r12,    r15     ;

0000c4ee <L0^A>:
    c4ee:       0f 9e           cmp     r14,    r15     ;
    c4f0:       01 20           jnz     $+4             ;abs 0xc4f4

0000c4f2 <.Loc.104.1>:
    c4f2:       30 41           ret                     

0000c4f4 <.L3>:
    c4f4:       1f 53           inc     r15             ;

0000c4f6 <.LVL4>:
    c4f6:       cf 4d ff ff     mov.b   r13,    -1(r15) ; 0xffff
    c4fa:       f9 3f           jmp     $-12            ;abs 0xc4ee

而完全不关心存储器中的数据是什么。 请注意、memset 包括 零长度 BSS 校验。

仔细查看链接器文件(gcc)、看起来数据直接放在 FRAM 中的文本之后。 在此程序中、内存集被放置在文本的末尾并且以一个跳转指令结束。 因此、数据中的第一项能够导致勘误表 CPU40中所述的问题。

勘误表将 gcc 列为不受影响、但我认为在此特定场景中(文本末尾的 memset)、数据中的第一项可能会导致问题。

这不会影响 FR2355、因为持久段位于文本和数据之间(不过、这可能仍然是问题、具体取决于持久段中的首要内容)。

我可以考虑的解决方法涉及修改链接器脚本。

• 将 keep (*(.text.end_of_text))添加到文本段、并将一个函数添加到此段、其变为"nop"和"ret"
• 在文本和数据之间添加一个段、并在其中放置一个变量、该变量是 NOP 指令的数据。

我真的不喜欢这些解决方案中的任何一个(因为我的代码库最终将支持许多目标、并且维护已修改的链接器文件似乎很混乱)。 但是、我没有看到可确保不会出现问题的其他解决方案。

如果 GCC 认为需要、它将插入一个 NOP。 但它无法处理库函数 memset 的特殊结构。 它在中间有其返回指令、在末尾有一个分支 编译器无法修复它。 链接器如果感兴趣、也可能需要链接。

这个问题要求 memset 成为文本段中代码的最后一位、并且对于初始化程序中的第一个数据位、应该具有特定的模式。 简单的做法是对已初始化的数据执行一些操作。 您可以向链接器脚本添加一些内容(有一种包含数据的机制)、但更简单的是修复初始化程序。 改变变量的顺序最简单。 在最坏的情况下添加"int foo = 0；"、这样就不会触发该勘误表。

关于初始化数据的位置、我听到了一点提示、但我不知道是什么。 然后、当我查看针对另一个处理器(fr5969)的代码时、我注意到这些数据位于 FRAM 的开头。 而非.text 段前面的符号链接。

我查看了链接器脚本、但我对它们不是专家、也看不到任何会导致这种情况的脚本。