• State TI Thinks Resolved
  • Locked Locked
  • Replies 1 reply
  • Answers 1 answer
  • Subscribers 99 subscribers
  • Views 387 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.

TMS320C5505: PLL Lock is causing issues with Bootloader

Carolus Andrews
Mastermind 23865 points
Part Number: TMS320C5505


Team,

I have a customer using the named IC in a design, and on a small percentage of the boards (and we have run several thousand of them), it sometimes fails to boot.

We have monitored what we can in the design and from what we see, it looks like the PLL is failing to lock up. They have a fairly large, second stage bootloader that configures the interfaces in the DSP.  The PLL is started near the beginning of the bootloader, but no clock speeds higher than 3MHz are used until after it is finished loading. On failed boot attempts, activity stops immediately before talking to the SPI bus with a higher 25MHz speed. They are using a 12.288Mhz core clock. 

My question is about any particular sensitivities of the PLL. I noticed that the requirements of the clock are quite stringent. On Table 6-4 of the datasheet, the timing requirements of the clock specifies the clock should be high and low for 46.6% of the clock period. They are violating this in their standard design, but the boot success did not improve with a squarer clock.

In short, could you answer the following three questions:

  1. What should occur, internal and external to the C5505 prior to starting the PLL?
  2. Is there some initialization that needs to occur before starting the PLL?
  3. What is the easiest way to determine if the PLL is locked?  Enable the CLKOUT pin?
  • 0
    TI__Mastermind 30170 points
    Hi Carolus,

    Can you confirm that the issue with the PLL occurs in the secondary bootloader, and not in the primary bootloader?

    I recommend using the PLL initialization from the latest CSL example, and seeing if it prevents this failure. There were some improvements to the wait times in the most recent CSL release.
    Download C55XCSL-LOWPOWER from http://www.ti.com/tool/sprc133
    The CSL PLL example installs to this path: <INSTALL_PATH>\c55_csl_3.08\ccs_v6.x_examples\pll\CSL_PLL_Example\csl_pll_example.c
    In the PLL initialization, omit the lines where PLL is bypassed and re-enabled. These are just there for demonstration purposes (that you do not need to fully re-init PLL after it has been initialized once then bypassed)
    status = PLL_bypass(hPll); //demonstrates the PLL bypass and power down
    status = PLL_enable(hPll); //demonstrates PLL power up & enabling with the previous configuration

    The PLL configuration should be checked for validity with the PLL calculator tool:
    processors.wiki.ti.com/.../C5505_PLL_Calculator_060210.zip

    Refer to this E2E thread where a customer found that their PLL init issue was caused by code optimization. The debugging steps can be repeated here for this customer also.
    e2e.ti.com/.../2465848

    1) What should occur, internal and external to the C5505 prior to starting the PLL?
    Before releasing reset, all voltages and clocks must be up and stable.
    The primary bootloader should complete and pass execution to the application or secondary bootloader.
    The primary bootloader has a timer wait for the trimmed bandgap and LDOs to stabilize before passing control to the application.

    2) Is there some initialization that needs to occur before starting the PLL?
    After the primary bootloader completes, the PLL is running. Before deactivating and re-initializing it, peripherals must be idled smoothly and clock gated. After PLL init, the peripherals should be reset with the peripheral resets.

    3) What is the easiest way to determine if the PLL is locked? Enable the CLKOUT pin?
    There is no reliable status indicator, except for waiting the prescribed 4ms for it to lock.
    CLKOUT can be enabled to monitor the SYSCLK, which is generated by the PLL, but it cannot be used as an indicator that the PLL has locked. Though it will give you an idea.
    CLKOUT is also useful to monitor bootloader progress - it is enabled at reset, and then disabled by the primary bootloader very early in its execution.

    Looking forward to debugging this issue with you.

    Hope this helps,
    Mark