• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 98 subscribers
  • Views 359 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.

66AK2G12: Reset when configuring PLL

Laurent Guillier
Prodigy 90 points
Part Number: 66AK2G12

Hi,

my customer designed its own 66AK2G12 board, mainly from K2GICE and K2GEVM schematics.

When porting u-boot (from Processor SDK Linux 05_03_00_07: Based on version 2018.01,  git.ti.com/.../ti-u-boot, Branch: ti-u-boot-2018.01, Commit 313dcd69) to this new board, we encountered a problem when configuring PLL.

The main differences between K2GICE and my customer's board regarding the CPU core schematics are:
- SYSOSC is 25MHz instead on 24MHz on K2GICE
- BOOTMODE[8..6] set accordingly

Porting u-boot on the new board mainly consisted on removing all code related to ID ROM, and 'forcing' 66AK2G12 uC recognition.

This adapted u-boot version runs smoothly on K2G ICE board, but on the new board the CPU resets when configuring the PLL.
Using the XDS200 JTAG probe, and running step by step, we found that the reset occurs when executing the following line in arch/arm/mach-keystone/clock.c (https://git.ti.com/cgit/ti-u-boot/ti-u-boot/tree/arch/arm/mach-keystone/clock.c?h=ti-u-boot-2018.01#n159):

pllctl_reg_setbits(data->pll, ctl, PLLCTL_PLLEN_MASK);

Beyond that, if the pll init stage is skipped, the u-boot code runs OK (init, relocation, welcome message and prompt, commands invokation ...)

Do you fellows have ever met this kind of problem ? What root cause may lead to a reset when setting the PLLEN ?
Thanks for sharing your related issues - and hopefully, solutions!

Regards

Laurent

  • 0
    TI__Guru 50170 points

    Hi, Laurent,

    Could you elaborate more on the design is from K2GICE and K2GEVM schematics? Were some components/peripherals from K2GICE and some from K2GEVM?

    We have not seen issue this type of behavior, but I am checking internally to see if there anything may be causing it.

    Rex

  • 0 in reply to Rex Chang
    TI__Guru 50170 points

    Hi, Laurent,

    I checked with hardware expert, and it seems that The following conditions may cause what your customer saw:

    The biggest issue we have seen associated with the PLL setup is the additional current draw once the PLL is enabled.  Once the PLL is set up and enabled the device will immediately begin to draw more power.  If the customer PDN solution is not sufficient, this will result in a droop on the core voltage causing it to go out of spec.  This can cause the behavior observed.  Secondly we’ve seen the customer incorrectly program the PLL causing the device to clock so fast that the processor can’t operate correctly. 

    -          The customer should check the voltage levels at the device on the input voltage so see if there is any droop when the PLL is enabled.  If there is they need to review their PDN solution.

    -          The customer should measure the frequency on the SYSCLKOUT and be sure they are configuring the PLL correctly. 

    Rex

  • 0 in reply to Rex Chang
    Prodigy 90 points

    Hi Rex,

    thank you for your quick and effective answer!

    We will check the core voltage level upon setting the PLLEN bit, and feed you back with the results.

    Thanks

    Laurent

  • 0 in reply to Laurent Guillier
    Prodigy 90 points

    Hi Rex,

    Indeed the 0,9V core voltage supply is "pulsing" when the PLLEN bit is set, and this is what triggered the reset via the power supply monitoring circuit ...

    Thanks for your precious help, problem solved!

    Best Regards,

    Laurent