[参考译文] PROCESSOR-SDK-AM62X：多核开发、IPC 工艺、多个端点、保留内存用途

1.是的。 请记住、Linux 用户空间不能直接访问 Virtio 缓冲区、它会复制到内核空间中、然后复制到缓冲区中

2、尺寸正确。 这不是"最大"大小、而是 Linux 允许的"唯一"大小

3.有关内存、请参阅多核学院页面。 当前页面在这里、或者如果您需要、我可以复制粘贴我的源代码更新草稿、该草稿将在下周左右发布：  
https://dev.ti.com/tirex/explore/node?node=A__AZgEw2fWxmvPzpRgXlGAMQ__AM62-ACADEMY__uiYMDcq__LATEST

4.基本正确。   有关 MCU 侧的信息、请访问 software-dl.ti.com/.../IPC_GUIDE.html。 Linux 端使用低级邮箱驱动程序-请注意、此时我们不会向用户空间公开邮箱驱动程序、RPMsg 是 TI 支持的唯一 Linux IPC。

除非您正在开发自己的 IPC 协议、否则我不会担心理解所有的低级细节。

此致、

Nick

实际上、这可能是您可以帮助我解决的地方。 我昨天刚刚完成了对整个多内核 IPC 模块的重写。 如果您有兴趣尽早阅读更新的文档并提供反馈、我可以将整个模块附加在此处、保存在 zip 文件中。

大家可以随意访问多核学院中的任何其他页面、它们都将进行大量重写。

-尼克

您好、Nick。

我会尽我所能地帮助你！ 没有计划制定自己的 IPC 协议

1.关于 Linux 允许的"唯一"大小。

->我知道 RTOS/Linux 发送10字节消息与496字节消息的区别吗？  

-> 关于 Linux <->RTOS 通信速度、您有这方面的数字吗？ 我在 Linux 端运行了一个简单的计时器来测量1回声消息传输的速度、Linux -> RTOS -> Linux、测试了10字节和496字节的消息、并且正如预期的那样、496字节消息需要更多的时间。 如果"数据包"大小固定为512、是否不确定时差的发生位置？  

2.我已经查看过有关内存的多内核学院页面。 不知道是否有任何变化,从我上次阅读它.  

->很抱歉、只是想确认一下、我的理解是否正确、即 0x9CC0_1000到0x9DA0_0000可从用户端免费使用？ 我最初担心的是 Linux/RTOS 是否以某种方式使用此地址空间、如果我在其中写入、可能在我不知情的情况下突然发生覆盖。  

3.在 MCU+ SDK 页面中讨论以下几点。 我的理解是否正确、即每个 数据包的最大(或固定)大小为512Bytes、并且最多可保存256条消息？ (256 x 512字节)？  

4.对不起我的好奇心,但跳到我的主要问题

通过修改 rpmsg 样本程序、我尝试从 Linux 发送496字节的消息、而无需等待 RTOS 的任何响应。
我对 RTOS 程序设置了延迟、并希望 RTOS 侧在延迟到期后连续读取这些496字节的消息。  

a. 如果我从 Linux 发送496字节 x 10条消息=没有问题。 RTOS 收到10 x 496条消息、并随后将所有内容回传给 Linux。  

B.但是、如果我发送496字节 x 20条消息、它将不起作用。 我可以知道此器件漏掉了什么吗？

->第一次尝试: 当我发送496字节 x 20消息从 Linux 的第一次尝试,我注意到 RTOS 没有以任何方式响应。 并且 Linux 端程序没有错误。 RTOS 似乎没有检测到任何从 Linux 传入的 IPC RP 消息。 即使我移除了 RTOS 侧的延迟、也会出现相同的行为。

->第二次尝试:当我第二次尝试在 Linux 端运行命令时,下面出现了以下错误,错误105意味着我认为没有足够的缓冲区大小。

我可以知道自己做错了什么吗？ 我最初以为我应该能够发送256个496字节的消息、但在发送20个消息时已经失败了。

