[参考译文] AM625：如果 SDK8.3 有 49 天崩溃问题

您好、Tony、

我正在与您联系以获取更多信息。

这是否是您需要每天更新的地方、即使我没有取得任何进展？ 或者、如果我能够与相应的开发人员进行对话、您只是想要更新吗？

此致、

Nick

客户申请 TI 会尽快解决该问题、因为这是 TI 的已知问题、没有理由等待。

今天的更新：

我有软件存储库。 在我们解决以下问题之前、我没有时间浏览软件库：

 AM623：V10.00.08 的 TI-Linux-Firmware 源代码

 AM623：RESP 中的 mbox 超时、连续运行 4295312 秒 

如果我在几天内没有提供其他更新、请 ping 此主题。

此致、

Nick

现在可以解决基于 SDK9.2 的 49 天崩溃问题。  

接下来、我们来检查 SDK8.3 是否受到影响。  

还在处理 SDK 8.3 代码。 明天将进行另一次更新。

此致、

Nick

您好、Tony、

我 90%都确定 RTOS SDK 8.3 不会受到 49 天崩溃的影响。 请再给我一天时间进行验证。

请注意、仅当客户使用 RTOS SDK 8.3 中的 DM R5F 固件时才适用。 如果他们使用更高版本的 DM R5F 固件、则该更高版本的固件可能容易受到影响。

过去 2 天的工作总结  

DM R5F 固件“ipc_echo_testb_mcu1_0_release_strip"的“的命名约定实际上来自 IPC 工程的之前 TI-RTOS/PDK 版本、而不是 IPC 工程的 MCU+ SDK ipc_rpmsg_echo_linux 版本。 因此、我怀疑 ti/drv/ipc/examples 下的示例代码是用于生成 DM R5F 固件的代码。

假设这是代码、那么 SDK 8.3 不受 49 天崩溃的影响。 代码中没有超时选项等待 Linux 为 IPC 通信做好准备、只有这样的无限循环：

examples/common/src/ipc_testsetup_baremetal.c
examples/common/src/ipc_testsetup.c

                    while(!Ipc_isRemoteReady(pRemoteProcArray[t]))
                    {
                        TaskP_sleep(10);
                    }

仍在等待验证这是工程  

我的联系人 （能够验证这是否是用于 AM62x SDK 8.3 DM R5F 固件的项目）在过去 2 天里一直在休假。 我希望在星期四上收到他们的回复。

此致、

Nick