SYSBIOS code modifies reserved bit of L138/C6748?

Paul,

This code sequence is intentional.  It was originally written based upon TI-internal device specifications.  Looking at some of the early TI-external reference guides (e.g., SPRUGM7A from July 2009), the bit was described and was included in the prescribed sequence for initializing the PLL following power down:

<snip>

4. Set the PLLDIS bit in PLLCTL to 1 (disables PLL output).
5. Clear the PLLPWRDN bit in PLLCTL to 0 (brings PLL out of power-down mode).
6. Clear the PLLDIS bit in PLLCTL to 0 (enables PLL) to allow PLL output toggling. Note that the PLLC is still in PLL bypass mode; therefore, the toggling PLL output does not propagate to the rest of the device.

<snip>

The “DIS” indicated “disabled”: “0 = PLL is not disabled, 1= PLL is disabled”

I don’t know why more recent reference guides don’t include the steps of toggling PLLDIS, but my guess is that it was later found to be unnecessary.  This is just a guess though.  To find out exactly why it is no longer documented would require looping in the device team, or posting to one of the device forums.

Scott

Scott,

Thanks very much for this prompt and useful answer.

First, my code doesn't include PLL_PLLDIS_BIT set and reset bits and it looks like

#define PLL_LOCK_TIME_CNT 2400

PLL0_PLLCTL &= ~(0x00000008);

/*Power up the PLL by setting PWRDN bit set to 0 */

PLL0_PLLCTL &= ~(0x00000002);

/*Set the PLLRST bit in PLLCTL to 1 to bring the PLL out of reset*/

PLL0_PLLCTL |= 0x8;

/*Wait for PLL to lock. See PLL spec for PLL lock time*/

{unsigned short i=0; for(i=0; i<PLL_LOCK_TIME_CNT; i++);}

PLL0_PLLCTL |=  0x1;

PLL1_PLLCTL &= ~(0x00000008);

/*Power up the PLL by setting PWRDN bit set to 0 */

PLL1_PLLCTL &= ~(0x00000002);

/*Set the PLLRST bit in PLLCTL to 1 to bring the PLL out of reset*/

PLL1_PLLCTL |= 0x8;

/*Wait for PLL to lock. See PLL spec for PLL lock time*/

{unsigned short i=0; for(i=0; i<PLL_LOCK_TIME_CNT; i++);}

PLL1_PLLCTL |=  0x1;

And out of my numerous (several thousands, described in DEEPSLEEP wake hangs at SLEEPCOMPLETE testing) tests I recorded perhaps only one time that the waking up process hangs within the code segments above, and it seems weird because the lines here do not include any while-polling loop which has the potential to hang. I didn’t figure out the reason and could not reproduce it. Do you think it could possibly be related to the missing of the four (2 for PLL0, 2 for PLL1) PLL_PLLDIS_BIT modification lines here?

Second, could you help to move this entire thread to the OMAP L13x forum? I could only copy my own thread but I would like to preserve your answer as an integral part.

Third, I googled ti.com and could not found the SPRUGM7A document. Could you upload one here or send a copy to me?

With sincere thanks,

Paul

Additionally the current silicon revision for OMAP L138 is at least 2.1 and there should have been considerable amount of change during over the three years. Could you ask the L138 designers on this issue?

Paul

Paul,

I think it is possible that the lack of toggling of the PLL disable bits could be making a difference in the consistency of your sleep/wake cycles.  (Because, these seem like logical steps in such a sequence to ensure proper module transitions.)  I don’t know for sure, so moving this thread to the L138 forum is a good next step.    That is the best place for device revision questions too.  I cannot move the thread myself, but will ask that it be moved…

Scott