• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 33 subscribers
  • Views 1824 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.

TM4C1294KCPDT: Clock configuration for tm4c1294 @ 120mhz

nihit bhavsar
Prodigy 175 points

Part Number: TM4C1294KCPDT
Other Parts Discussed in Thread: TM4C1294NCPDT

Hi,

Pardon my silly doubts, after reading datasheet i'm confused about single ended MOSC mode and crystal mode, all I want is system clock of 120mhz.

Some excerpts from tm4c1294 datasheet is confusing me, below I've copy pasted it : 

INITIALIZATION AND CONFIGURATION (System control chapter) : 

-> " If single-ended MOSC mode is required, the MOSC is ready to use. If crystal mode is required,

     clear the PWRDN  bit and wait for the MOSCPUPRIS  bit to be set in the Raw Interrupt Status

     (RIS) , indicating MOSC crystal mode is ready."

  ............ here datasheet says to "clear" PWRDN bit, this contradicts the next point in datasheet as follows,

->  Write the PLLFREQ0  and PLLFREQ1  registers with the values of Q , N , MINT , and MFRAC  to

     the configure the desired VCO frequency setting

How to configure PLLFREQ0 register?

-> EXCERPT FROM PLLFREQ0 SECTION : 

" When controlling this register directly, software must change this value while the

PLL is powered down "

 ..............powered down = write 1 again to PWRDN bit

  

Any help is appreciated.

Thanks

  • 0
    Prodigy 175 points
    part number is tm4c1294ncpdt, sorry for the confusion
  • 0 in reply to nihit bhavsar
    Intellectual 435 points
    Hi Nihit,

    I would suggest you to use SysCtl API to set CPU clock that is easy to use.

    As per my understanding, for your interest of clock config, call API as follows:

    SysCtlMOSCConfigSet(SYSCTL_MOSC_SESRC);
    SysCtlClockFreqSet((SYSCTL_XTAL_25MHZ | SYSCTL_OSC_MAIN | SYSCTL_USE_PLL | SYSCTL_CFG_VCO_480), 120000000);

    In 2nd line above, i assume that your single ended oscillator source is 25MHz

    For using these APIs, you will need to include as below:

    #include "driverlib/sysctl.h"
    #include "driverlib/sysctl.h"

    and also include driverlib.lib generally at location (but may very depending on your installation path; and provided that your have installed tiva ware):

    C:\ti\TivaWare_C_Series-2.1.4.178\driverlib\ccs\Debug\driverlib.lib

    Hope this helps.

    BR,
    Pranav.
  • 0 in reply to Pranav Saraswala
    Prodigy 175 points
    Hi Pranav,

    Thanks for replying, i don't want to use API's due to some reasons,
    I've successfully configured clock with some GPIO's using direct register access i will copy paste it here if anyone intends to use DRA,


    SYSCTL_MOSCCTL_R = ~SYSCTL_MOSCCTL_NOXTAL & ~SYSCTL_MOSCCTL_PWRDN;
    __asm(" NOP");
    __asm(" NOP");
    __asm(" NOP");
    __asm(" NOP");
    __asm(" NOP");


    SYSCTL_RSCLKCFG_R |= SYSCTL_RSCLKCFG_OSCSRC_MOSC | 1;
    SYSCTL_RSCLKCFG_R |= SYSCTL_RSCLKCFG_USEPLL | 1;
    SYSCTL_RSCLKCFG_R |= 0x03000000;
    SYSCTL_RSCLKCFG_R |= SYSCTL_RSCLKCFG_PSYSDIV_M & 1;

    SYSCTL_RCGCGPIO_R = SYSCTL_RCGCGPIO_R12 | SYSCTL_RCGCGPIO_R5; // port N and F

    //Onboard LED's D1 and D2
    GPIO_PORTN_DIR_R = 0xFF;
    GPIO_PORTN_AFSEL_R = 0;
    GPIO_PORTN_DR4R_R = 0xFF;
    GPIO_PORTN_DEN_R = 0xFF;
    GPIO_PORTN_DATA_R = 0x03;

    Note that this is crude implementation and code not clean yet,

    Appreciate your help.

    Nihit
  • 0 in reply to nihit bhavsar
    Intellectual 435 points
    Hi Nihit,

    My understanding is as follows:

    Following POR, power to MOSC circuit is off (equivalent to PWRDN=1).
    If using single ended mode, you are ready to go and do not need to do anything to bit PWRDN of MOSCCTL register. This bit deals only with the power to MOSC circuit only and not with PLL.

    To config PLL frequency, before write to PLLFREQn registers, power to PLL should be down., i.e., bit PLLPWR should be 0 prior to writing PLL frequency parameters in PLLFREQn registers.

    As such, PWRDN and PLLPWR are separate and do not have direct relation. That was the source of your confusion i suppose.

    Moreover, i have one more suggestion here. Since you are trying to config HW_REG through DRA, same is done in API. Referring to API implementation for same thing (whenever you feel lost during your DRA implementation) could be helpful. API implementation codes are available at location C:\ti\TivaWare_C_Series-2.1.4.178\driverlib

    Hope this help.

    BR,
    Pranav.
  • 0 in reply to nihit bhavsar
    TI__Guru**** 191886 points
    Hi,
    Please use the TivaWare library or look at the source code of the TivaWare on how to configure the clock if you want to use DRM. Read #4 in the FAQ e2e.ti.com/.../695568 about the DRM support.
    If you have a direct clock input (not crystal) then you don't need to wait for the crystal/oscillator to settle.
  • 0 in reply to Charles Tsai
    Prodigy 175 points
    thanks for your support
  • 0 in reply to nihit bhavsar
    Guru 117855 points

    nihit bhavsar said:
    ... I don't want to use API's  'due to some reasons' ...

    The inexactness - and/or failure to justify - 'walking such tightrope' (i.e. DRA/DRM code style) - proves 'ALWAYS the CASE' here - does it not?      

    Could it be that:

    • instructor's archaic/misguided demand
    • the quest to 'reinforce learning'  (never/ever positively linked to DRM ... BTW)
    • the desire for code to execute faster - and or occupy lesser footprint

    lead those (sufficiently) misguided - to choose 'DRA/DRM?'   

    Now the deployment of ANY code style - which  'complicates, extends, or introduces RISK'  w/in the MCU's System Clock Setting - is to be, 'Practically & Studiously AVOIDED!'     This as ANY mistake here - may subject the hapless user (and the cadre of equally hapless 'helpers') to the scourge of,  'JTAG/SWD LOCK-OUT!'  

    Risk/Reward Analysis dictates that  (high-risk) 'DRA/DRM' be deployed (if it must) in a, 'LESS CONSEQUENTIAL AREA/MANNER' - such that the (inevitable missteps)  prove less destructive... 

    'Some Reasons'  (poster's justification for DRA/DRM) has a long & hard road to travel - to overcome the damaging impact - invited (by this poster) - to (his own) doorstep!