Hi,
We have implemented DEEPSLEEP mode on our customized board and it's running is not stable. We agreessively test the mode by quickly entering into and waking up from DEEPSLEEP mode repeatedly.
The code we implemented strictly follows "10.10.1 Entering/Exiting Deep Sleep Mode Using Externally Controlled Wake-Up" in SPRUH77, and is very similar to the DEEPSLEEP lines in function
PMI_Status PMI_sleepCPU(PMI_Sleep state, unsigned scaleVoltage, unsigned sleepArg)
in
C:\ti\bios_6_33_04_39\packages\ti\sysbios\family\c674\pmi\pmi_slp.c
The behavior is:
1. It can ALWAYS come into DEEPSLEEP successfully and the current draw becomes minimal.
2. The "sleep-wake" cycle we test is very quick, each is within 5 seconds. We always found that after some successful cycles the code would then fail to wake up, and in order to find out the position whether the code has actually hang we inserted some GPIO "markers" in the code which looks like:
line xx: GPIO PIN 1, 2, 3, 4 = [0 0 0 1]
line xx: GPIO PIN 1, 2, 3, 4 = [0 0 1 0]
line xx: GPIO PIN 1, 2, 3, 4 = [0 0 1 1]
...
line xx: GPIO PIN 1, 2, 3, 4 = [1 1 1 1]
and use these snippets to separate the code into blocks so if the program hangs at a certain block we could read the location out from the GPIO pins. Our tests indicate that the code could hang at our code part corresponding to
/* poll until SLEEPCOMPLETE bit indicates awake from deep sleep */
do {
awake = REG(DEEPSLEEP_REG) & SLEEPCOMPLETE_BIT;
} while (awake == 0);
in the PMI_sleepCPU() function above, i.e., in the loop polling for DEEPSLEEP.SLEEPCOMPLETE bit.
Our "sleep-wake" cycle is controlled by virtual buttons on the LCD touchscreen and we operate quickly in a 5-second pace as said above, and the record is:
Least: we could go through 15 "sleep-wake" cycles before hanging at the location above.
Most: we could go through 86"sleep-wake" cycles before hanging at the location above.
The code controlling entering-exiting DEEPSLEEP mode is placed in 128KB internal memory since we would put DDR2 into self-refresh mode, as have been detailed in RE: Code placement for L138 DEEPSLEEP mode?.
Questions:
1. Are we "sleep-wake"ing the chip too frequently so the waking up failed? The chip when awake is running at 300MHz and I think 5 secs is really a macroscopic time for it, so it seems very unlikely to me that this pace could be cause of the issue.
2. Is our use of GPIO "markers" sound? There is one possible case that the "markers" could not locate: due to some errors during the waking-up attempt the CPU runs into an exception (abort exception, etc.) and the PC points to some undefine location or into the ROM. My "markers" cannot know whether this actually happened.
a. I would like to know does TI has the ability to "intrude" during these "half-alive-half-dead" moments? If I attempt JTAG connection they would fail at those moments, hence I have no access to its internal status. Do chip's designers/manufacturer have some advanced capability/instrument to know what is going on under these circumstances?
Paul