[引用 user="user1432743"](如果不包含 math.h，我认为编译将不会通过)

嗯、对于大多数 C 程序来说、情况并非如此。  如果不包含 math.h、编译器将根据参数类型和"默认参数促销"来猜测函数的原型。  您不需要弄清楚这一点；只需在使用数学函数时始终仔细检查您是否包含 math.h。  通过添加编译器选项--diag_error=225可以实现额外的安全性…

>是否确定在核心8上运行的程序的文件调用日志中包含 math.h？
是的。 我已经包含了 math.h。
(如果不包含 math.h、我认为编译将不会通过。)

如果日志在一个内核上正常工作、则它应在所有内核上正常工作。 编译器完全不知道您在哪个内核上运行。

是否确定在内核8上运行的程序的文件调用日志中包含了 math.h？ 您遇到的错误种类与忘记包含 math.h 时可能发生的情况非常相似

我将这一n`t 移至编译器论坛、供专家们评论-O3和-O2之间的行为差异、因为这似乎是库的器件问题。

此致、
Rahul

我将 platform_write 更改为 printf 并使用 CIO 控制台确认了输出。 结果如下。

[仅 printf]
1：0.000000e+00
1：6.931472e-01
2：0.000000e+00
2：6.931472e-01
3：0.000000e+00
3：6.931472e-01
4：0.000000e+00
4：6.931472e…

对于调试、您能否将 platform_write 更改为 printf 并使用 CCS 中的 CIO 控制台来检查输出。 目前尚不清楚 RTS 库中的日志函数是否出现中断、或者是否是 platform_write 导致了该问题。 转到标准 IO 函数将消除该变量。

此致、
Rahul

你好。 感谢你的答复。

>是否所有内核都从同一位置运行 DDR 或 MSMC 存储器中的代码？
是的。 所有内核都从 DDR 运行代码。

>是否已为所有内核启用高速缓存？
否 所有 L2 (SRAM)都是存储器设置。

>能否在 core8上设置断点并在调用 log 函数之前和之后检查 temp 变量的值。
我重新编写了下面的函数并显示了结果。…

所有内核是否都从同一位置运行 DDR 或 MSMC 存储器中的代码？ 是否已为所有内核启用高速缓存？  您能否在 core8上设置断点并在调用 log 函数之前和之后检查 temp 变量的值。

[引用 USER="user1432743"]为什么第二次调用函数时内核8才变为 nan？

计算是否第一次打印正确的值、第二次仅出现此问题？ 我怀疑某些内存损坏问题可能会导致这种情况、因此最好设置断点…

您好！

我已通知 RTOS 团队。 他们将直接在此处发布反馈。

此致、
Yordan

抱歉、最后4行没有意义。

您好！

有关该错误的说明，请访问：

http://software-dl.ti.com/ccs/esd/documents/ccsv7_debugging_jtag_connectivity_issues.html#device-hung 

正如您所知、有几种情况会导致这种情况、但它们都来自器件或内核本身。 通常 ICEPICK JTAG 路由器知道一个内核/器件电源模式和时钟…

Jovana、

您是否已解决问题？

Todd

[更新6/22：我将此标记为 TI 认为已解决、因为海报未回复。]

Jovana、您好！

您是否可以重新构建并将整个构建输出复制/粘贴到文件并附加它？ 请复制所有错误、而不仅仅是上述错误。 这使我们能够查看版本、链路输出等

Todd

已升级到版本7.4.24、这似乎解决了问题。

因为已经有一段时间了，我想你已经解决了这个问题。  非常感谢您的解决。

谢谢、此致、

乔治

您是否升级到 版本7.4.24？  这是否解决了问题？

谢谢、此致、

乔治