C.如何从这种情况中恢复？

您好、Nick、您有没有机会看到我在上面提出的近期问题？

Unknown 说：

如果您有兴趣尽早阅读更新的文档并向我提供反馈、我可以在此处以 zip 文件形式附加整个模块。

我也忘了回复这个问题。 是的、请我有兴趣查看最新更新的文档。 那会很有帮助。

谢谢！

您好、Stephen：

抱歉、时间已用完、无法深入探讨此问题。 邮箱驱动程序具有20条未处理的消息的任意限制、它可以跟踪这些消息-这是一个纯粹的软件结构、如果您需要、驱动程序代码本身可以增加多达256条。 我没有时间调出之前我讨论过的 e2e 线程、但您或许能够找到这些线程？) 使用 google 站点搜索、搜索结果如下：
网址：e2e.ti.com 尼克邮箱"20"消息

正如在另一主题中所讨论的、没有电源或互联网、可能会持续数天。 如果下周我还没有回复、请随意 ping 该主题。

不幸的是,我的文档源代码卡在一台计算机上,我不能访问,而电源是关闭的,所以根据我得到电源恢复的时间,我可能只是指向已发布的产品。

此致、

Nick

你好、Nick、你结束时的艰难情形似乎是这样的。

我认为我找到了您所指的主题：

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1179393/am6442-problem-detecting-rpmsg-mailbox-full-when-communicating-to-r5-core/4618458?tisearch=e2e-sitesearch&keymatch=mailbox%25252020#4618458

您能帮助确认我们可以在哪里对邮箱默认大小20进行修改吗？

我最近进行了一些快速测试、似乎在大约17条消息中出现故障、每个消息有496个字节。 从我的角度来看、这似乎是不一致的。 我们将继续关注这一点。

1.你有什么想法如何从这种情况中恢复? 包括 Linux 和 RTOS 两侧。

2.另外,我注意到,有一些实例表明 Linux 端(内核和用户空间应用)没有错误,但我没有从 M4 RTOS 端( rpmsg_receive)函数不返回任何响应,当发送大约~20条消息。 行为因实际消息长度(10字节或496字节)而异。 你对 RTOS 方面发生的情况有什么想法吗？

您好、Stephen：

这就是线程！ 尝试"将 include/linux/mailbox_controller.h 中的 MBOX_TX_QUEED_LEN 值增加到256"并查看会发生什么情况。

有关初始调试指导、请查看多核 Academy 的应用开发>调试部分。

我当前的连接不足以加载学院草稿的 zip、因此现在请参阅  
https://dev.ti.com/tirex/explore/node?node=A__AVn3JGT9fqm0PbS.pegO-g__AM62-ACADEMY__uiYMDcq__LATEST

此致、

Nick

您好、Nick。

感谢您的确认。 我会检查一下。

1.作为关于上述问题的更新,(从 Linux 发送连续消息时 RTOS 挂起)

我执行了进一步的测试并注意到以下情况：

RTOS 在发送17条消息后挂起、每条消息的大小为10个字节。

在查看驱动程序代码时、我在｛SDK｝/source/drivers/ipc_rpmsg 的 ipc_rpmsg_priv.h 下看到了此代码

如果我使用 RPMessage_recv ()函数(非回调)实现,这意味着在队列中有16条消息的限制? 发送17会导致程序挂起？

除了邮箱限制20外、RTOS 侧的 Vring 数据可以读取、但有限制16吗？  

鉴于这些点,它看起来是不可能的队列256条消息..  

如果我的理解有误、请纠正我。 谢谢！

P.S.我在使用回调功能时观察到很多情况、但我对 IPC Comms ISR 的工作原理感到困惑。 我可能会就此打开一个单独的话题。

您好、Stephen：

嗯、这是一个好问题。 我假定大家可以简单地将数量增加到256、但直到现在我才知道这段代码。 让我将您的线程重新分配给一位更熟悉代码库的 MCU+端的团队成员。

