[参考译文] AM2634：IPC 在回调时挂起

admin

Other Parts Discussed in Thread: SYSCONFIG

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1361411/am2634-ipc-hangs-on-callback

器件型号：AM2634
主题中讨论的其他器件：SysConfig

我将结合使用 IPC 与 SDK 8.6及 syscfg 1.19.0。

IpcNotify_ISR()中的代码存根在产生大量 IPC 流量时完成。 RPMessage_notifyCallback()试图处理来自 RxBuf 的消息，但 RPMessage_vringIsFullRxBuf 总是返回 true，但在 RPMessage_recvHandler 中，RPMessage_allocEndPtMsg 总是返回空。是什么导致了这个无限循环？

我们将使用2个锁步内核、这是 IPC 的 syscfg 配置：

谢谢

亚历山德罗

1 年多前

0 admin 1 年多前

TI__Guru**** 2539500 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

您好！

请检查 sdk_examples\drivers\ipc\ipc_rpmsg_echo 中的 IPC_rpmsg_echo 示例。它正在发送 100000u 条消息。
有多少条消息导致了此问题？

此致、
贡詹

0 admin 1 年多前

TI__Guru**** 2539500 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

我们使用该示例作为设计的参考。问题不是消息数量、而是突发速率。我们面临的问题是我们在一段时间内拥有较高的比率。问题是：什么导致 RPMessage_allocEndPtMsg 返回空指针？

0 admin 1 年多前

TI__Guru**** 2539500 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

您好！

能否谈谈此问题是什么突发频率导致的、以便我可以重现和调试。

谢谢。
贡詹

0 admin 1 年多前

TI__Guru**** 2539500 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

我能够用 rpmsg 示例的修改版本重现问题。在示例中、我将仅使用2个内核并修改了 syscfg、如下图所示：

如果我暂停所有内核而不是恢复、则会出现问题、这似乎是同步问题。在我们的项目中、即使不进行调试也会出现问题、但在本例中、我仍然无法重现同步。

e2e.ti.com/.../ipc_5F00_rpmsg_5F00_echo.c

最后但同样重要的是、我们使用的是已修补的 SDK、其中 IPC_rpmsg.c ipc_rpmsg_priv.h 和 IPC_rpmsg_vring.c 文件根据 TI 建议进行修改、以避免出现另一个错误。

e2e.ti.com/.../3652.ipc_5F00_rpmsg.ce2e.ti.com/.../3652.ipc_5F00_rpmsg_5F00_priv.he2e.ti.com/.../3652.ipc_5F00_rpmsg_5F00_vring.c

0 admin 1 年多前

TI__Guru**** 2539500 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

您好！

我仔细检查了您在该 E2E 中提供的代码。
根据 AM263X TRM ： 在之前发起的邮箱与同一接收方的交互完成之前，发送方不得向同一接收方发起另一条消息。"
您能否重新检查您的高突发率是否遵循此条件？

谢谢。
贡詹

0 admin 1 年多前

TI__Guru**** 2539500 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

我认为这是 SDK"RPMessage_send"函数的负责人、不是吗？

0 admin 1 年多前

TI__Guru**** 2539500 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

您好 Alessandro：

很抱歉延迟回复。我已经尝试在最后复制您的设置。
我的更改：
1.在结束时复制了全部4个内核中的 ipc_rpmsg_echo.c。
2.使用 SysConfig 禁用内核1和内核3的 IPC。
3. RP 报文缓冲区数目=16

在这些改变后,我也被卡住在"RPMessage_allocEndPtMsg 返回一个空指针",并试图知道它的原因。
但在调试过程中、我会注意到 core1和 core3还尝试使用 ipc_rpmsg_echo.c 的代码向其他内核发送消息。然后、我发现这两个内核都假定自己为 core0 ( gIpcNotifyCtrl.selfCoreId=0的默认值)、在本例中、3个内核充当 main_core。为了避免这个问题、我将 core1、core3的代码更改为不启动消息传输。

禁用 core1和 core3的消息传输后，core 0正在尝试向 core 2发送消息，并且在终端中收到以下警告："WARN: RPMessage_SEND:294:[IPC RPMSG] Message send to remote core 2 @ 13 end point failed.

我假设发生这种情况是因为突发速率很高。这些是我的观察结果、希望它能有所帮助。

谢谢、此致、
贡詹

0 admin 1 年多前

TI__Guru**** 2539500 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

您好、Gunjan、

您是对的、由于传输速率高、您看到的警告消息是意料之中的。

在我们的代码中、只有两个采用锁步配置的内核、因此内核0_1与内核0_0处于锁步模式、内核1_1与内核1_0处于锁步模式、因此问题不是由 IPC 的错误配置引起的。此外、在修改后的示例项目中、我在从调试配置中加载内核0_1和内核0_0时禁用了该功能。

在修改后的示例中、您是否尝试暂停内核并再次重新启动它以创建一点去同步(以完全异步的方式从一个内核传输到另一个内核以及相反方式传输数据)？您是否尝试过提高费率？

此致

亚历山德罗

0 admin 1 年多前

TI__Guru**** 2539500 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

您好 Alessandro：

我最终能够重复这个无限循环的问题。
这似乎是一个有效的问题、并且在缓冲器由于高突发速率而填满时会发生。我提出了一个内部 JIRA 错误来修复此问题。在当前示例中、每当收到 IPC 消息时、它都会存储在缓冲区中(如果缓冲区中有任何空间)、后续应用程序会检查该缓冲区以处理消息。当缓冲区已满时、您会卡在无限 while 循环中。
目前、您可以使用 SysConfig 更改 RP Message Number of Buffers=8。
或降低突发速率。
或者、通过注册在接收 IPC 消息时调用的处理程序、将应用切换到回调模式、而不是在接收消息时存储在 vring 缓冲区中(供稍后处理)。您可以参考以下代码和 IPC_NOTIFY 示例。

RPMessage_CreateParams_init(&createParams);
createParams.localEndPt = gServerEndPt;
createParams.recvCallback = echocallback;
status = RPMessage_construct(&gServerMsgObject, &createParams);
DebugP_assert(status==SystemP_SUCCESS);

谢谢、此致、
贡詹

基于 Arm 的微控制器（参考译文帖）

基于 Arm 的微控制器（参考译文帖）(Read Only)

[参考译文] AM2634：IPC 在回调时挂起