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:无法使用仅 MCU 模式

Guru**** 2417460 points
Other Parts Discussed in Thread: SK-AM62-LP

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

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1529704/am620-q1-failed-to-use-mcu-only-mode

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

工具/软件:

尊敬的 TI 团队:

我们使用自己的 MCU 工程+EVB 电路板测试不能使用仅 MCU 模式、

修改例程、使用 ipc_rpmsg_echo_linux_am62x-sk-lp_m4fss0-0_freertos_ti-arm-clang+EVB 电路板测试仍然无法正常运行、

以下是测试步骤和日志:

1.使用我们自己的 MCU 工程+EVB 板进行测试:

Echo 100 >/sys/devices/system/cpu/cpu0/power/pm_qos_resume_latency_us

Echo mem >/sys/power/state

Echo 100 >/sys/devices/system/cpu/cpu0/power/pm_qos_resume_latency_us

rtcwake -m mem -s 10.

以上述两种方式进入仅 MCU 模式时、它无法唤醒、并且无法在 R5 串行端口输入中唤醒。

它将在 3 分钟后自动复位。

修改例程以使用 ipc_rpmsg_echo_linux_am62x-sk-lp_m4fss0-0_freertos_ti-arm-clang+EVB 电路板测试:

Echo 100 >/sys/devices/system/cpu/cpu0/power/pm_qos_resume_latency_us

Echo mem >/sys/power/state

 

Echo 100 >/sys/devices/system/cpu/cpu0/power/pm_qos_resume_latency_us

rtcwake -m mem -s 10.

当以上述两种方式进入仅 MCU 模式时、它无法唤醒、

并且无法在 R5 串行端口输入中唤醒、它将在 3 分钟后自动复位。