如果确实必须手动更改驱动程序以便在远程内核的 RX virtio 缓冲区中启用超过16条消息、我们肯定需要将其记录在某个地方(我不记得 SysConfig 的 IPC 设置需要更改 virtio 缓冲区数量上的任何内容、但我可能会记错)。

此致、

Nick

嗨、Nick。  

我最初应该问如果我在 RP 消息中创建多个端点、256消息队列会发生什么情况。 但它看起来像我被其他因素缠住了瓶子。  

在我们的应用中、我们期望 M4和/或 A53内核相互发送多个数据、而且我想知道单向发送消息的最大队列、假设 A53或 M4 (接收端)在处理数据时会延迟。

例如、M4将  连续向 A53发送 X 条消息 、而 A53不会在两者之间发送 ACK 消息。 M4可以发送多少个而不丢失数据/程序错误/挂起？ (__LW_AT__(反之亦然)

我知道在不同的线程中可以看到批量数据传输的零拷贝、但对于本例、我们认为从 M4 RTOS 到 A53 Linux 的实时数据反射、反之亦然。

1.您能帮助确定发送消息的最大队列吗? 一旦超过此值,我假设数据丢失/程序错误等?

->[Linux 到 RTOS]和[RTOS 到 Linux]

请帮助确认以下内容是否正确

2.我的理解是否正确、每发送一封邮件、还输入一封邮箱邮件？

即 VRING = 1邮箱消息中存储了1个496字节的消息？

如果您知道 RTOS 和 Linux 之间用于反映*实时数据*的任何其他实现、请告诉我。 目前我们认为、如果在 Linux 和 RTOS 两端都运行多个任务、一旦消息处理延迟、16条消息队列就会太小

感谢您一如既往的支持！

尊敬的 Stephen：

我将在内部与专家讨论这一点。 稍后我们将向您提供更新。

此致、

Nitika

嗨、Nitika、  

很抱歉、请允许我检查我们是否有有关上述查询的更新？  

谢谢你

尊敬的 Stephen：

对于您的查询出现延迟、我们深表歉意。

该团队一直忙于商务旅行和其他承诺。 我正在查看您的问题、我们会尽快回复您。

此致、

Nitika

嗨、Nitika、

我也运行了多个测试来检查这个问题。 下面是连续发送邮件时得到的结果。  

1. Linux -> RTOS :最大队列为16

2. RTOS -> Linux :没有限制? 我已超过256条消息、但 Linux 端仍然可以收到...  

下图适用于 Linux -> RTOS 情况。 Linux 连续向 RTOS 发送消息、其间没有任何确认/延迟。 一旦我从 Linux 连续发送17条消息、RTOS 就卡在 ISR 内部。

我修改了如下驱动程序代码、只是为了测试我的理解是否正确。 主要目标是在队列满为16之后退出 ISR、并让接收任务运行以在 pMsg 缓冲器内释放空间。

->在 RPMessage_recv 内部,有很多中断禁用/启用代码被调用,我注释掉了一切,以避免与任务输入关键/退出关键的冲突。

一旦我使用下面修改的代码、我就可以接收 超过16条的消息。

此外、在 不修改驱动程序代码的更简单的方法中、如果在 Linux 端、我们每发送16条消息后设置一次延迟、那么 RTOS 可以处理数据、并且我们可以避免 RTOS 端的"ISR 卡滞"问题。

您能否验证上述理解是否正确？

尊敬的 Stephen：

我在软件开发团队中验证了这一点。

Unknown 说：

这意味着队列权限中最多有16条消息？

是的、值16是默认的最大接收消息数(一次可以未完成)、由于确认机制已删除、因此数据未以接收数据的速度进行处理、从而导致出现故障。 可以将此值增加到256。

Unknown 说：

使用下面修改后的代码后、我可以收到 超过16条的消息。

信标实现是处理问题的一种方法。

您能否将 RPMSSAGE_MAX_LOCAL_MSG_OBJ 增加到256 (或 SysConfig 中设置的 Vring 中的缓冲区数量)并检查它如何影响 RTOS 挂起问题？

此致、

Nitika

Unknown 说：

您能否将 RPMSSAGE_MAX_LOCAL_MSG_OBJ 增加到256 (或 SysConfig 中 Vring 中的缓冲区数)并检查它对 RTOS 挂起问题有何影响？[/QUOT]

嗨、Nitika、  

如果我错了、但上面的陈述基本上是2件正确的事情、请回答我。 一个是驱动程序修改、一个是 SysConfig 修改...

1.驱动器侧:我把 RPMESSAGE_MAX_LOCAL_MSG_OBJ 增加到256 ,似乎 RTOS 可以按预期处理超过16条消息。

2. SysConfig side：在 syscfg 中设置 vring 缓冲区大小不起作用(问题仍然存在)。 尽管我不再使用调试器进行检查、但在发送超过16条的消息时、RTOS 程序没有响应。 以下是 SysConfig 设置。 不确定 PDK IPC 的用途是什么、但我也尝试了切换。 没有影响。

顺便说一下、我对上述设置感到非常困惑(注意：我不在当前设置中使用上述设置、而仅使用上述设置来测试您的建议)。 如上图所示设置 syscfg 将在生成的 ti_drivers_config.c 文件中添加以下内容

在链接器中需要以下内容：

然而、下面的线程提到 IPC VringMem 不用于 Linux IPC 案例(syscnfg 已生成它)？？

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1289485/sk-am62-reissuing-load-m4-firmware-generate-from-mcu-rtos-sdk

我在工程中使用的配置设置如下所示。 我是否可以知道在没有 R5 IPC 通信的情况下设置 RTOS <->Linux IPC 时的设置是否正确？

尽管针对上述 A53禁用了 IPC、但 RP 消息通信可与 Linux <-> M4 RTOS 配合使用。  

这意味着无法从 SysConfig 端将 RPMSG obj 从16调整到256、并且需要重新编译驱动程序。 我的理解是否正确？ 目前、无论我从 SysConfig 端执行什么操作、从 Linux 发送超过16条连续消息时、RTOS 都会挂起。  

希望您能确认上述理解？ 谢谢你

尊敬的 Stephen：

您的理解是正确的。 很抱歉我误解了我的回复、如果 MCU+内核之间 不需要通信、则 Nick 的回复是正确的 IPC_VLING_MEM。

Unknown 说：

尽管针对上述 A53禁用了 IPC、但 RP 消息通信仍可用于 Linux <->M4 RTOS。

是的、对于仅涉及 Linux 的 IPC、启用"Linux A53 IPC RP Message"选项就足够了。 您以上共享的最后一项 SysConfig 设置足以用于 Linux <->M4 RTOS IPC。

您能否说明一点、如果使用上述最后一项 SysConfig 设置、请将 RPMSSAGE_MAX_LOCAL_MSG_OBJ 修改 为256、重新构建驱动程序和示例并再次测试。 您仍然观察到 CPU 挂起吗？

此致、

Nitika

嗨、Nitika、

感谢您确认设置。

Unknown 说：

您可以澄清一点、如果您使用上述最后一项 SysConfig 设置、请将 RPMSSAGE_MAX_LOCAL_MSG_OBJ 修改 为256、重新编译驱动程序和示例并重新测试。 您是否仍观察到 CPU 挂起？

在不同的测试设置中、是的、我仍然可以遇到在 M4侧挂起的问题。  

用于测试目的：

答：我曾尝试从 Linux 发送1000条突发消息、RTOS 可以处理。 未遇到挂起。 但是、在这种情况下、除了 RPMsg 接收任务之外、在 RTOS 端没有其他任务运行。

b.由于我们刚刚增加了缓冲区大小、但驱动器侧没有变化以处理缓冲区满情况、因此我尝试了通过在 RTOS 侧添加延迟来模拟填充256个温度缓冲区。

我将 M4置于 ClockP_SLEEP 状态、然后在睡眠期间从 Linux 发送500条消息。 Linux 暂时停止以256发送消息(可能是因为 vring 缓冲区已满？)。 RTOS 退出 ClockP 睡眠模式后、Linux 恢复发送、然后 在出现第333条消息时突然停止。 RTOS 端似乎也停止了响应。

尽管上述测试有些强制、但我不确定 多个任务运行后、"实际"应用程序会产生什么影响。 我认为、基于驱动程序代码发生缓冲区已满情况后、挂起的风险仍然存在。

请问 TI 对此有何立场？ 这是否作为问题通过、TI 将计划解决？  

像往常一样、如果我最后有任何错误、请告知我。 感谢您的支持！

你好、Nitika、有任何有关这方面的更新吗？ 谢谢你

尊敬的 Stephen：

我试图在我的终端重现您的问题、以查看这是否作为错误传递。

如果可能、您可以共享正在运行的测试代码、也可以突出显示您所做的更改、以便我在结束时也可以对其进行比较。

此致、

Nitika

嗨、Nitika、  

我已经上传了基于原始示例项目的示例文件。 我们基本上使用了 IPC Linux echo 示例+ rpmsg 示例项目、仅删除了"echo"部分、并添加了一些调试日志。

请参阅随附的 zip 文件。 谢谢！

e2e.ti.com/.../ti_5F00_ipclimit16.zip

尊敬的 Stephen：  

感谢您共享文件。

这些 将有助于重现问题、并将很快更新结果。

此致、

Nitika

你好、Nitika、有任何有关这方面的更新吗？  

您是否至少能够重现该问题？

谢谢！

您好、Nitika、很抱歉跟进、但您对此有任何更新吗？  
谢谢你

尊敬的 Stephen：

对此延迟深表歉意。

我上周没有到货、在接下来的几周也将无法到货。

我已将您的问题发送给另一位处理该问题的专家。 请允许他们留出一些时间来与您联系。

此致、

Nitika

嗨、Nitika、

明白了。 将等待有关此方面的更新。  

尊敬的 TI 团队：

有任何相关更新？

您好、Stephen：

Unknown 说：

关于此问题的任何更新?

对延迟响应深表歉意。

我们的设置中面临一些问题。 专家目前不在办公室。 请在下周结束前回复。

感谢您的耐心。

此致、

Tushar

您好、TI 专家！如果有机会我们可以对此提供一些更新、  
谢谢！

您好、Stephen：

感谢您的耐心。

Unknown 说：

a. 我尝试从 Linux 发送1000条突发消息、RTOS 可以处理它。 未遇到挂起。 但是、在这种情况下、除了 RTOS 端的 RPMsg 接收任务外、没有其他任务在运行。[/QUOT]

我们了解到、 将  RPMESSAGE_MAX_LOCAL_MSG_OBJ 修改为256后、如果除了 IPC 外没有其它任务在 RTOS 端运行、这个问题不会在理想情况下重现。

[报价 userid="606578" url="~/support/processors-group/processors/f/processors-forum/1365362/processor-sdk-am62x-multicore-development-ipc-process-multiple-endpoints-reserved-memory-purpose/5254590 #5254590"]我将 M4置于 ClockP_Sleep 状态、然后在睡眠期间从 Linux 发送500条消息。 Linux 暂时停止以256发送消息(可能是因为 vring 缓冲区已满？)。 RTOS 退出 ClockP 睡眠模式后、Linux 恢复发送、然后 在出现第333条消息时突然停止。 RTOS 端似乎也停止了响应。

我们正在 分析这种情况、即在 RTOS 端添加等待、Linux 持续向 RTOS 发送消息。 我们能够复制 M4F 挂起问题、内核返回超时错误、如下图所示。

我们使用 ClockP_SLEEP () API 添加了 M4F 内核进入睡眠2秒的代码。 当内核接收到总共200条消息时、它会进入休眠状态2秒。 我尝试发送了10000条突发消息,核心在1877条消息挂起。

您是否也遇到了如上所示的相同问题？

此致、

Tushar

您好 Tushar、您上面发布的错误与我遇到的错误相同。  

虽然在我们的例子中,程序的顺序如下。  

1.M4F =睡眠5秒(ClockP_SLEEP)

2. linux =发送500条消息(在 M4F 睡眠期间)

3. Linux =在256条消息后暂时停止发送(我认为由于缓冲区已满而暂停)

4. m4F =从睡眠中唤醒

5. linux =自动恢复发送消息

6. linux =突然停止发送第333条消息

7. m4F =已检查状态并已挂起

谢谢！

您好、Stephen：

感谢您的确认并提供以上详细信息。

Unknown 说：

M4F =休眠5秒(ClockP_SLEEP)

您能说明一下该睡眠是在哪里实施的吗？ 当我们在 RTOS 端接收20条消息时、是否会调用该函数？

我可以看到、M4F 内核能够在一段时间后但 Linux 发出超时错误之前恢复。  我 仍在进行调试、很快会更新。

此致、

Tushar

尊敬的 Tushar：

抱歉、我的错。  

M4F =休眠40秒(ClockP_SLEEP),以便有足够的时间执行 Linux 命令来发送500条消息。  

放置方式如下所示。

在从 Linux 端接收任何消息之前、我将 M4F 置于睡眠状态 目的是模拟在驱动程序代码中填充临时缓冲区、以查看发生了什么情况。

Task function()
{

    /* some code */
    
    ClockP_sleep(40);
    
    /* send message from Linux during sleep duration */
    
    while(1)
    {
        RPMsg_recv();
    }

}

谢谢！

尊敬的 Tushar：  

有任何相关更新？

谢谢！

Tushar、您好！  

从 Linux 端提供一些注释、如果您的"等待 TX 缓冲区超时"端等待发送 RPMsg 已等待15秒、但仍然没有可用的缓冲区可供其使用、则 Linux 行为符合预期。 因此这表明远程内核已停止运行15秒。

代码位于 drivers/rpmsg/virtio_rpmsg_BUS.c、函数 rpmsg_send_offchanne_raw

此致、

Nick

您好、Stephen：

对这里的持续拖延深表歉意。 让我们看看我们能否在您这边的调试工作上取得一些进展。

Tushar 将此信息脱机发送给我：

VRING 缓冲器满后、M4F 将进入循环而绝不退出循环。
代码 M4F 此时执行的代码如下所示。

/* check full ring */
            while((RPMessage_vringIsFullRxBuf(remoteCoreId) != 0U))
            {
                RPMessage_recvHandler(remoteCoreId);
            } 

由于 Linux 停止发送消息、这必须意味着 vring 将保持满。 因此、我假设问题不是 while 环路条件(即 RPMessage_vringIsFullRxBuf 可能按预期工作)。 问题必须出现在接收处理程序中。

我能否让您在程序挂起后将 CCS 连接到 M4F 内核、并单步执行代码以确切地查看正在执行哪些指令？ 例如、如果 RPMessage_allocEndPtMsg 无法分配消息指针、则该函数将退出。 通过 CCS 调试远程内核的步骤记录在以下位置： https://dev.ti.com/tirex/explore/node?node=A__AfR2ju5RKoCJDj50kzWghg__AM62-ACADEMY__uiYMDcq__LATEST

此致、

Nick

您好、Nick。  

很抱歉我们已经在一周长的假期里迟到了回复。  

我已经在使用连接到 CCS 的 EVM 进行调试、所以我们  能够检查并单步执行代码、以查看程序卡住的地方。 先前文章中发布的上述信息 是我在使用 CCS 进行调试时详细调查的结果。  

对此我很抱歉、但我之前发布的图片(幻灯片)中的信息旨在解释您提出的这种情况。 (具有原始代码和修改后的代码比较的代码)。 如果在这方面有什么不明确的地方、请告知我。

1.我不确定 Tushar 的设置、但如果  将 RPMSSAGE_MAX_LOCAL_MSG_OBJ 设置为[16]与[256]、程序行为会有很大的不同。 如果值设置为16、则无法离开 ISR 的问题很容易复制。

这就像[任务上下文从 allocEndPtMsg]使用的温度缓冲区提取数据]与[ allocEndPtMsg 使用的温度缓冲区在 ISR 上下文中存储数据时变满]之间的竞态条件。

