Hi Team,
My customer is facing one issue related to the AM3352BZCZD60 deepsleep0 with Linux SDK 6.0.
For the back ground, you can refer to the link as below for the designs:
https://e2e.ti.com/support/arm/sitara_arm/int_sitara_am335x/f/425/t/531699
Now after setting the wake up resource correctly, the board can go into deepsleep0 mode and can wake up normally.
However, when doing long time suspend test, the system would sometimes fail to wake up.
When the issue happened, the system would hang there, and we found that the main OSC is alive and the DDR_CKE is low.
For issue debugging,
1. we double checked the DDR3 software leveling for this issue debug. It was all right.
2. Checking the MPU, CORE, DDR_PLL, PER_PLL configuration, all those are correct.
3. Adding the console print, we found it executed the C codes normally till the last stage of the suspend C code. Log could be found as below:
[ 3860.685100] PM: Syncing filesystems ... done.
[ 3860.690040] Freezing user space processes ... (elapsed 0.01 seconds) done.
[ 3860.714785] Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
[ 3860.737929] omap_wdt_suspend,387
[ 3860.862101] PM: suspend of devices complete after 126.841 msecs
[ 3860.868345] PM: suspend devices took 0.130 seconds
[ 3860.877147] PM: late suspend of devices complete after 3.697 msecs
[ 3860.884065] mem_type 0x3 suspend_vtp 0x0 evm_id 0x4 cpu_rev 0x2 suspend_state 0x0
[ 3860.892045] -------------stp1--------------------
[ 3860.896997] -------------stp2--------------------
[ 3860.901949] -------------stp5--------------------
[ 3860.906901] -------------stp6--------------------
[ 3860.911853] -------------stp7--------------------
[ 3860.916973] -------------stp8--------------------
Some questions now I have might need your help to confirm
1. For the main OSC: they used the 25MHz. Is there any report related to this wake up issue with such 25 frequency?
2. For the DDR design with VTT: they don't use the GPIO to control the output of VTT. So according to the previous talk, the assembly codes of below is commented, in order to get it work well in suspend mode. Will this affect the issue?
In addition, we found that, if the wake up time is much faster (like using rtcwake -d /dev/rtc0 -m mem -s 1), it is much easier to reproduce this issue.
Could you help to give some comments on how to solve this issue? This looked like the boards' deepsleep0 mode is not reliable. Many thanks!