下图中红色框内的器件是我们在例程中进行的修改

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

    您好 Walter、

    我们分步执行此操作:

    1. 首先、我们检查一下在 TI EVM(如 SK-AM62-LP)上使用默认的 Linux SDK 代码而没有任何更改、MCU 是否仅工作?

    我仅在 SK-AM62-LP 上测试了 SDK 10.1 MCU、它使用以下准确的映像在我的最后正常工作: https://www.ti.com/tool/download/PROCESSOR-SDK-LINUX SDK-AM62X/10.01.10.04

    2.然后让我们仅在 TI EVM 上更改 IPC Echo 示例时运行 MCU。 仅 MCU 工作吗?

    如果没有、则可能是由 IPC 回显固件导致的、我们可以从中进行调试。

    3.如果这样做有效,那么我们可以检查您的定制硬件。

    修改例程、使用 ipc_rpmsg_echo_linux_am62x-sk-lp_m4fss0-freertos_ti-arm-clang+EVB 电路板测试仍然无法正常工作、

    请分享您对 IPC 示例代码所做的所有更改。

    它无法在 R5 串行端口输入中唤醒、

    请说明您如何测试此唤醒源。 最简单的方法是:

    HOST PC~$ echo a > /dev/ttyUSB2

    此致、

    Anshu

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

    您好 Walter、

    您还能解释一下您所用的 IPC Echo 固件是如何开发的吗?  

    标准 IPC RPMSG ECHO Linux 文件包含所有支持低功耗模式的元件: https://github.com/TexasInstruments/mcupsdk-core-k3/blob/k3_main/examples/drivers/ipc/ipc_rpmsg_echo_linux/ipc_rpmsg_echo.c

    建议使用此文件作为基础并进行构建。

    此致、

    Anshu

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

    尊敬的 Anshu:

    在上图中、我们已经分享了在示例中所做的所有修改。

    我们需要首先证明 MCU 在进入仅 MCU 模式后继续运行。

    谢谢

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

    尊敬的 Anshu:

    我更新最新的现象。

    拉出 U 盘后、可通过 RTC 和我们配置的唤醒源唤醒 AM62。

    MCU 在睡眠后仍然不会继续运行、但在唤醒时不会重新启动、

    但在睡觉时从停止的地方继续奔跑

    谢谢

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

    尊敬的 Anshu:

    根据 ti SDK 文档中的说明、在“仅 MCU“模式下、

    MCU 应正常运行。

    但是、我们的测试表明、进入“仅 MCU“模式后、MCU 没有继续运行。

    您是否有任何日志支持此功能?

    也许您可以参考我的修改内容、然后再次进行测试、并提供 MCU 日志作为证据。

    谢谢

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

    您好 Walter、

    经过一些调试后、我们确定、当 USB 器件连接到处理器后进入深度睡眠或仅进入 MCU 模式时、SoC 有时会崩溃。 我们认为这可能是由 TIFS 引起的、这是它在 3 分钟后重置的原因、因为它的计时器到期。

    我们仍在尝试找出问题的根源、但我们能够重现问题。

    谢谢、

    Anshu

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

    您好 Walter、

    您能否确认 USB 是否是可能的唤醒源之一?

    谢谢、
    Anshu

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

    您好 Walter、

    您能否分享来自 SoC 的 USBx_DRVVBUS 信号的原理图?

    该信号上是否有任何拉电阻器?

    此致、

    Anshu

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

    尊敬的 Anshu:

    仅测试点、  USBx_DRVVBUS 上无拉电阻器。

    BR

    Chason

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

    尊敬的 Anshu:

    我提到的测试现象和测试程序均使用修改后的程序在 EVB 电路板上进行了测试。

    它不是我们自己的项目板。

    谢谢

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

    您好 Walter

    感谢您在 TI EVM 上进行实验。  

    您能否说明您拥有的 EVM 版本(丝印应包含该详细信息)  

    我认为、在 EVM 上、应该移除 USB1 DRVBUS 上有一个 10K 下拉电阻、以可靠地测试此功能  

    此外、 在 DEEP SLEEP/MCU ONLY 模式下 VBUS_5V0_TYPEA 应为 5V、为了唤醒至工作、您可以在 TP203 上进行检查、以确认 EVM 测试中是否满足这种情况。  

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

    嗨、Mukul & Anshu

    更新 USB 唤醒旁边的调试状态

    我想我们创建这个主题就是试着讨论为什么 MCU 不会在“仅 MCU 模式“下工作

    因为据我所知、当 AM62x 处于“仅 MCU 模式“时、MCU 程序应该继续运行。

    请检查附件、我发现了一些问题

    (1) Pls ref main、c、即使我们已经在 Linux 器件树中将“MCU_GPIO0_14"设置“设置为唤醒源、但客户似乎再次在 MCU 代码中重新初始化此 GPIO、这是否合理? 因为据我所知、即使是“深度睡眠模式“或“仅 MCU 模式“GPIO 唤醒、我们也只正式支持 Linux 器件树设置、不是吗? 这是否令人担忧?

    static Pinmux_PerCfg_t fii_PinMuxMcuDomainCfg[] =
    {
     /* MCU_GPIO0 pin config */
         /* MCU_GPIO0_14 -> MCU_MCAN0_RX (C4) MCU_CAN1_INH*/
         {
             PIN_MCU_MCAN0_RX,
             0x28054087
         },
        {PINMUX_END, 0U}
    };

    (2) 函数“lpm_mcu_wait_for_uart ()“的 Pls 参考“ipc_rpmsg_echo.c"</s>“

    一旦 AM62 在仅 MCU 模式下运行、此功能 (lpm_MCU_wait_for_uart) 应保持运行、并在 while 循环中打印字符串“MCU 正在运行“。

    但我们发现此函数处于暂停状态、直到 AM62 唤醒。

    在仅 MCU 模式下是否会禁用 UART 输出?

    源代码作为附件。

    首先更新状态并继续调试。

    #if defined(ENABLE_MCU_ONLY_LPM)
    static void lpm_mcu_wait_for_uart()
    {
        UART_Transaction trans;
        uint8_t uartData;
        int32_t status;
        uint32_t cnt = 0U;
    
        UART_Transaction_init(&trans);
    
        /* Read 1 byte */
        trans.buf   = &uartData;
        trans.count = 1U;
    
        DebugP_memLogWriterPause();
    
        gNumBytesRead = 0u;
    
        while(1)
        {
            if(cnt < 0xFFFFF)
            {
                cnt++;
            }
            else
            {
                DebugP_log("MCU is running\r\n");
                cnt = 0U;
            }
    # if 0
            if (cnt == 0xFFFFFF)
            {
                //SOC_triggerMcuLpmWakeup();
                /* Wait for resuming the main domain */
                //SemaphoreP_pend(&gLpmResumeSem, SystemP_WAIT_FOREVER);
                DebugP_log("cnt = %u\r\n",(cnt / 0xFFFF));
            }
    #endif
        }
    
    
    # if 1
        /* Wait for any key to be pressed */
        status = UART_read(gUartHandle[CONFIG_UART0], &trans);
        DebugP_assert(status == SystemP_SUCCESS);
    
        while (gNumBytesRead == 0u && gbSuspended == 1u)
        {
        }
    
        if (gNumBytesRead != 0)
        {
            DebugP_log("[IPC RPMSG ECHO] Key pressed. Notifying DM to wakeup main domain\r\n");
            SOC_triggerMcuLpmWakeup();
            /* Wait for resuming the main domain */
            SemaphoreP_pend(&gLpmResumeSem, SystemP_WAIT_FOREVER);
    
            DebugP_log("[IPC RPMSG ECHO] Main domain resumed due to MCU UART \r\n");
        }
        else if (gbSuspended == 0u)
        {
            UART_readCancel(gUartHandle[CONFIG_UART0], &trans);
            DebugP_log("[IPC RPMSG ECHO] Main domain resumed from a different wakeup source \r\n");
        }
    #endif
        DebugP_memLogWriterResume();
    }
    
     

    e2e.ti.com/.../ipc_5F00_rpmsg_5F00_echo_5F00_linux_5F00_am62x_2D00_sk_2D00_lp_5F00_m4fss0_2D00_0_5F00_freertos_5F00_ti_2D00_arm_2D00_clang.zip

    谢谢你。

    Gibbs

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

    尊敬的专家

    更新状态、

    板:SK-AM62-LP

    SW:10.00.00.04

    我们需要一个示例代码、

    我们需要 MCU UART (M4 UART) 在正常运行模式和 MCU olny 模式下始终“保持字符串输出“。

    我想我们可以基于这个项目进行修改。

    --> ipc_rpmsg_echo_linux_am62x-sk-lp_m4fss0-0_freertos_ti-arm-clang

    在测试了几天之后、根据此示例工程、我们发现 MCU 内核 (M4) 正在持续运行、但根本原因应该是任何无法正常运行的 I/O(如 UART)。

    谢谢你。

    Gibbs

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

    嗨、Gibbs、

    USB DRVVBUS 信号详细信息

    在 SK-AM62-LP 上、我们观察到该信号在深度睡眠期间变为低电平、可能是由于 10k Ω 的下拉电阻器。 当 USB-A 器件连接到 EVM 时、这会导致任何低功耗模式失败。 发生的情况是、TIFS 将在 3 分钟后超时、因为它与 DM 固件失去接触、导致整个 SoC 复位。

    我们拆焊该电阻器、并在连接 USB A 器件后成功暂停/恢复。  

    我们可以在 SK-AM62-LP EVM 上尝试一下、确保这也适用于您吗?

    M4F IPC 固件

    但客户似乎再次在 MCU 代码中重新初始化此 GPIO、这是否合理? [/报价]

    外设不能在不同的操作系统之间共享。 一旦 Linux 将 GPIO 等外设声明为唤醒源、MCU 预计不会使用相同的 GPIO。 此时、它会导致外设的所有权发生冲突、并可能导致意外行为。  

    此函数 (lpm_mcu_wait_for_uart) 应保持运行、并在 while 循环中打印字符串“mcu is running“。

    我没有尝试确切的代码、但我已经在仅 MCU 模式下尝试打印数字。 我注意到的是代码仍然在执行、但它不会打印到 UART 终端、因为它等待用户按键收到传入的 UART 字节。

    我做了一个粗略的例子:

    这是 MCU M4F 固件、我添加了用于打印数字计数的代码。  

    这是我所做的代码更改、将变量设置为 500、然后每 1 秒递减一次。

    #endif
        DebugP_log("<DEBUG> recieve task\r\n");
        /* create message receive tasks, these tasks always run and never exit */
        ipc_rpmsg_create_recv_tasks();
    
        /* wait for all non-Linux cores to be ready, this ensure that when we send messages below
         * they wont be lost due to rpmsg end point not created at remote core
         */
         DebugP_log("<DEBUG> Timer print stuff\r\n");
         uint32_t    loopcnt = 500, delaySec = 1;
         while(loopcnt > 0)
         {
             DebugP_log("<DEBUG> Number %d\r\n", loopcnt);
             ClockP_sleep(delaySec);
    
             loopcnt--;
         }
         DebugP_log("<DEBUG> sync all\r\n");
        IpcNotify_syncAll(SystemP_WAIT_FOREVER);

    我观察到的是、当 SoC 挂起时、代码仍然执行、但不会打印输出。 以下是显示其暂停 5 秒的 Linux 日志:

     

    rtcwake -m mem -s 5
    rtcwake: wakeup from "mem" using /dev/rtc0 at Wed Jun 25 22:39:50 2025
    [ 1081.970150] PM: suspend entry (deep)
    [ 1081.974284] Filesystems sync: 0.000 seconds
    [ 1081.993505] Freezing user space processes
    [ 1081.999462] Freezing user space processes completed (elapsed 0.001 seconds)
    [ 1082.006472] OOM killer disabled.
    [ 1082.009703] Freezing remaining freezable tasks
    [ 1082.015666] Freezing remaining freezable tasks completed (elapsed 0.001 seconds)
    [ 1082.023072] printk: Suspending console(s) (use no_console_suspend to debug)
    [ 1082.055583] ti-sci 44043000.system-controller: ti_sci_cmd_set_device_constraint: device: 10
    [ 1082.055772] ti-sci 44043000.system-controller: ti_sci_cmd_set_device_constraint: device: 10
    [ 1082.056622] am65-cpsw-nuss 8000000.ethernet eth0: Link is Down
    [ 1082.063972] ti-sci 44043000.system-controller: ti_sci_cmd_set_device_constraint: device: 10
    [ 1082.064182] ti-sci 44043000.system-controller: ti_sci_cmd_set_latency_constraint: latency:0
    [ 1082.097989] Disabling non-boot CPUs ...
    [ 1082.100553] psci: CPU1 killed (polled 0 ms)
    [ 1082.104309] psci: CPU2 killed (polled 0 ms)
    [ 1082.108638] psci: CPU3 killed (polled 0 ms)
    [ 1082.110451] Enabling non-boot CPUs ...
    [ 1082.110891] Detected VIPT I-cache on CPU1
    [ 1082.110945] GICv3: CPU1: found redistributor 1 region 0:0x00000000018a0000
    [ 1082.111011] CPU1: Booted secondary processor 0x0000000001 [0x410fd034]
    [ 1082.112365] CPU1 is up
    [ 1082.112653] Detected VIPT I-cache on CPU2
    [ 1082.112685] GICv3: CPU2: found redistributor 2 region 0:0x00000000018c0000
    [ 1082.112729] CPU2: Booted secondary processor 0x0000000002 [0x410fd034]
    [ 1082.113862] CPU2 is up
    [ 1082.114174] Detected VIPT I-cache on CPU3
    [ 1082.114211] GICv3: CPU3: found redistributor 3 region 0:0x00000000018e0000
    [ 1082.114262] CPU3: Booted secondary processor 0x0000000003 [0x410fd034]
    [ 1082.115441] CPU3 is up
    [ 1082.115972] ti-sci 44043000.system-controller: ti_sci_resume: wakeup source: 0x50
    [ 1082.133086] am65-cpsw-nuss 8000000.ethernet: set new flow-id-base 19
    [ 1082.142518] am65-cpsw-nuss 8000000.ethernet eth0: PHY [8000f00.mdio:00] driver [TI DP83867)
    [ 1082.142544] am65-cpsw-nuss 8000000.ethernet eth0: configuring for phy/rgmii-rxid link mode
    [ 1082.375129] OOM killer enabled.
    [ 1082.378275] Restarting tasks ... done.
    [ 1082.384426] random: crng reseeded on system resumption
    [ 1082.389847] k3-m4-rproc 5000000.m4fss: Core is on in resume
    [ 1082.395647] k3-m4-rproc 5000000.m4fss: received echo reply from 5000000.m4fss
    [ 1082.408784] PM: suspend exit
    

    因此、当我暂停 5 秒以进入仅 MCU 模式 (MCU 计数器上为 375) 时、它将在 5 秒后恢复打印。

    <DEBUG> Number 380
    <DEBUG> Number 379
    <DEBUG> Number 378
    <DEBUG> Number 377
    <DEBUG> Number 376
    <DEBUG> Number 375
    <DEBUG> SemaphoreP_pend(&gLpmSuspendSem, SystemP_WAIT_FOREVER)
    <DEBUG> Sciclient_lpmGetNextHostState
    <DEBUG> passed the if statement
    [IPC RPMSG ECHO] Next MCU mode is 1
    [IPC RPMSG ECHO] Suspend request to MCU-only mode received 
    [IPC RPMSG ECHO] Press a single key on this terminal to resume the kernel from MCU only mode 
    <DE\ufffd[IPC RPMSG ECHO] Main domain resumed from a different wakeup source 
    <DEBUG> start of while loop
    <DEBUG> Number 369
    <DEBUG> Number 368
    <DEBUG> Number 367
    <DEBUG> Number 366
    <DEBUG> Number 365
    

    很可能发生的情况是 UART 缓冲区不打印任何内容、因为它确定了唤醒器件的用户输入的优先级、如所示:

    [IPC RPMSG ECHO] Press a single key on this terminal to resume the kernel from MCU only mode 

    我们可以运行一些更深入的测试,但这已经告诉我,它仍然在运行,但只是没有打印。

    SW:10.00.00.04

    SDK 版本何时更改? 在以前的线程中、使用的是 SDK 10.1。  

    此致、

    Anshu

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

    嗨、Ansu

    感谢您的答复。

    以下是一些快速反馈和一些问题

    Q1/A1: SDK 版本何时更改? 在以前的线程中、使用的是 SDK 10.1。  

    我使用  SDK 10.1 进行测试、客户使用 SDK  10.00 进行测试。 这两个版本都有相同的问题。 但基本上、我认为应该是编码问题。

    Q2/A2 :您认为将自定义代码放在线程函数“lpm_mcu_wait_for_uart ()“中是合理的吗?

    对代码进行如下修改、即概念讨论。

    我们禁用 UART 唤醒、但仍然是 MCU_GPIO 从仅 MCU 模式组成。

    因为客户表示他们在此函数中放置了一些 GPIO 程序、所以它也不会触发。

    我怀疑它应该有 RTOS 任务优先级问题。

    static void lpm_mcu_wait_for_uart()
    {
        UART_Transaction trans;
        uint8_t uartData;
        int32_t status;
    
        //UART_Transaction_init(&trans);
    
        /* Read 1 byte */
        //trans.buf   = &uartData;
        //trans.count = 1U;
    
        //DebugP_memLogWriterPause();
    
        //gNumBytesRead = 0u;
    
        /* Wait for any key to be pressed */
        //status = UART_read(gUartHandle[CONFIG_UART0], &trans);
        //DebugP_assert(status == SystemP_SUCCESS);
    
        //while (gNumBytesRead == 0u && gbSuspended == 1u)
        //{
        //}
    
        while(1){
    
    	// Place customized code here
            // and do something.
    	// example another uart / gpio action
    
        }
    
    
        // Because we do not need mcu uart wakeup
        // but keep another mcu gpio wake up
        // this gpio test in Linux device tree, and it works.
        if (gNumBytesRead != 0)
        {
            //DebugP_log("[IPC RPMSG ECHO] Key pressed. Notifying DM to wakeup main domain\r\n");
            //SOC_triggerMcuLpmWakeup();
            /* Wait for resuming the main domain */
            //SemaphoreP_pend(&gLpmResumeSem, SystemP_WAIT_FOREVER);
            //DebugP_log("[IPC RPMSG ECHO] Main domain resumed due to MCU UART \r\n");
        }
        else if (gbSuspended == 0u)
        {
            //UART_readCancel(gUartHandle[CONFIG_UART0], &trans);
            DebugP_log("[IPC RPMSG ECHO] Main domain resumed from a different wakeup source \r\n");
        }
    
        //DebugP_memLogWriterResume();
    }
    

    谢谢

    Gibbs

     

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

    客户报告说、 MCU 无法在仅 MCU 模式下控制 IO 的问题已经解决。

    有关 IPC 在恢复过程中崩溃的未来通信已移至

    https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1532839/am620-q1-ipc-crash-in-resume-from-mcu-only-mode

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

    您好、Gibbs、

    客户如何使用 MCU 域 GPIO 模块?  

    Anshu 为我展示了一个图、其中有一个外部 CAN 器件连接到 MCU CAN 接口和一个 MCU GPIO 引脚。

    1) 哪个内核控制 MCU CAN 接口上的 CAN 器件?

    2) 哪个内核控制 MCU GPIO 模块?

    LPM_MCU_WAIT_FOR_UART ()-您应该修改它吗?  

    客户可以修改他们喜欢的示例的任何部分。 但是、如果他们试图做一些 TI 没有经过测试的事情、那么我们能够提供的支持将受到限制。

    TI 已测试的“低功耗 GPIO 唤醒“用例是 Linux 控制 Foundational_Components 模块、而 Linux 则根据 https://software-dl.ti.com/processor-sdk-linux/esd/AM62X/10_01_10_04/exports/docs/linux/GPIO/GPIO/ pm_wakeup_sources.html 将 Power_Management 设置为唤醒源 。

    如果 Linux 在客户设计中也是 MCU GPIO 的所有者、我建议使用 TI 测试的唤醒实现。

    此致、

    Nick

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

    嗨、Nick

    简单回答您的问题、讨论内容位于仅 MCU 模式下

    Q1/A1: 哪个内核控制 MCU CAN 接口上的 CAN 器件?

    MCU M4 内核控制 MCU MCAN

    Q2/A2: 哪个内核控制 MCU GPIO 模块?

    您谈论的是“唤醒 GPIO“、我认为 A53 内核控制这个唤醒 GPIO、因为我们在 Linux 设备树 (DTS) 中对其进行编码。

    但按照我们的 SDK 指南、我们只支持 Linux DTS 中的唤醒 GPIO 设置、不是吗?

    https://software-dl.ti.com/processor-sdk-linux/esd/AM62X/10_01_10_04/exports/docs/linux/Foundational_Components / Power_Management / pm_wakeup_sources.html

    -->  3.3.6.2.  MCU GPIO 定义

    因此、我建议客户在 Linux DTS 中设置任何唤醒源、并告诉客户不要 在 MCU 代码中使用此唤醒源 (GPIO)。

    谢谢

    Gibbs

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

    嗨、Gibbs、

    根据电子邮件讨论、此主题将关闭。

    谢谢、

    Anshu

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

    谢谢、Anshu

    请关闭此螺纹。

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

    您好 Walter、  

    将在以下主题中讨论 TIFS 超时: e2e.ti.com/.../am620-q1-tifs-timeout
    谢谢、

    Anshu