工具/软件：
您好、
我们的客户要求我们产品从唤醒到发出 CAN 数据包的时间小于 300ms、
我们的实际测试约为 480ms。
测试 M4F 内核的启动并发送 CAN 数据包需要 119ms 时间、
这意味着 TI AM62 芯片需要 360ms 的时间来唤醒和启动 M4F 内核。
我的问题是如何在本例中缩短 360ms 的时间？
您好、Walter
建议您描述更多细节。
“示例类似“。
主要问题：
当 AM62x 处于深度睡眠模式时、如何在 300ms 内缩短 CAN 响应 (ACK) 时间？
(MCUSS 的周期 A + AM62 唤醒时间+ 周期 B = 300ms)
当前您的状态：
MCUSS 的周期 A + AM62 唤醒时间+周期 B = 480ms、特别是（MCUSS 的周期 A + AM62 唤醒时间）= 119ms
您的要求：
是否可以缩短 周期 A？
是否可以缩短 周期 B？
是否可以缩短 MCUSS 的 AM62 唤醒时间？
建议您描述更多详细信息、比如问题。
(1) 您的 CAN PHY 芯片是什么？ PHY 如何唤醒 AM62？
(2) 什么是相关的硬件连接？
(3) 当第一个 CAN 切换信号时、用于 MCUSS 唤醒的任何 UART 日志？
...等等
谢谢
Gibbs
您好 Walter
有几个问题、需要 仔细检查
(1) 时间 A (480ms) 的定义、步骤如下：
您的 ECU（包括 AM62）已处于“深度睡眠模式“-> ECU 从车辆获取 IGN 信号->触发 AM62 GPIO -> AM62 启动唤醒-> AM62 发送第一个 CAN 帧
是否正确？
(2) 时间 B 的定义 (119 ms)
“AM62 唤醒时间“包括“MCU 应用启动时间“、我是否可以说 119ms 表示 MCU 应用在发送第一个帧之前的执行时间？
嗨、Anshu
点击此链接、这是一个从深度睡眠状态唤醒的 GPIO 示例。
红色：进入深度睡眠
黄色：MCU GPIO 触发后、退出深度睡眠
唤醒时间= 84.571991 - 84.374566 = 0.197425 = 197ms、正确吗？
如果基于我们具有 GPIO 唤醒功能的默认 Linux 示例、在这种情况下、MCU 如何唤醒和执行？
非常感谢
Gibbs
尊敬的 Anshu：
我们使用 ipc_rpmsg_echo_linux_am62x-sk-lp_m4fss0-0_freertos_ti-arm-clang + EVB 电路板测试不大约为 200ms、但超过 300ms。
谢谢
嗨、Anshu
基于 Walter 的日志。
我发现日志与我的日志略有不同。
请勾选黄色标记。
M4 内核应用程序 (M4-FW) 似乎仅在唤醒过程完成后启动。
它花费了大约 62.4ms、还应该包括 RPMSG 信道创建
您能否为我们提供深入调试和研究以缩短唤醒时间的建议？
非常感谢
Gibbs
嗨、Gibbs、
我们进行了一些延迟测试、我们将在这里分享结果。
唤醒源-> M4F MCU 固件
第一项测试是检查从唤醒源到 M4 MCU 固件开始的延迟。 这一过程花费了 282.176ms
蓝色信号是 PMIC_LPM_EN 信号、当 SoC 唤醒时该信号从低电平变为高电平。 此信号反馈到 TI EVM 上的 PMIC。
橙色信号是在 M4F MCU 执行时设置为高电平的 GPIO。 此 GPIO 表示 MCU 固件的启动。
这两个事件之间的时间为 282ms。
唤醒源->无打印语句的 M4F MCU 固件
将语句打印到内核日志会增加恢复进程的延迟。 因此我们删除了 PRINT 语句并执行了相同的测试。
在这种情况下、唤醒事件和 MCU M4F 固件启动之间的延迟为 115.64ms。
如何禁用/减少打印语句？
有两种方法可以做到这一点：
# Detach kernel serial console
consoles=$(find /sys/bus/platform/devices/*.serial/ -name console)
for console in ${consoles}; do
echo -n N > ${console}
done
现在、 M4F 固件恢复的目标延迟是多少？
我们需要知道具体的目标编号。
此致、
Anshu