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:AM62 具有进入休眠状态且无法唤醒的概率趋势。

Guru**** 2416110 points


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

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1523881/am620-q1-am62-has-a-probabilistic-tendency-to-enter-a-dormant-state-and-cannot-be-awakened

器件型号:AM620-Q1
主题:TCAN1043 中讨论的其他器件

工具/软件:

您好、

我们在工程中遇到间歇性故障唤醒、

包括我们设置的唤醒源(例如 USB 唤醒)无法触发唤醒的情况。


要确定我们的代码出现的问题、

我们还使用 EVB 板进行了测试、并发现存在三种无法唤醒的场景:


1.将 MCU_GPIO0_14 设置为低电平以实现唤醒并将该引脚接地、

并以“同时为真;执行 echo mem >/sys/power/state;done;“进入命令行、执行自动睡眠唤醒。

一段时间后、EVB 板停止运行、命令行只会打印出睡眠状态日志。


2.插入 USB 驱动器并使 EVB 板进入休眠模式。 然后卸下 USB 驱动器。

MCU_GPIO0_14 无法再唤醒电路板。 大约 1 分钟后、电路板会自动重新启动。


3.插入 USB 驱动器并在命令行中输入“rtcwake -m mem -s 10“。

然后立即卸下 USB 驱动器。 10 秒后、EVB 板也无法唤醒。 大约 1 分钟后、

电路板会自动重新启动。

我们的 SDK 是 10_01_10_04、我们如何解决该问题?

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

    您好 Walter、

    我需要仔细研究一下、下周我会回来给您解答。

    谢谢、

    Anshu

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

    嗨、Anshu

    这是一份备忘录、因为我刚刚完成了与客户的此问题会议。

    (1) 我们发现一个导致 AM62 无法唤醒的特殊用例。 当 AM62 进入深度睡眠过程并 同时触发许多 GPIO 唤醒时、这种情况会使 AM62 无法唤醒。

    (2) 我们发现唤醒 GPIO 仅支持电平触发器、对吗?

    (3) 客户尝试编写一个脚本、因为他们希望测试“自动“重复唤醒、步骤如下。

    a) 让  MCU_GPIO0_14 始终保持低电平。 (接地,电平触发器,低电平有效)

    b) 在这个 UART 控制台中 同时执行这个脚本 ,如下所示的脚本。

    while true; do echo mem > /sys/power/state; done;”

    由于 CAN PHY (TCAN1043) 触发了唤醒 GPIO (MCU_GPIO0_14)、因此一旦 CAN PHY 接收到任何 CAN 消息、它就会将  MCU_GPIO0_14 切换为低电平有效。  本实验的目的是尝试在 AM62 进入深度睡眠过程时模拟高频 GPIO 唤醒触发到 AM62。

    结果表明、AM62 无法再唤醒、即使我们使用另一个接口(例如:USB) 尝试唤醒它也是如此。

    Gibbs

     

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

    您好 Anshu:

     基于 Gibbs 更新,我知道你有什么建议吗?

    谢谢你  

    Roy

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

    嗨、Gibbs、

    (2) 我们找到了 wake GPIO only support level trigger、不是?

    GPIO 唤醒将在发生边沿更改时完成: https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/arch/arm64/boot/dts/ti/k3-am62x-sk-lpm-wkup-sources.dtso?h=ti-linux-6.12.y#n29

    我需要在内部检查是否请求了同时唤醒源、因为这并不是我们已经测试过的内容。

    此致、

    Anshu

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

    嗨、Gibbs、

    同步唤醒源

    之前、我们从未测试过多个 同时唤醒源的用例。

    现在、我们已经进行了许多测试、尝试从深度睡眠中同时唤醒。 我们所做的是将同一域中的两个 GPIO 连接到一个开关按钮、然后将开关接地、这样 SoC 将在开关闭合时唤醒。

    我们注意到、即使唤醒事件同时发生、也根本不会影响恢复序列。

    这是合理的、因为当在硬件级别发生任何唤醒事件(无论是 1 个唤醒源、同时 2 个唤醒源还是同时有无限多个源)时、DM 固件只需要了解发生了唤醒事件并将执行恢复序列。 然后、它将在稍后恢复最后一个 A53 内核后考虑唤醒源。

    USB 唤醒

    现在回到原始帖子、这可能与 USB 唤醒源本身有关。 我们需要详细了解如何执行 USB 唤醒。

    • 正在使用哪个 USB 模块? USB0 还是 USB1?
    • 如何执行 USB 唤醒? 通过 USB 连接、USB 断开连接还是远程唤醒? 请包含根据需要使用的所有命令。
    • USB DRVVBUS PADCONFIG 寄存器的内容是什么?  对于 USB0、它将为 0x000F4254、 对于 USB1、它将为 0x000F4258。

    与 USB DRVVBUS 信号相关的错误: https://sir.ext.ti.com/jira/browse/EXT_EP-12298

    https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/commit/?h=ti-linux-6.12.y-cicd&id=d944a388dcf124033818b044263cc1f70fbe3062

    https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/commit/?h=ti-linux-6.12.y-cicd&id=9d9083b890e59de4ab3f2f2b78049b2f2d90b0a0

    需要更多背景信息

    • 系统进入深度睡眠模式的频率如何?  
    • 您已使用“while true ...“ userspace 命令记录了深度睡眠循环测试。 系统是否会进入您正在测试的连续暂停/恢复循环?
    • 系统所有可能的唤醒源是什么? 仅 MCU GPIO 和 USB?

    此致、
    Anshu

      

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

    嗨、Gibbs、

    我们的 soc 团队一直怀疑他们使用的唤醒引脚称为 MCU_GPIO0_GPIOX、

    因此、唤醒源和唤醒中断应在 MCU 中配置、而不是在 SOC 中配置。

    但是、我之前尝试过、在 MCU 配置中断后、必须在睡眠期间释放它、

    否则唤醒时会出现错误。

    当我问 TI FAE 时、他回复说我没有在 MCU 驱动程序中配置唤醒源。

    假定在 MCU 启动时配置了唤醒中断、并在 MCU 睡眠时释放、

    它实际上是否会产生唤醒中断? 同时、

    TI 的 SDK 文档指出、这些引脚通常应由 MCU 配置、

    但当 soc 不依赖于 MCU 时除外。

    这使我们感到不安、请详细说明。

    谢谢

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

    您好 Walter、

    我需要与 MCU SDK GPIO 专家讨论这个问题。 我将在星期一上回复您。

    谢谢、

    Anshu