2.  

Unknown 说：

由于 Linux 停止发送消息、这必然意味着 vring 将保持满。

我对此也有同样的理解。

3.  

Unknown 说：

如果 RPMessage_allocEndPtMsg 无法分配消息指针、则该函数将直接退出。

我认为这就是问题所在。

此处讨论了2个缓冲器的主题。 VRing 缓冲区 设置为256、将 RPMSSAGE_MAX_LOCAL_MSG_OBJ 设置为16。

RPMessage_vringIsFullRxBuf 检查大小为256的 VRING 缓冲区

RPMessagerecvHandler -> RPMessage_allocEndPtMsg 使用 大小为16的 RPMSSAGE_MAX_LOCAL_MSG_OBJ。  

如果 VRING 未满、而仍有数据要提取、但 allocEndPtMsg 内的温度缓冲区已满、则会发生该问题。

RPMessage_vringIsFullRxBuf 循环不会退出、因为 VRING 缓冲区中仍有尚未拉取的 数据、但 RPMessage_allocEndPtMsg 无法再存储任何数据、因为大小为16的温度缓冲区已满； 这会导致无限循环、一旦发生这种情况、就无法中断循环。

正如我在编号1中提到的、程序行为会因温度缓冲区大小而异。 然而,问题仍然是相同的,这种情况下,一旦发生,就没有办法/没有逻辑退出无限循环。

