• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 83 subscribers
  • Views 1415 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.

PLL Setup

Joel Kuehner
Prodigy 80 points
Other Parts Discussed in Thread: TMS320F28335

On the TMS320F28335, we set up the PLL as follows:

  1. Set PLLSTS.DIVSEL to 0
  2. Set PLLCR.DIV = 10
  3. Wait for PLLSTS.PLLLOCKS
  4. Set PLLSTS.DIVSEL = 2 (divide by 2)

We have a 24 MHz oscillator, with a desired SYSCLKOUT = 120 MHz.  It was recommended by TI that we use this configuration with a divide by 2, rather than simply using PLLCR.DIV = 5 with no divider.

My first question is regarding the clock frequency between steps 2 and 4.  Once PLLCR.DIV = 10 takes effect, our frequency is 240 MHz.  I see no way around this with the stipulation that PLLSTS.DIVSEL must be 0 while altering PLLCR.DIV, and the stipulation that we should use divide by 2.

1. Is it OK for the frequency to be > 150 MHz while waiting for PLL lock?  If so, for how long is it acceptable to have the frequency at 240 MHz?  Are there limits on the instructions we can execute during this wait?

2. Also, is step 3 required?  If we executed steps 1, 2 and 4, then executed some other instructions, then waited for PLL lock before executing time-critical code, would that be acceptable?  Or will the PLL configuration somehow not take effect if we don't wait for PLL lock before setting DIVSEL?  In other words, I'd like to do something like

  1. Set PLLSTS.DIVSEL to 0
  2. Set PLLCR.DIV = 10
  3. Set PLLSTS.DIVSEL = 2 (divide by 2)
  4. Perform cinit, RAM zeroing, etc.
  5. Wait for PLLSTS.PLLLOCKS

Would this be acceptable?

Thanks,

- Joel

  • 0
    TI__Genius 15381 points

    Joel Kuehner said:

    1. Is it OK for the frequency to be > 150 MHz while waiting for PLL lock?  If so, for how long is it acceptable to have the frequency at 240 MHz?  Are there limits on the instructions we can execute during this wait?

      When PLLSTS.DIVSEL is set to 0, the clock divider is /4 not /1 so you will not be exceeding the device clock rate between steps (2) and (3)

    Joel Kuehner said:

    2. Also, is step 3 required?  If we executed steps 1, 2 and 4, then executed some other instructions, then waited for PLL lock before executing time-critical code, would that be acceptable?  Or will the PLL configuration somehow not take effect if we don't wait for PLL lock before setting DIVSEL?  In other words, I'd like to do something like

    1. Set PLLSTS.DIVSEL to 0
    2. Set PLLCR.DIV = 10
    3. Set PLLSTS.DIVSEL = 2 (divide by 2)
    4. Perform cinit, RAM zeroing, etc.
    5. Wait for PLLSTS.PLLLOCKS

    Would this be acceptable?

    TI does not recommend running critical code while waiting for the PLL to lock.

  • 0 in reply to Joe Prushing
    Prodigy 80 points

    Joe Prushing said:

    2. Also, is step 3 required?  If we executed steps 1, 2 and 4, then executed some other instructions, then waited for PLL lock before executing time-critical code, would that be acceptable?  Or will the PLL configuration somehow not take effect if we don't wait for PLL lock before setting DIVSEL?  In other words, I'd like to do something like

    1. Set PLLSTS.DIVSEL to 0
    2. Set PLLCR.DIV = 10
    3. Set PLLSTS.DIVSEL = 2 (divide by 2)
    4. Perform cinit, RAM zeroing, etc.
    5. Wait for PLLSTS.PLLLOCKS

    Would this be acceptable?

    TI does not recommend running critical code while waiting for the PLL to lock.

    [/quote]

    Hi Joe,

    Thanks for the reply. 

    Does TI not consider the code that waits for PLL lock to be critical code?  Are the instructions used to wait for PLL lock guaranteed to function correctly, or is there some chance they will not function correctly?

    - Joel

  • 0 in reply to Joel Kuehner
    TI__Guru* 92200 points

    Joel Kuehner said:

    Hi Joe,

    Thanks for the reply. 

    Does TI not consider the code that waits for PLL lock to be critical code?  Are the instructions used to wait for PLL lock guaranteed to function correctly, or is there some chance they will not function correctly?

    - Joel

    Joel,

    Most, if not all, of TI examples loop while the PLL is locking.  Often we disable the watchdog, but you are correct that there is still code executing that needs to execute correctly.   I do not know of any issues reported doing this on devices such as the 2833x – if there were issues, then the number of customers reporting a problem would be quite large and I believe we would be aware of an issue. Our design specification also does not caution against running non time-critical code during lock.   If you would rather have the CPU in a deterministic state during PLL lock, you could put the CPU in IDLE mode and setup a CPU timer and interrupt to wake it once the lock time has expired.  The PLL takes 131,072 XCLKIN cycles to lock.

    Regards,

    Lori

  • 0 in reply to Lori Heustess
    Prodigy 80 points

    Lori Heustess said:

    Most, if not all, of TI examples loop while the PLL is locking.  Often we disable the watchdog, but you are correct that there is still code executing that needs to execute correctly.   I do not know of any issues reported doing this on devices such as the 2833x – if there were issues, then the number of customers reporting a problem would be quite large and I believe we would be aware of an issue. Our design specification also does not caution against running non time-critical code during lock.   If you would rather have the CPU in a deterministic state during PLL lock, you could put the CPU in IDLE mode and setup a CPU timer and interrupt to wake it once the lock time has expired.  The PLL takes 131,072 XCLKIN cycles to lock.

    Hi Lori,

    Thanks for the answer. 

    We're not so much worried about whether the PLL lock wait will work reliably (we assume it will, based on the same reasoning you cited).  Rather, we're trying to figure out whether we can use the time prior to lock to do something useful.  Joe's response implies we cannot (since it would be critical code), while your response implies that we can (since it would not be time-critical code).

    Summarizing, this thread now has the following two statements from TI:

    • TI does not recommend running critical code while waiting for the PLL to lock.
    • TI's design specification does not caution against running non time-critical code during lock.

    The subtle difference is that the first statement does not use the term "time-critical", but simply "critical".  Pretty much all of our code is critical (it all has to work), but it is not all time-critical (it does not all have to complete in a specified amount of time).

    Recall that my original question #2 was whether we could do the following:

    1. Set PLLSTS.DIVSEL to 0
    2. Set PLLCR.DIV = 10
    3. Set PLLSTS.DIVSEL = 2
    4. Perform cinit, RAM zeroing, etc.
    5. Wait for PLLSTS.PLLLOCKS

    Step 4 is not time critical, but it is critical (it has to work).

    So I guess I'll repose the question.  Would this sequence be acceptable, given that step 4 is not time critical?

    Thanks,

    - Joel

  • 0 in reply to Joel Kuehner
    TI__Guru* 92200 points

    Joel,

    Yes, non time-critical tasks are allowed during PLL lock.  Meaning they do not depend on the full CPU frequency and they are executed at the slower clock speed.

    -Lori

  • 0 in reply to Lori Heustess
    Prodigy 80 points

    Excellent.  Thank you!!

    And thanks to Joe for answering my question #1.

    - Joel