This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[参考译文] AM620-Q1:在 RPMSG 通信过程中、SOC 侧偶尔无法接收从 M4 发送的数据。

Guru**** 2439710 points


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

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1536312/am620-q1-during-the-rpmsg-communication-process-the-soc-side-occasionally-fails-to-receive-data-sent-from-the-m4

器件型号:AM620-Q1


工具/软件:

在 RPMSG 通信过程中、SOC 侧偶尔无法接收从 M4 发送的数据。 从仅 MCU 模式睡眠中唤醒后、该问题会更加频繁。

观察到的现象是:

1、SOC 侧可以正常发送数据、M4 可以接收数据、

2.从 M4 发送的数据不会被 SOC 端接收。

我们使用的是 选择 每 3 秒监视 RPMSG 文件描述符 (FD) 的函数、该函数始终返回值 0、这意味着达到 3s 超时。

可通过执行以下命令来恢复通信:


echo stop > /sys/class/remoteproc/remoteproc0/state

echo start > /sys/class/remoteproc/remoteproc0/state

请帮助分析此问题的根本原因。

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

    您好:

    对此处延迟的回复表示歉意。

    1) 您是否解决了问题、还是仍在调试?

    2) 这是否与其他涉及低功耗模式循环测试的 e2e 线程相关、有时在从低功耗模式恢复后、M4F 停止响应来自 Linux 的低功耗模式转换消息? 或者这与不同的测试相关吗?

    3)“从仅 MCU 模式睡眠唤醒后、此问题变得更加频繁。“ 请告诉我更多关于这个问题的信息。 该问题是否仅在进入仅 MCU 低功耗模式、然后重新退出低功耗模式后才会发生? 或者、该问题有时是否会在正常 Linux 运行时发生、而没有进入低功耗模式?

    4) 在 M4F 内核进入不良状态之前、您做了什么来调试其正在执行的操作?

    此致、

    Nick

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

    您好、 Nick:

     1)。 我们仍在调试

     2)。 调试测试仍然是   低功耗模式循环测试、但我们仅使用 MCU、当发生此情况时 、我们可以看到最后一次唤醒没有执行、但我们使用 USB0 来唤醒它。

     3)。 我们不知道该错误只发生在 MCU only LPM,但在这个测试模式下,发生的速度将上升,很容易重复。

    4)。 我们使用 MCU UART 来查看 MCU 运行状态、它输出正确的信息   

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

    嗨、 Xiao-an

    总结您的问题和背景、

    (1) 电路板仅在正常运行模式 (A53 + M4) 和仅 MCU 模式 (M4) 之间工作。

    (2) 您的电路板有 从 MCU LPM 触发唤醒事件的“多个 WAKUP 源“、如下所示的“两个“源、

    a)。 MCU 代码发送“SOC_triggerMcuLpmWakeup()":“:用于生成 MCU IPC 中断到 DM R5 以从 MCU LPM 唤醒主域。

    b)。 USB I/O:在 Linux dts 中编写相关代码

    关于项目 A)。  我们进行了压力测试、因为我们希望确保 MCU 可以通过 在 MCU LPM 下“每次“发送 RPMsg 唤醒事件 SOC_triggerMcuLpmWakeup () 来唤醒 A53、因此下面将讨论更多内容:

     问题:AM620-Q1:TIFS 超时后仅 MCU 3 分钟复位 

    您的故事:  

    一旦您在 MCU LPM 中发现 A53 无法通过 RPMSG 唤醒事件 (SOC_triggerMcuLpmWakeup) 唤醒、您就会尝试使用 USB I/O 唤醒 A53 (Linux)。

    通过 USB 成功唤醒后、您发现 MCU 中仅 RPMSG TX 成功、但发送到 A53 的 MCU (M4) 失败? 请确认   

    谢谢

    Gibbs

      

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

    嗨、Gibbs:

    >(1)  您的电路板仅在正常运行模式 (A53 + M4) 和仅 MCU 模式 (M4) 之间运行。

         是的。

    > (2) 您的电路板具有 可从 MCU LPM 触发唤醒事件的“多个 WAKUP 源“、如下所示的“两个“源、

         是的。  

    >  通过 USB 成功唤醒后 、您发现 MCU 仅发送 RPMSG TX 成功、但发送到 A53 的 MCU (M4) 失败? 请确认   

         是的、在这几天之后、我们学习了。 我们发现 MCU 在我们的代码中不向 A53 发送消息、因为我们在遇到阻塞调用时没有机会更改 send 标志。

    下面是一些新闻:

     我们发现  出现“ k3-m4-rproc 5000000.m4fss:k3_m4_suspend:等待 rproc 完成事件 的中断“的原因是 MCU 运行状态在以下代码中被阻止:

    status = Sciclient_lpmGetNextHostState(SystemP_WAIT_FOREVER, &nextHostState);

    当我们从 SOC 向 MCU 发送“RP_MBOX_SUSPENT_SYSTEM"消息“消息时、MCU 实际上已收到它、但当 MCU 想要通过调用 SCI API 来获得下一个主机状态时、它无法进入。 因此、MCU   还没有机会 ex可爱 的 SOC_triggerMcuLpmWakeup。 这就是 IPC 无法正常工作的原因。

    因此,也许我们应该 专注于为什么 API “Sciclient_lpmGetNextHostState"真正“真正阻止永远!  

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

    嗨、Xiao-An

    很多的信息要澄清

    分享我观察到的一些信息、

    (1) Pls 确保您完全删除 DTS 中的显示节点、因为按照另一个主题讨论、我怀疑唤醒崩溃(重新启动)“可能“与 DSS 或 GPU 有一定关系、

    您的错误消息如下所示、

    [  537.083419] OF: graph: no port node found in /bus@f0000/dss@30200000/oldi-txes/oldi@0/ports
    [  537.517066] OF: graph: no port node found in /bus@f0000/dss@30200000/oldi-txes/oldi@1/ports

    (2) 在 M4 中、此错误消息不应遵循“平稳关机“、即使我们仍然不知道根本原因。

    k3-m4-rproc 5000000.m4fss: k3_m4_suspend: timedout waiting for rproc completion event

    (3) 如何确保 发送的“RP_MBOX_SUSPEND_SYSTEM"消息“消息成功?  是否表示“mail_box_send"没有“没有返回错误?

    static int k3_m4_suspend(struct rproc *rproc)
    {
    	struct k3_m4_rproc *kproc = rproc->priv;
    	unsigned long msg = RP_MBOX_SUSPEND_SYSTEM;
    	unsigned long to = msecs_to_jiffies(5000);
    	struct dev_pm_qos_request qos_req;
    	struct device *dev = kproc->dev;
    	int ret;
    
    	kproc->suspend_status = 0;
    	reinit_completion(&kproc->suspend_comp);
    
    	ret = mbox_send_message(kproc->mbox, (void *)msg);
    	if (ret < 0) {
    		dev_err(dev, "PM mbox_send_message failed: %d\n", ret);
    		return ret;
    	}
    
    	ret = wait_for_completion_timeout(&kproc->suspend_comp, to);
    	if (ret == 0) {
    		dev_err(dev, "%s: timedout waiting for rproc completion event\n", __func__);
    		// Set constraint to keep the device on
    		dev_pm_qos_add_request(kproc->dev, &qos_req, DEV_PM_QOS_RESUME_LATENCY, 0);
    		return 0;
    	};
    

    (4) 如何在 Sciclient_lpmGetNextHostState () 中禁用“SystemP_WAIT_FOREVER"?“?

    参考  https://software-dl.ti.com/mcu-plus-sdk/esd/AM62X/latest/exports/docs/api_guide_am62x/group__SCICLIENT__FMW__LPM__IF.html#ga57860e66a2f13065b44e7e255d066d36

    嗨、Nick

    这 是我这边的一个问题、

    (1) 您是否认为仅 MCU LPM 也需要“正常关断“过程? 如果答案是肯定的、如何在代码中进行检查?

    谢谢你。

    Gibbs

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

    您好、Gibbs、

    Linux Remoteproc 驱动程序应向 M4F 发送仅 MCU 低功耗模式消息、然后 M4F 根据该消息执行代码。 我来展示一下运行代码的代码。

    https://github.com/TexasInstruments/mcupsdk-core-k3/blob/k3_main/examples/drivers/ipc/ipc_rpmsg_echo_linux/ipc_rpmsg_echo.c

    在这里、M4F 创建一项任务、等待来自 Linux 的暂停消息、然后开始等待 UART 输入:

    void lpm_mcu_suspend_task(void* args)
    {
    ...
    #if defined(ENABLE_MCU_ONLY_LPM)
        status = SemaphoreP_constructBinary(&gLpmResumeSem, 0);
        DebugP_assert(SystemP_SUCCESS == status);
    #endif
    
        while (1)
        {
            uint8_t nextHostState;
    
            /* Wait for suspend from linux */
            SemaphoreP_pend(&gLpmSuspendSem, SystemP_WAIT_FOREVER);
            ...
             switch (nextHostState)
            {
            ...
    #if defined(ENABLE_MCU_ONLY_LPM)
                case TISCI_MSG_VALUE_HOST_STATE_ON:
                    gbSuspended = 1u;
    
                    /* Print before sending ACK, otherwise IO isolation is enabled while printing */
                    DebugP_log("[IPC RPMSG ECHO] Suspend request to MCU-only mode received \r\n");
                    DebugP_log("[IPC RPMSG ECHO] Press a single key on this terminal to resume the kernel from MCU only mode \r\n");
    
    // this is where we notify Linux that M4F has received the MCU only LPM message
                    IpcNotify_sendMsg(gbSuspendRemotecoreID, IPC_NOTIFY_CLIENT_ID_RP_MBOX, IPC_NOTIFY_RP_MBOX_SUSPEND_AUTO, 1u);
                    lpm_mcu_wait_for_uart();

    您可以在此处查看 M4F 实际从 Linux 接收邮箱消息的位置:

    void ipc_rp_mbox_callback(uint16_t remoteCoreId, uint16_t clientId, uint32_t msgValue, void *args)
    {
        if (clientId == IPC_NOTIFY_CLIENT_ID_RP_MBOX)
        {
        ...
            else if (msgValue == IPC_NOTIFY_RP_MBOX_SUSPEND_SYSTEM) /* Suspend request received from linux during LPM suspend */
            {
                gbSuspendRemotecoreID = remoteCoreId;
    
    // this semaphore is what tells the lpm_mcu_suspend_task that we got the mailbox
                SemaphoreP_post(&gLpmSuspendSem);
            }

    此致、

    Nick

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

    嗨、Gibbs、

    我们已经澄清了“k3-m4-rproc 5000000.m4fss:k3_m4_suspend:等待 rproc 完成事件的中断“的问题。

    原因是 M4 内核卡在“status = Sciclient_lpmGetNextHostState (SystemP_WAIT_FOREVER、&nextHostState);“。

    我们现在计划将对 ipc_notify 的回复放在回调函数中。

    请问这种方法是否还有其他未知的问题?

    为什么 R5 内核不回复来自 M4 内核的请求?

    谢谢

    void ipc_rp_mbox_callback(uint16_t remoteCoreId, uint16_t clientId, uint32_t msgValue, void *args)
    {
         if (clientId == IPC_NOTIFY_CLIENT_ID_RP_MBOX)
        {
            if (msgValue == (uint32_t)IPC_NOTIFY_RP_MBOX_SHUTDOWN) /* Shutdown request from the remotecore */
            {
                gbShutdownRemotecoreID = remoteCoreId;
                trigger_shutdown();
    			IpcNotify_sendMsg(gbSuspendRemotecoreID, IPC_NOTIFY_CLIENT_ID_RP_MBOX, IPC_NOTIFY_RP_MBOX_SUSPEND_ACK, 1u);
            }
            else if (msgValue == (uint32_t)IPC_NOTIFY_RP_MBOX_SUSPEND_SYSTEM) /* Suspend request from Linux. This is send when suspending to MCU only LPM */
            {
            	SUSPEND_cnt++;
            	gbSuspended = 1U;
                gbSuspendRemotecoreID = remoteCoreId;
                SemaphoreP_post(&gLpmSuspendSem);
    			IpcNotify_sendMsg(gbSuspendRemotecoreID, IPC_NOTIFY_CLIENT_ID_RP_MBOX, IPC_NOTIFY_RP_MBOX_SUSPEND_AUTO, 1u);
    			DebugP_memLogWriterPause();
            }
            else if (msgValue == (uint32_t)IPC_NOTIFY_RP_MBOX_ECHO_REQUEST) /* This message is received after resuming from the MCU only LPM. */
            {
            	gbSuspended = 0u;
            	REQUEST_cnt++;
                IpcNotify_sendMsg(remoteCoreId, IPC_NOTIFY_CLIENT_ID_RP_MBOX, IPC_NOTIFY_RP_MBOX_ECHO_REPLY, 1u);
                DebugP_shmLogWriterResume();
            }
        }
    }
    
    
    void lpm_mcu_suspend_proc(void)
    {
        int32_t status;
    	static uint8_t InitFlag = 0U;
    	uint8_t nextHostState;
    
    	if (InitFlag == 0U)
    	{
    		status = SemaphoreP_constructBinary(&gLpmSuspendSem, 0);
    	    DebugP_assert(SystemP_SUCCESS == status);
    	    status = SemaphoreP_constructBinary(&gLpmResumeSem, 0);
    	    DebugP_assert(SystemP_SUCCESS == status);
    		InitFlag = 1U;
    	}
    
    	/* Wait for suspend from linux */
    	status = SemaphoreP_pend(&gLpmSuspendSem, SystemP_NO_WAIT);
    	if (status == SystemP_SUCCESS)
    	{
    		status = Sciclient_lpmGetNextHostState(0x50, &nextHostState);
    		if (status != SystemP_SUCCESS)
    		{
    			DebugStr("[IPC RPMSG ECHO] Failed to get next system state. Canceling suspend.\r\n");
    			IpcNotify_sendMsg(gbSuspendRemotecoreID, IPC_NOTIFY_CLIENT_ID_RP_MBOX, IPC_NOTIFY_RP_MBOX_SUSPEND_CANCEL, 1u);
    		}
    		switch (nextHostState)
    		{
    			case TISCI_MSG_VALUE_HOST_STATE_OFF:
    				//IpcNotify_sendMsg(gbSuspendRemotecoreID, IPC_NOTIFY_CLIENT_ID_RP_MBOX, IPC_NOTIFY_RP_MBOX_SUSPEND_ACK, 1u);
    				break;
    
    			case TISCI_MSG_VALUE_HOST_STATE_ON:
    		#if 0
    				gbSuspended = 1u;
    
    				/* Print before sending ACK, otherwise IO isolation is enabled while printing */
    				//DebugStr("[IPC RPMSG ECHO] Suspend request to MCU-only mode received \r\n");
    				// DebugStr("[IPC RPMSG ECHO] Press a sinlge key on this terminal to resume the kernel from MCU only mode \r\n");
    
    				IpcNotify_sendMsg(gbSuspendRemotecoreID, IPC_NOTIFY_CLIENT_ID_RP_MBOX, IPC_NOTIFY_RP_MBOX_SUSPEND_AUTO, 1u);
    				DebugP_memLogWriterPause();
    		#endif
    				break;
    
    			case TISCI_MSG_VALUE_HOST_STATE_INVALID:
    			default:
    				IpcNotify_sendMsg(gbSuspendRemotecoreID, IPC_NOTIFY_CLIENT_ID_RP_MBOX, IPC_NOTIFY_RP_MBOX_SUSPEND_CANCEL, 1u);
    				break;
    		}
    
    		if (gbShutdown == 1u)
    		{
    			SemaphoreP_destruct(&gLpmSuspendSem);
    			SemaphoreP_destruct(&gLpmResumeSem);
    		}
    	}
    }

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

    您好 Walter、

    我看到在 Sciclient_lpmGetNextHostState () 中、您 用 0x50 替换了 SystemP_WAIT_FOREVER。

    只是为了确认:在“不工作“的情况下、您是否使用了  SystemP_WAIT_FOREVER? 还是使用 0x50?

    此致、

    Nick

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

    您好、Nick、

     在异常情况下、此参数为 SystemP_WAIT_FOREVER。

    谢谢

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

    您好 Walter、

    感谢您的确认。

    现在、我怀疑 DM R5F 中出现了问题

    这让我怀疑 DM R5F 内核正在进入错误状态。 然后 DM R5F 内核没有响应  Sciclient_lpmGetNextHostState ()、因此 M4F 不会响应 Linux 低功耗转换请求。

    让我们仔细检查您的 M4F 代码、以确保

    请通过 Gibbs 将完整的 M4F 测试代码发送给我。 通过这种方式、我可以回顾一下、确保没有任何明显的问题。

    调试 DM R5F  

    Anshu 在此其他主题中发送了一些有关获取 DM R5F 日志的指导:

    https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1534178/am620-q1-mcu-only-3-minute-reset-after-tifs-timeout/5921504

    我们可能还应该检查此故障情况的日志。

    此致、

    Nick

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

    检查 DM R5F 当前状态  

    低功耗模式转换失败后、您是否开始在终端中看到任何关于邮箱通信失败的消息? 如果是、这可能表明 DM R5F 已进入错误状态。 在这种情况下、邮箱消息将失败、因为 DM R5F 没有回复这些消息。

    将 M4F 超时值更改为 0x50 后、您是否仍然看到低功耗模式失败?

    如果 DM R5F 进入错误状态、那么即使添加了超时值 0x50、低功耗模式转换仍将失败。 如果在 M4F 回复后仍看到低功耗模式转换失败、请附加终端输出。

    此致、

    Nick

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

    您好、Nick、

    1.由于信息安全策略,我们无法将整个代码分发到外部。

    在之前的回复中、我已经发布了关键代码修改。

    将 AM62 更改为 0x50 后、AM62 不再卡在“Sciclient_lpmGetNextHostState ()“;

    相反、它可以正常地继续进行睡眠和唤醒周期(包括成功的后续睡眠唤醒应力测试)。

    3.以前、当 RPMSG 通信失败时、我们可以通过使用命令重新启动 M4 来恢复它

    “echo “stop">“>/sys/class/remoteproc/remoteproc0/state(因为 M4 卡在 WAIT_FOREVER 中)。

    但是、现在当 RPMSG 通信失败时、无法再将命令“echo 'stop'>/sys/class/remoteproc/remoteproc0/state “发送到 M4。


    我们尚未连接 R5 串行端口来检查日志。 目前、我们正在测试问题所在位置

    在高温条件下、RPMSG 通信间歇性失败。

    谢谢

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

    您好 Walter、

    设定支持期望

    我理解无法与我们共享 M4F 代码。

    我已经找到并修复了您之前分享的代码片段中的几个问题。 我很紧张,你可能有代码片段中的其他错误 ,你没有分享. 如果问题是由您 未共享的代码引起的、我无法帮助您进行调试。

    将 M4F 超时值更改为 0x50 后、您是否仍然看到低功耗模式失败?  

    我要总结我认为你告诉我的 2) 和 3)。 如果有任何错误、请纠正我:

    *将 M4F 超时设置为 0x50 后、电路板可以无限期地进行睡眠/唤醒周期。 电路板始终能够进入低功耗模式。

    请告诉我更多关于 3 ):回声停止不能再发送到 M4F  

    在与睡眠/唤醒测试相同的测试中是否观察到此情况? 还是另一个测试?

    当 RPMsg 通信失败以及发送“echo stop“命令时、请共享您的终端输出。

    此致、

    Nick

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

    您好、Nick、

    将其更改为 0x50 后、睡眠唤醒故障问题仅显著减少。
    但是、在超过 10,000 个睡眠唤醒周期后、3 分钟后自动复位的问题仍然存在
    (日志在另一个问题中可用)。 我已停止对睡眠唤醒的进一步测试、目前正在测试问题
    rpmsg 中偶尔断开连接的问题。
    谢谢
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好 Walter、

    我懂了。 在其他问题得到解决后、我们可以在稍后循环回到这次讨论。

    “在 RPMsg 中偶尔断开连接“是否有不同的线程? 还是“3 分钟重置“线程?

    此致、

    Nick

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

    您好、Nick、

    这是关于 RPMSG 的概率通信故障的讨论主题。
    之前、由于 MCU SystemP_WAIT_FOREVER 在睡眠唤醒期间卡滞、导致通信失败。
    现在、将其更改为后 0x50、不再出现睡眠唤醒期间 RPMSG 通信故障的问题。
    但是、RPMSG 在正常运行期间自动断开的问题仍然存在、
    在高温条件下重现投影图像的可能性更大。 我们目前正在进行测试以解决该问题。
    谢谢