[参考译文] TMS320F280039：CCS 20和 CCS 12.8.1上的编译器问题(22.6.1.LTS)

第151行的评论令人困惑。  静态变量的范围 测试项目 只限于功能范围 MAIN_CORE_TESTS 。  函数期间无法访问它 STA_CoreTest 。   

我想您是说该函数 STA_CoreTest 从不返回该值 STA_TEST_PASS 但在某些情况下应该这样做。  为了对此进行评论、我需要详细了解该函数 STA_CoreTest 。

谢谢。此致、

-乔治

我试图快速地描述这个问题,但很明显,我根本没有描述它。

以下是上面编译器列表中的相同代码、它仍然保留在调试器的反汇编视图中丢失的所有名称引用：

这段摘录是围绕函数中的循环main_core_tests(),围绕调用STA_CoreTest()-后者不直接涉及到问题,它只是收到了一个错误的参数,正如我下面所述。

注意：test_item代码不需要静态这一事实、只是用于漏洞利用(可能是全局的、具有相同效果)。 很多代码都在此处、以便完成此处所述的操作。

a.在进入循环之前、变量 test_item 设置为0 (在此屏幕截图上方的行中)。 偏移+0x1C 处的获取会在 AL 中加载0、因此它STA_CoreTest作为参数传递
b.然后、每次在偏移量+0x23处运行时递增
c.在偏移量+0x26处、循环返回到标签$C$L1。 第一次运行时、存储器中 test_item 的值正确为1
d.当在偏移+0x1c 处再次加载 AL 时、我预计它会为1、但令我惊讶的是、它仍会为0、因此适用于循环中的每次重复

我不知道是否存在与偏移+0x1b (使用 ACC)处的指令的流水线争用。
从+0x14到+0x1b 的行是由宏 DEBUG_MARK2_TOGGLE ()从 C 源代码生成的:如果我移动/删除该行,问题就会消失。

让我坚持这一点： 我自己不会相信这种说法 如果我没有看到它一直在发生, 通信 运行的两个不同项目。
这就是为什么我要求其他人测试代码(整个测试项目附加到原始消息)。

如果我理解正确,你是说这些指示接近结束的关键循环...

        INC       @||test_item$1||
        MOV       AL,@||test_item$1||

存储器位置的增量 test_item1美元 意外情况。  但加载到的值 AL 始终为0。  是这样吗？

谢谢。此致、

-乔治

呃。 这几乎是正确的。

行为与指令类似 MOV AL,@||test_item$1||出现偏离 始终跳过。 最后一个偏移量+0x24被正确解析、但当循环返回到顶部时、却使用相同的指令 偏移+0x1c 处 继续在 AL 中离开0。

正如我所写的那样、在您看到它正在运行之前、听起来是不合逻辑的。

我略微修改了代码、声明test_item为全局代码、以便在存储器窗口中轻松显示。 生成的编译代码完全相同。

然后、我在我的屏幕上记录了一个短的调试会话、从第一次运行循环开始、递增并跳回顶部。 这是一个4 MIB 视频、您可以从此处下载   

www.swisstransfer.com/.../2e360ce7-7581-4bdc-88d4-1c8235376bed

感谢您制作视频。  不幸的是,我看不到它。  有关它的一些事情会阻止 TI 使用的恶意软件系统。   

我将提请 C2000硬件专家注意此主题。  他们很可能比我更有帮助。

谢谢。此致、

-乔治

e2e.ti.com/.../2025_2D00_02_2D00_21-08_2D00_37_2D00_40.mp4

还有一个尝试:转换为 mp4,似乎上传它在这里,即使它是大

尊敬的 Luca：  

我将接管解决这一问题的工作。  请给我一些时间来完成它并尝试在我的设置上进行复制。

此致、

Delaney

感谢您的帮助。

在中、已发布 C2000-CGT 版本 22.6.2.LTS 然后我安装了它。
针对这款最新编译器在 CCS 20.0.2上重新编译整个工程、我可以确认在我这边 仍然相同 ——不管怎样,围绕有问题的行生成的代码看起来都是一样的。

尊敬的 Luca：

很抱歉耽误你的时间。 您能否提供 STA_CoreTest ()函数定义中代码的屏幕截图? 我认为这样可以帮助我在深入研究汇编代码之前、先排除 C 代码中的任何问题。  

此致、

Delaney  

尊敬的 Delaney：

