[参考译文] TMS320F28379D：奇怪的处理器行为：错误的指令执行？

我已更换代码

  address = *((uint32_t*)buf);

使用

   address = buf[1];
  address <<= 16;
  address |= (buf[0] & 0x0000FFFFUL);

现在、该程序可以正常工作。 但我不明白第一个变体有什么问题。

此致、

Alex

尊敬的 Alex：

由于此变量位于 MSG RAM 中、可从 CPU1进行更新、因此您可能需要使用易失性变量并查看它是否能解决问题。

此致、

Vivek Singh

您好、Vivek、

这话什么意思？ 您是说对"buf"指针使用 volatile、还是对它指向的变量使用 volatile？ 实际上、"buf"是函数参数。

我认为易失性在编译时很重要、但在运行时不重要。 在我看来、编译器的易失性 syas 无法缓存变量、无法优化对其的读取访问。 我弄错了吗？

如屏幕截图所示、XAR4寄存器指向正确的地址(将其与表达式"&buf[0]进行比较)。 在执行指令""之前MOVL  ACC,*+XAR4[0]、ACC 寄存器被手动填充为假值0xA5A5A5A5、在执行指定的指令之后、它包含0x20000081。 这意味着 ACC 在执行这个指令期间被更新。 同时、表达式""*((uint32_t*)buf)(在"表达式"选项卡中)显示相应的值0x82000。 执行""之前和之后显示此值MOVL  ACC,*+XAR4[0]。

此致、

Alex

在执行""之前、我已暂停 CPU1MOVL  ACC,*+XAR4[0] -结果相同-在 ACC 寄存器中获得了错误的值(0x20000081而不是0x82000)。 因此它不能从 CPU1更改 MSG RAM。

调试选项卡表达式显示两个 CPU 上表达式*((uint32_t*) 0x3FC01的值0x00082000。

此致、

Alex

Сan 这与奇数地址的32位访问有关？

我还在查看地址对齐。 buf[2]中的值是什么？

您正是因为易失性才会在编译时和运行时产生影响。 我只是想、由于某种原因、CPU1会在您阅读时更新相同的位置、但您的新帖子确认这不是问题。  

buf[2]= 0x0010

您是否还可以检查编译日志并查看是否有任何警告？

没有任何警告。

0x3FC00的值是什么？

你是对的。 这是0x0081

好的、那么、基本上发生的情况是、当用户尝试访问奇数地址处的32位值时、它将奇数地址转换为偶数地址、然后从该地址处提供值、在本例中为0x3FC00。 在这种情况下、编译器应该已经给出了一些警告、但由于它不是、可能有一些开关来启用此类警告。 我必须就此向我们的编译器团队咨询。

此致、

Vivek Singh

您能否尝试在 buf 声明后添加以下行、并查看这是否可以解决问题-

#pragma DATA_ALIGN (buf、2)；

此致、

Vivek Singh

很抱歉、但我不明白我应该将此 pragma 放在哪里。

我定义了一个结构类型

typedef struct {
    uint16_t BL_cmd;
    uint16_t BL_data[20];  
} C1C2_MSG_t;

此с1с2_msg类型的全局变量使用.cmd 文件放置在地址0x3FC00。 "buf"是函数的 uint16_t*参数：

void my_func(uint16_t* buf)

{

...

}

此函数的调用方式如所示

...

my_func( c1c2_msg.BL_data );

...

此致、

Alex

这在哪里描述？ 在什么文档中？

尊敬的 Alex：

如果您对此有任何进一步的疑问、请告诉我。

此致、

Vivek Singh

尊敬的乔治：

感谢您的全面介绍和第二种解决方案。

此致、

Alex