• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Subscribers 31 subscribers
  • Views 251 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.

Original question:

MSPM0G3507: Regarding SYSPLL_ERR_01

MSPM0G3507: Clock accuracy according to FCC in SYSPLL_ERR_01

K.Z
Genius 3215 points

Part Number: MSPM0G3507

Hi All,

SYSPLL_ERR_01 includes a WA by FCC.

The clock accuracy of 5% does not refer to the accuracy of SysPLL itself. Rather, when using FCC, LFCLK (3%) and SYSOSC (1%) are utilized, so including the margin, 5% makes sense.

In other words, if you encounter a PLL that does not lock, you must use FCC, which results in an error of 5%.
If the PLL is functioning normally, FCC does not need to be used, so the clock accuracy depends on the clock source (for example, if SYSOSC and a normal PLL are used, it becomes 1%).

My understanding is that if you encounter a PLL that does not lock, you must restart the PLL until it locks. Is this correct?
Also, I have a question about the meaning of “does not lock.”
For example, if SYSOSC = 16 MHz and you multiply it by PLL to get 32 MHz, does “not locking” mean it stays at 16 MHz? Or does it mean the accuracy becomes worse? If the accuracy becomes worse, what level of accuracy should we expect?

Best Regards,

Ito

  • 0
    TI__Mastermind 29715 points

    Hi Ito,

    K.Z said:
    My understanding is that if you encounter a PLL that does not lock, you must restart the PLL until it locks. Is this correct?

    That is correct.

    If the PLL output clock is exist but not correct, it might impact your application logic. (communication error if the PLL clock has large difference compared to expectation).

    K.Z said:
    Also, I have a question about the meaning of “does not lock.”

    It more accurate to state that the PLL does not lock to correct frequency.

    That means, the PLL clock is incorrect but stable. For example, SYSPLL output 79MHz rather than 80MHz (user set in their code).

    B.R.

    Sal

  • 0 in reply to Sal Ye
    Genius 3215 points

    Hi Sal,

    I now understand the meaning of “does not lock.”
    We often receive questions from customers asking, “Within ± what % does it not lock?” (e.g., ?MHz ~ 80MHz ~ ?MHz).
    Is there no specific variation data available?
    Or is the variation completely random?
    Best Regards,
    Ito
  • 0 in reply to Sal Ye
    Genius 3215 points

    Hi Sal,

    This is an additional question about the meaning of “does not lock.”
    For example, if the target frequency is 80 MHz, does it mean that it ends up locking at 79 MHz?
    Or does it mean that when the target frequency is 80 MHz, it fluctuates within the range of 79 MHz to 81 MHz?
    In other words, could it happen that when PLLEN is switched from 0 to 1 the first time, the frequency is 79 MHz, but when PLLEN is switched from 0 to 1 the second time, it becomes 81 MHz?

    Best Regards,

    Ito

  • 0 in reply to K.Z
    TI__Mastermind 29715 points

    Hi Ito,

    K.Z said:
    Is there no specific variation data available?

    No specific variation data. We observe more often with lower frequency but it has possibilty larger than the setting.

    K.Z said:
    For example, if the target frequency is 80 MHz, does it mean that it ends up locking at 79 MHz?

    Yes, locked stable frequency in 79MHz, not fluctuation between 79 to 81MHz.

    K.Z said:
    In other words, could it happen that when PLLEN is switched from 0 to 1 the first time, the frequency is 79 MHz, but when PLLEN is switched from 0 to 1 the second time, it becomes 81 MHz?

    This also correct, the next time it might be a differenct incorrect frequency.

    While this issue occurs with a very low possibility, I don't see the case in my bench test that the frequency is locked incorrect continously with 2-times.

    B.R.

    Sal

  • 0 in reply to Sal Ye
    Genius 3215 points

    Hi Sal,

    Thank you for your reply.

    What would be the accuracy (±%) for devices that fail to lock?
    The customer is concerned about how much the value might vary from the configured setting. For example, when set to 80 MHz, what is the actual range where the value does not lock? Has such data not been collected yet?

    Best Regards,

    Ito

  • 0 in reply to K.Z
    TI__Mastermind 29715 points

    Hi Ito,

    K.Z said:
    What would be the accuracy (±%) for devices that fail to lock?

    No deviation is finalized.

    It is various and can be lower to KHz. I do not see the bench test show higher than the setting frequency, but possible to higher than 80MHz (example).

    B.R.

    Sal

  • 0 in reply to Sal Ye
    Genius 3215 points

    Hi Sal,

    I have reviewed the sample code.

    The accuracy range is ±0.3%, but is that because the clock source is HFXT?
    If there is any background information, please let me know.

    I wanted to check the variation caused by PLL reconfiguration, so after completing the LFOSC count,
    I disabled the PLL and then immediately enabled it again.
    I ran this algorithm 1,024 times and recorded the LFOSC count values.

    The average LFOSC count value was 1% lower than the target count value for 64 MHz.
    The variation was -7% to +5% at 3σ.

    In my code, I only implemented:
    Disable PLL → Enable PLL → Wait for PLL stable
    I did not perform any disable/enable operations for SYSOSC.

    I think these results are quite severe. Are there any improvement measures?
    Will this be addressed in the next SDK?

    Best Regards,

    Ito

  • +1 in reply to K.Z
    TI__Mastermind 29715 points

    Hi Ito,

    K.Z said:
    The accuracy range is ±0.3%, but is that because the clock source is HFXT?

    Not exactly.

    The key points is detection the PLL reference clock and output clock both, which can mitigate the reference clock (LFCLK) accuracy impact.

    The boundray limitation defined in the code is the PLL output frequency deviations compared to the PLL reference input clock (SYSOSC or HXFT). It is not the absolute frequency.

    For example, you set the HFXT as 4MHz as SYSPLL reference clock (input clock), and then the real HFCLK is 4.4MHz which has 10%. While during PLL check, its FCC check error can be still within the 0.3% boundray, as the PLL output will be 4.4MHz*20=80.8MHz (ideal).

    K.Z said:
    The average LFOSC count value was 1% lower than the target count value for 64 MHz.

    The real LFOSC count does not matter, as we use the LFOSC for PLL input and output both, even if it has larger offset compared to standard 32768Hz, it only impact some rounding error on the FCC count.

    K.Z said:
    The variation was -7% to +5% at 3σ.

    The variation also does not matter, as we do not treat the LFOSC as a standard 32768Hz clock. Instead, we treat the SYSPLL input clock as a standard clock, then we do judgement on the SYSPLL output frequency.

    As long as PLL is enabled and stabled, the LFOSC count should be fixed with the SYSPLL out frequency.

    B.R.

    Sal

  • 0 in reply to Sal Ye
    Genius 3215 points

    Hi Sal,

    I understood that, based on the LFOSC count value obtained using the FCC,
    we would check the accuracy of the MFCLK via the PLL and determine whether it is necessary to reconfigure the PLL.
    For example, when generating an MCLK of 64 MHz, the LFOSC count value varies by about -7% to +5%.
    In that case, wouldn’t the MCLK be set within a range of 59.52 MHz to 67.2 MHz?
    I assume the explanation you provided is that the LFOSC count value and the MCLK setting value are not in a one-to-one relationship, but honestly,
    I’m not quite grasping it.

    Best Regards,

    Ito