• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 100 subscribers
  • Views 1158 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.

MPU PLL produces very slow clock

Ivan Frederiks
Intellectual 370 points

Other Parts Discussed in Thread: AM3352

Hello!

I'm currently working with AM3352 and I got troubles with MPU PLL operation.

I use custom board with 25 MHz main oscillator. I use standard PLL setup sequence with following parameters:

  • N = 24
  • M = 550
  • M2 = 1

I run simple test:

  • GPIO pulse
  • empty loop with 100 iterations (7 instructions per iteration)
  • GPIO pulse

Distance between pulses (observed on the oscilloscope) is ~31.2 us. It means that MPU runs at (7*100*10E6)/31.2 ~= 22.6 MHz

PLL does not seem to be bypassed: distance between pulses changes when I change PLL parameters (I tried to change N, M and M2). When I set N to 0 or M to 2047 PLL refuses to lock.

Other PLLs (Core, Peripheral, DDR) seem to work fine: I tested their outputs using CLKOUT2 and got correct frequencies.

Looks like MPU PLL input is connected to wrong signal, but there is no user option for PLL input selection...

Please help me to put MPU and its PLL into normal state. Thank you in advance!

  • 0
    TI__Guru**** 393215 points
    Hi Ivan,
     
    The PLL parameters you list would give a MPU clock frequency of 550MHz. However you should be aware that the GPIO is connected to the L4 standard peripheral interconnect, which interfaces to the L3 slow interconnect. The ARM MPU is connected to the L3 fast interconnect, which is connected to L4 through L3 slow. The fastest interconnect clock to the GPIO is 100MHz. The pulse period you measure does not give information about the real MPU frequency, but rather about the total possible GPIO performance. MPU caches being enabled/disabled will also influence this.
  • 0 in reply to Biser Gatchev-XID
    Intellectual 370 points

    Hi Biser,

    thank you for reply! Time between pulses has linear dependency on number of iterations in the loop. With 200 iterations test takes twice longer to execute. GPIO performance is not related to my problem.

  • 0 in reply to Ivan Frederiks
    TI__Mastermind 30845 points

    Hi Ivan,

    - Try changing the PLL settings to run CPU at 300, 400, 500, 600 Mhz and see if you see a linear increase in the GPIO period you measure.

    - The Clock tree tool can help you to understand the clock tree:
    http://www.ti.com/tool/clocktreetool

    - Also I am not sure what target SW you are using. If you can hook a JTAG emulator then you could use the GEL file of some of the development board to setup the PLL. Different MPU clock frequency settings are supported by the GEL files:
    http://processors.wiki.ti.com/index.php/OMAP_and_Sitara_CCS_support#GEL_Files_9
    I have not seen any problems using teh GEL file to setup the MPU clock.

    A.

  • 0 in reply to AnBer
    Intellectual 370 points

    Hi AnBer,

    thank you for reply! I tried to change PLL settings as you suggested and got following results:

    200 iterations, 7 ASM instructions per iteration
    MPU_M test execution time, us
    100 210
    200 120
    300 90
    400 75
    500 66
    600 58
    2000 iterations, 7 ASM instructions per iteration
    MPU_M test execution time, us
    100 2000
    600 550
    20000 iterations, 7 ASM instructions per iteration
    MPU_M test execution time, ms
    100 20.5
    300 8.5
    500 (ROM boot default, no MPU PLL setup performed) 6.2
    600 5.44

    I hope this data will help to find solution for this issue.

    I already tried the Clock tree tool (before posting to E2E) and compared all affected registers. Everything seems to be fine.

    Concerning target SW: I use StarterWare bootloader and one of examples with minimum modifications.

  • 0 in reply to AnBer
    Intellectual 370 points

    Hi AnBer,

    I found the root of this issue: I used CacheEnable(CACHE_ICACHE) instead of CacheEnable(CACHE_ALL).