我们希望知道的是、如果这被确认为 SDK 中的错误、TI 将在将来发布修复？  

谢谢！

您好、Stephen：

啊、在我找到你在这里讨论的图形之前、我必须重新阅读整个线程两次：
https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1365362/processor-sdk-am62x-multicore-development-ipc-process-multiple-endpoints-reserved-memory-purpose/5246973#5246973

这是对行为的总结。 我将我们的开发者具体指向您的图形和您的最新回复、并请他们给出他们的想法。

对于未来的读者、我还将重申 Stephen 的观点、即增大 RPMSAGE_MAX_LOCAL_MSG_OBJ 并不能解决这个问题：
https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1365362/processor-sdk-am62x-multicore-development-ipc-process-multiple-endpoints-reserved-memory-purpose/5254590#5254590

无论  RPMSSAGE_MAX_LOCAL_MSG_OBJ = 16还是256、都会出现这一行为。 问题在于、无论缓冲区的大小如何、如果 RX 缓冲区变满后又有另一条消息进入、 则 ISR 无法将 RX 缓冲区中的消息清空、并且它会进入无限循环。

此致、

Nick

您好、Nick。

Unknown 说：

啊、在我找到您在这里谈论的图形之前、我必须重新阅读整个线程两次：

对不起,但是的,这是我指的职位!

以上所有的解释都与我们目前的理解完全相同。 很棒、我们很赞同这个！

请务必告知我们开发团队是否有任何更新、以及未来是否会对此采取任何措施。  

感谢您的支持！

尊敬的 Stephen：

感谢您的耐心。

我已针对上述问题提交了内部 Jira 工单、可能会在即将发布的 SDK 版本(即 v10.1)中进行修复。

此致、

Tushar

Tushar ,尼克:

 当我们说到 SDK v 10.1时、请确保也将其包含在 AM64X 上。

谢谢

吉姆

尊敬的 Jun：

Unknown 说：

当我们说到 SDK v 10.1时、请确保也将它包含在 AM64X 中。

谢谢提醒。

我还在 Jira 工单中添加了 AM64x。

此致、

Tushar