• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 29 subscribers
  • Views 1111 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 slip and oscillator fail tests.

Francisco Torres
Intellectual 585 points

Hello,

I am writing a test to verify the forwarding of pll1 slip error, pll2 slip error and oscillator failure error to ESM module (so ESM group 1 channel 10, 42 and 11 are activated.).

I have copied function checkPLL1Slip(), checkPLL2Slip() and checkClockMonitor() from file sys_selftest.c, generated by halcogen. Everything works as expected, I can see ESM group 1 channel 10, 42 and 11 activated when the functions runs.

In my test I am also logging data through serial cable (I am using a Hercules board). Before running any of the previous mentioned functions I can see logs in serial port correctly, but after running this function all I can see is some strange symbols and after some time serial log is correct again.

I would need to know why logging in serial port does not work correct after this test and fix it.

Do I need to include any kind of waiting time after calling any of those functions to ensure that all clocks are correct?

Regards,

Francis.

  • 0
    TI__Mastermind 49120 points
    Hi Francis,

    The clock domain used by the SCI module is VCLK. This domain clock is divided down from HCLK. I suppose that you have chosen PLL1's output clock to be the source for the GCLK/HCLK/VCLK domains. This is done in system.c via the mapClocks() function.

    When you disturb the PLL1 by causing a slip condition, all clock domains using PLL1 are switched over to using the main oscillator. This directly affects the baud rate of the communication and hence you see garbage on the terminal.

    One way you can choose to get around this issue is to switch the G/H/VCLK domains' clock source over to the HF LPO (typically 10MHz). Calculate all serial port communication settings for a 10MHz VCLK so that the serial logger works correctly through the testing. After the test is done, you can update the SCI module with settings assuming a faster (PLL1) VCLK, and then switch the G/H/VCLK domains over to the chosen PLL1 output.

    Regards,
    Sunil
  • 0 in reply to Sunil Oak
    Intellectual 585 points

    Hello Sunill,

    Thanks for your help. Yes, I have GHVSRC bits 3-0 set to 0x1 (this is PLL1).

    Yes, I understand why I can see some garbage in the terminal (serial line). I do not need to log anything during the test (so no need to switch to the oscillator).

    My problem is that after functions checkPLL1Slip()/checkPLL2Slip()/checkClockMonitor() are finished I can still see some garbage on serial line for some time. So if I add a while() loop with a few thousands iterations after those function the logs are correct but if I remove this loop part of the logs are garbage AFTER those functions.

    Maybe I am wrong but this indicates that the clock used in SCI (VCLK) needs some time to be stable after any of these functions run.

    It is ok for me to have a delay (actually inside the functions they are some wait times but I need to know if there is any bit that indicates when clocks are stable again, or at least the maximum time that I need to wait for the clocks to be stable again.

    Best Regards,

    Francis.

  • 0 in reply to Francisco Torres
    TI__Mastermind 49120 points
    Francis,

    The checkPLL* functions do not implement a check at the end of the function to wait for the PLL to acquire lock and be available for use. Instead the GHV clock domains are just switched over to using the PLL output (actually the originally selected source is restored). This causes the GHV clock domains to be "frozen" until the PLL1 output is available again. This PLL locking time is specified in the datasheet.

    So you have two options:
    1) Modify the checkPLL1Slip function to wait for the PLL to acquire lock. You can poll the CSVSTAT register bit 1 to be set.
    2) Switch over to HF LPO as the source for GHV clock domains while you are testing the PLLs and oscillator fault responses. Then you can reconfigure the PLLs as required at the end of the tests and resume normal execution at full speed.

    Regards,
    Sunil
  • 0 in reply to Sunil Oak
    Intellectual 585 points

    Hello Sunil,

    I tried option 1) "Modify the checkPLL1Slip function to wait for the PLL to acquire lock. You can poll the CSVSTAT register bit 1 to be set." I added at the end of the function a while loop

    while ((systemREG1->CSVSTAT & 0x1) == 0x0);

    but I can still see garbage in the serial line after checkPLL1Slip() finishes.

    Regarding option 2), I think that function checkClockMonitor() is already doing that with 

    /* Switch all clock domains to HF LPO */
    systemREG1->GHVSRC = 0x05050005U;

    and I have the same problem, even if I add the line while ((systemREG1->CSVSTAT & 0x1) == 0x0);

    Any ideas?

    Thanks a lot for helping.

    Francis.

  • 0 in reply to Francisco Torres
    Intellectual 585 points
    Hello Sunil,

    I think I found the solution.

    As you suggested I need to

    systemREG1->GHVSRC = ghvsrc_bk;

    just at the end, and before that line I can add a wait time as described in spnu499b.pdf "10.5.2.1 PLL Enable".

    With this implementation I see some garbage in the serial line while the test is running, but all logs before and after the test are correct.

    I think I found a problem in checkPLL1Slip(). In this function the secuence is:

    /* Switch back to the initial clock source */
    systemREG1->GHVSRC = ghvsrc_bk;
    ........
    /* Restore the PLLCTL1 register */
    systemREG1->PLLCTL1 = pllctl1_bk;

    and I think it should be the opposite.

    Regards,
    Francis.