请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
主题中讨论的其他器件：SK-AM62-LP
你好, Gibbs、
我们已经解决了 MCU 无法在仅模式下控制 IO 的问题。
接下来、请优先解决 MCU 唤醒 soc 并导致 IPC 崩溃和自动重启的问题
谢谢
你好, Gibbs、
我们已经解决了 MCU 无法在仅模式下控制 IO 的问题。
接下来、请优先解决 MCU 唤醒 soc 并导致 IPC 崩溃和自动重启的问题
谢谢
您好 Walter、
我们需要有关您正在测试的内容的更多信息。 以下是我目前所了解到的详细信息：
Anshu 告诉我、您使用此 Linux 脚本运行测试：
while true; do echo mem > /sys/power/state; done;
根据该输入、我假设您显示的终端输出分成几个唤醒/暂停周期、如下所示：
我们可以从输出“fifo 1 有意外的未读消息“验证 M4F 是在上图中的#2 期间未读取邮箱消息的用户（即，不是 Linux）。
如果有人想要仔细检查我们如何验证“fifo 1“是什么意思的思考过程,我将附加相关代码片段。
// from devicetree files
// FIFO 1 is used for transmitting signals from Linux to M4F
// mbox-m4-0 > ti,mbox-tx = <1 0 0>;
mailbox0_cluster0: mailbox@29000000 {
compatible = "ti,am64-mailbox";
reg = <0x00 0x29000000 0x00 0x200>;
interrupts = <GIC_SPI 76 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 77 IRQ_TYPE_LEVEL_HIGH>;
#mbox-cells = <1>;
ti,mbox-num-users = <4>;
ti,mbox-num-fifos = <16>;
};
&mailbox0_cluster0 {
mbox_m4_0: mbox-m4-0 {
ti,mbox-rx = <0 0 0>;
ti,mbox-tx = <1 0 0>;
};
mbox_r5_0: mbox-r5-0 {
ti,mbox-rx = <2 0 0>;
ti,mbox-tx = <3 0 0>;
};
};
// from Linux driver
// fifo %d refers to the actual hardware offset
// i.e., 100% of the time, fifo 1 = the 2nd hardware fifo instance
#define MAILBOX_MSGSTATUS(m) (0x0c0 + 4 * (m))
#ifdef CONFIG_PM_SLEEP
static int omap_mbox_suspend(struct device *dev)
{
struct omap_mbox_device *mdev = dev_get_drvdata(dev);
u32 usr, fifo, reg;
if (pm_runtime_status_suspended(dev))
return 0;
for (fifo = 0; fifo < mdev->num_fifos; fifo++) {
if (mbox_read_reg(mdev, MAILBOX_MSGSTATUS(fifo))) {
dev_err(mdev->dev, "fifo %d has unexpected unread messages\n",
fifo);
return -EBUSY;
}
}
嗨、Anshu 和 Nick
回复如下。
Q1/A1：在遇到问题之前、您是否成功执行了多次低功耗模式循环？
是的,到目前为止,我们有两个圆睾丸。 4K 次 suceess 有一个故障、而 9k 次 suceess 有一个故障。
因此、为了避免竞态条件潜在问题、我要求 Cutomer 在 MCU 触发 A53 唤醒之前在代码中添加一些延迟（~1 秒）。
Q2/A2：您正在使用什么唤醒源进行这些测试？ 如何触发 M4F 以唤醒系统？
按照我之前提到的、因为我们发现在 LPM（退出/重新进入）时、有一些潜在的可能性（案例）导致 RPMsg 崩溃、因此我们设计了 “应力测试“以找出根本原因。
(1) 应力测试:
无 GPIO 触发、添加简单延迟、然后唤醒。 我想我已经在前一篇文章中分享了该代码。
(2) 实际用例
但在实际用例中、MCU（仅 MCU 模式或深度睡眠模式）将读取多个 GPIO 状态 (MCU_GPIO0_19 / MCU_GPIO0_20 / MCU_GPIO0_3 / MCU_GPIO0_14) 以触发 A53 Linux 唤醒、这些 GPIO 信号来自车辆 IGN/WIFI/5G 模块/CAN 总线/USB 唤醒… ETC ,所以它是很有可能多个唤醒事件几乎同时触发。 因为我们怀疑进入/退出 LPM 时 GPIO 唤醒触发过多可能会导致 RPMsg 通信失败,所以我们设计“ Stress test“（压力测试）、用于深度调试。
我认为 AM62 不会在现场车辆应用中（不会）断电、它仅在 LPM 和正常运行之间工作。 因此、我们需要确保 LPM 唤醒不存在严重问题。
Q3/A3：您是否使用未经修改的 ipc_rpmsg_echo_linux 示例？ 如果您使用的是自定义代码,请让 Gibbs 与我们离线分享该自定义代码。
按照我之前提到的、 我已经在这里分享了代码。 我们使用默认映像编译 (tisdk-default-image-am62xx-lp-evm-10.01.10.04.rootfs.wic.xz) 和的一些位修改示例代码 IPC rpmsg_echo_linux。 对于 SK-AM62-LP EVM 上的所有测试、您可以直接下载我的工程代码并在 EVM 上运行。
Q4/A4： 如果您使用的是自定义 M4F 代码、是否在 DDR 中存储任何程序数据？
此问题遵循 Q3/A3。 我想我们不将程序数据存储在 DDR 中、因为我们使用默认示例工程 (r 个人计算机 rpmsg_echo_linux ) 进行一些修改以进行测试。
Q5/A5 :我们有什么方法来分解看门狗重置?
这是一个新问题、当我们这样做时“ 应力测试“、 我们发现系统重新启动了一些时间、但需要长时间测试。 我们怀疑当 AM62 触发某个错误异常时、它似乎会触发看门狗复位、然后在 3 分钟后重新启动。 我们之前有非常类似的讨论。
系统重新启动后、我们会丢失任何日志。 我们能否用任何方法在 AM62 出现 WDT 错误时记录一些信息、并尝试知道让 AM62 重新启动的原因。
顺便说一下、 我还怀疑“持续执行 LPM “是否合理、因此与客户的讨论仍在继续。
非常感谢
Gibbs