• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 97 subscribers
  • Views 2111 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

AM335x deepsleep0 wake up issue after long time sleep

Steven Liu1
Expert 4525 points

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! 

  • 0
    TI__Expert 4525 points

    + sleep33xx.S file modification as below:

    #if 0

    #endif

  • 0 in reply to Steven Liu1
    TI__Guru**** 393215 points
    I will ask the PM experts to look at this.
  • 0 in reply to Biser Gatchev-XID
    TI__Guru*** 125430 points
    While you're in this state (DDR_CKE low and clock operational) are you able to run the scripts as described here:

    processors.wiki.ti.com/.../Debugging_AM335x_Suspend-Resume_Issues
  • 0 in reply to Brad Griffis
    TI__Expert 4525 points
    Hi Brad,
    Thanks for your response!
    I know this script, but it helped little. The issues happened after thousands of test circles, so it worked well for most of the tests, and we are not able to know when it would happen.
    In addition, customer now are able to reproduce this issue on the StarterKit EVM. The test steps are as below:
    1. running below script on the AM335x SK EVM, to set the EVM into suspend mode.
    while（1）
    {
    echo mem > /sys/power/state
    sleep 1
    }

    2. using another board to generate an PWM, period: 2 second, 50% duty cycle, then connect it to the SW3 button to act as the wakeup resource.
    3. test the suspend mode for a long time. LInux SDK version: 6.0.

    They set up the test before the weekend, only to find the board fail to wake up, the issue's observation is the same as the previous: main OSC running, CKE is low.

    Besides, in their former tests with their product board, they tested the issue with the rtc wake up by using the script as below:
    while(1)
    {
    rtcwake -d /dev/rtc0 -m mem -s 1;
    sleep 1;
    }
    Failure happened thousands of test cycles. The longest test is ~21,000 test cycles, but still failed at last.
    Besides, I also asked them to increase the rtc wake up time from 1 second to 5 seconds, the issues still existed.

    So do you have any comments on the test methods or clues to dig the root cause of this? Many thanks!
  • 0 in reply to Steven Liu1
    TI__Guru*** 125430 points

    Steven Liu1 said:
    Thanks for your response!
    I know this script, but it helped little. The issues happened after thousands of test circles, so it worked well for most of the tests, and we are not able to know when it would happen.

    After you encounter the issue, please run the 2 scripts I mentioned and post the results.

    Steven Liu1 said:
    So do you have any comments on the test methods or clues to dig the root cause of this? Many thanks!

    Start instrumenting the wake-up code to leave some breadcrumbs in internal memory so you can connect with JTAG and see how far in the code it's getting.  Does the A15 even begin executing code?  If so, how far does it get before it crashes?  Can you view the DDR contents?  Does it still look like it has valid code, or has it all been lost?