您可以在原始邮件的附件中找到整个项目源的 ZIP ," Universal Project.zip"-甚至包括一些非常无用的源文件,但我离开,不会改变太多的非常可重复的行为。

尊敬的 Luca：

我运行了您的代码、不确定我是否完全理解问题。 我们试着从 C 语言的角度来看待这一点、而不是马上深入到装配体中。 您是否期望 test_item 变量遍历所有枚举、然后在达到 STA_TEST_MAX 时脱离循环？ 您能否解释一下预期的程序执行情况与所看到的内容、以便我能够了解 在设置中看到的是哪一个？

此致、

Delaney

尊敬的 Delaney：

代码看起来非常简单、并且主要按预期工作。

首先请注意、本示例中的所有内容都是针对定制的 执行 问题出现。

循环迭代枚举值、从STA_TEST_START到达时结束STA_TEST_MAX。
如果test_item在内存中监视迭代器,循环成功结束,这完全符合预期。

在循环体中STA_CoreTest(),迭代器作为参数传递给,这是问题出现的地方。 当作为参数传递时、它将从存储器中检索。
令人惊讶的是、执行代码 诸如此类 test_item每次调用STA_CoreTest()其参数时中的值都有 始终 的值 做出响应 。

来自 组件 从代码角度看、数据页指针寄存器DP被加test_item载到访问数据页、变量值被加载到寄存器中AL。
尽管如此,这里的一切看起来都很好,直到一个点:在中间有另一个指令,在累加器(MOVL *+XAR4[6],ACC)中使用先例值,当然从代码优化。 我怀疑的是、中间的指令会在ACC和AL访问上产生流水线争用、并在中产生失败AL的负载。
寄存器AL是右的低16位ACC、在该阶段、这些位始终为零。
请注意、中间的指令是由宏生成的 DEBUG_MARK2_TOGGLE()：它的存在是罪魁祸首。

C 代码是合法的、汇编代码是合法的(显然)、但执行结果与预期不同。

另外需要注意的是、我再次使用最近发布的 CCS 20.1进行了测试、这也带来了 新固件 用于 XDS110调试探针。

问题仍然存在、但似乎也取决于 调试环境 :具有一些不同的断点和/或执行步骤 新品 不同和意外的结果-仍然围绕着这些几个循环体线。

先例行为或多或少是通过循环开头的断点获得的、并使用"汇编越过"步进、但我也看到用 DP 低16位标记的。 是的！

[编辑]

我在第二块(全新)电路板上进行了测试、以确保它不是由 MCU 引起、并且其行为仍然相同。 我开始认为我的问题与 XDS110固件有关。

如何降级 XDS110固件？ 完成 xdsdfu 和来自 CCS 12.8.1的固件( 版本3.0.0.32 )-很遗憾、现在我无法再使用 CCS 20进行调试

[编辑]

我解决了 XDS110固件降级的问题 。

但是、我不会将其标记为已解决：当前和受支持的 CCS 20具有显示该问题的 XDS110固件、唯一的权变措施是使用目前已弃用和不受支持的 CCS 12.8.1

我最初假设的完全错误是、这不是编译器问题、而是 XDS110固件问题。

尊敬的 Luca：

Delaney 目前已离职、下周回来时、她会尽快回复您。

此致、

Allison

尊敬的 Luca：

我在 CCS 12.8.1上测试了代码、想这就是我没有看到任何问题的原因。 您能否 在 CCS 20上尝试一下以确认这是一个仿真问题：

1. 使用路由到 UART 转 USB 桥接器的 GPIO 在工程中初始化 SCI 实例(您可以通过 SysConfig 轻松实现此目的)
2. 在 STA_CoreTest 函数中：您是否可以将项变量转换为 uint16_t、向其中添加48 (将其转换为 ASCII)并通过 SCI 发送字符？ -告诉我,如果你需要这方面的帮助所有/示例代码

如果您在单步执行代码时看到传递到函数中的 Item 变量为0、但 COM 端口正确发送实际值、则这属于与 JTAG/CCS 相关的问题。 如果 SCI 传输的数据也显示为0、则问题出在器件上的实际代码中。

此外、请注意、当单步执行代码时、请确保在"Register"视图中打开"Continuous Refresh"、以确保屏幕上的寄存器持续更新。 这可能是您看到将值0写入 AL 寄存器的原因。

此致、

Delaney

尊敬的 Luca：

好的、我现在将关闭此主题、但如果您在另一个 MCU 上看到问题、请告诉我、如果您有任何其他问题、请随时发布新主题。

此致、

Delaney