[continue conversation from https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1529704/am620-q1-failed-to-use-mcu-only-mode]
Hi, Gibbs，
We have solved the problem that mcu cannot control IO in only mode.
Next, please give priority to the problem that mcu wakes up soc and causes IPC crash and automatic restart
Thanks
Hello Walter,
We need more information about what you are testing. Here are the details I was able to figure out so far:
Anshu told me that you were running tests with this Linux script:
while true; do echo mem > /sys/power/state; done;
Based on that input, I assume that the terminal output you showed is broken into several wakeup / suspend cycles, like this:
We can verify from the output "fifo 1 has unexpected unread messages" that the M4F is the one who did not read the mailbox message during #2 in the above image (i.e., not Linux).
In case anyone wants to double-check the thought process on how we can verify what "fifo 1" means, I'll attach the relevent code snippets.
// 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;
}
}
Hi, Anshu & Nick
Replies as below.
Q1/A1 : Is it true that you had multiple successful low power mode cycles before running into an issue?
Yes, so far, we have two round testig. 4k times suceess has one faild, and 9k times suceess has one failed.
so try to avoid race condition potential issues, I ask cutomer add some delay (~1 sec) in code before MCU trigger A53 wakeup.
Q2/A2: What wakeup source are you using for these tests? How are you triggering the M4F to wake up the system?
Follow I mention before, because we found that has some potential chance (case) which caused RPMsg crash when (exits from / re-enter in) LPM, so we design "stress test" to find root cause.
(1) Stress test :
No gpio trigger, add simple delay and then wakeup. I think I already share the code in previous post.
(2) Real Use case
But in real use case, MCU (MCU only mode or deep sleep mode) will read multiple GPIO status (MCU_GPIO0_19 / MCU_GPIO0_20 / MCU_GPIO0_3 / MCU_GPIO0_14) to trigger A53 linux waleup, these gpio signals come from vehicle IGN/WIFI/5G module/CAN BUS/USB wakeup... etc , so it is very possible that multiple wakeup event trigger almost at the same time. Because we suspect too intensive gpio wakup trigger with enter/exit LPM may caused RPMsg communicaton falied, so we design "Stress test" for deep debugging.
I think AM62 will not (naver) power off in field vhicle application, it only works between LPM and Normal operation. so we need to make sure there is no serious issue for LPM wakeup.
Q3/A3 : Are you using the unmodified ipc_rpmsg_echo_linux example? If you are using custom code, please have Gibbs share that custom code with us offline.
Follow I mention before, I already share code here. We use default image build (tisdk-default-image-am62xx-lp-evm-10.01.10.04.rootfs.wic.xz) with a litte bit modification sample code for ipc_rpmsg_echo_linux. All test on SK-AM62-LP EVM, you can direct download my project code, and runs it on EVM.
Q4/A4 : If you are using custom M4F code, are you storing any program data in DDR?
This question is follow Q3/A3. I think we do not storing program data in DDR, because we use default sample project (rpc_rpmsg_echo_linux) with a little bit modification to test it.
Q5/A5 : Do we have any way to anlysis watch dog reset?
This is a new question, when we do "Stress test", we found system reboot some times, but it need long time testing. we suspect it seems trigger watchdog reset when AM62 hit some error exception, and then reboot after 3 minutes. We have very similiart discussion before.
Once system reboot, we lost any logs. Could we have any way to log some information when AM62 has WDT error, and try to know what's reason let AM62 reboot.
By the way, I also suspect "continuous execution of LPMs" is reasonable or not, so discussion with customer is keep on going.
Thank You Very Much
Gibbs