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.

TM4C123GH6PM: How to increase clock speed above 40 MHz?

Part Number: TM4C123GH6PM
Other Parts Discussed in Thread: ASH

Hi,

I am using the function call

SysCtlClockSet(SYSCTL_SYSDIV_5|SYSCTL_USE_PLL|SYSCTL_XTAL_16MHZ|SYSCTL_OSC_MAIN);

for setting the clock.

I get the required (400/(2*5)) =  40MHz clock at the above settings.

When I increase the SYSCTL_SYSDIV_5 factor to SYSCTL_SYSDIV_6, I get the expected 33.3 MHz clock.

When I decrease the divisor from 5 to 3 and use SYSCTL_SYSDIV_3, I should get System control clock as 400/6 = 66.6 MHz
System control clock should have a time period of 15 nS.
One count input to the SysCtlDelay function gives 3 clock cycles delay = 45 nS delay.
The red led on PF1 has been set to be high for 5,00,000 counts. This should give an ON time of red LED as  = 45nS* 5,00,000 = 22.5 mS.
However, the scope shows that the PF1 on time is 25 mS, which means the system control clock is at 60 MHz, not 66.6 MHz. I have attached the scope window showing on time of 25 mS.

Why is this disparity?

  • Greetings,

    balaji sankar said:
    ... the scope shows that the PF1 on time is 25 mS, which means the system control clock is at 60 MHz, not 66.6 MHz.

    I'm not so sure that's a correct conclusion.    Follows my interpretation:

    balaji sankar said:
    One count input to the SysCtlDelay function gives 3 clock cycles delay = 45 nS delay.

    I'm unclear (again) as to, "How you've concluded that the 'System Clock' runs @ 60MHz."   May I ask:

    • Have you attempted to, 'Measure the System Clock?'    (it appears that you are relating the System Clock's frequency to the performance of 'SysCtlDelay()' - only.)     That is not optimal!
    • Did you know that 'SysCtlDelay()' is  'Not famed' as a highly accurate (and consistent) delay generator?    Depending upon the demands upon the MCU - 'SysCtlDelay()' may produce varied timing durations.

    A superior method of monitoring the 'System Clock' would be to employ one of the MCU's Timers to, 'Output a scaled frequency version of System Clock.'    (that scaling makes the measurement easier - and will 'lessen the frequency output's  (drive demands)  upon the Timer's capture of an MCU's GPIO.)

    As a general rule - 'SysCtlDelay()' provides a 'cheap/dirty/eased delay' - but Not one 'famed for high accuracy & precision!'      One of the (many) ARM MCU's Timers - proves superb at providing such accuracy...

    Note too - IIRC - not all division factors may be applied to the System Clock.    (The MCU  manual should properly detail...)

    TAG:  'SysCtlDelay' may not provide an absolutely accurate & consistent delay...

  • Hi cb1_mobile,

    Thank you for the reply.

    I was wrong in using sysCtlDelay to measure the CPU clock. I used SysStlClockGet() function and paused the code to see its output value in expressions window and it was close to 66.66 MHz. Guess the clock was working  fine all this time.

  • Hi back - and thank you my friend.

    You were 'smart enough' to recognize & respond to the 'Ease & Speed' appeal of SysCtlDelay().    Yet you were 'unaware' of the limitations - present w/in this basic function.     When all else fails - RTFM (Read of the Fine user Manual) should be considered.    And in this case - is the 'Controlling Legal Authority' - and warns:

    26.2.2.10 SysCtlDelay
    Provides a small delay.
    Prototype: void SysCtlDelay(uint32_t ui32Count)

    Parameters: ui32Count is the number of delay loop iterations to perform.

    Description: This function provides a means of generating a delay by executing a simple 3 instruction cycle loop a given number of times.   It is written in assembly to keep the loop instruction count consistent across tool chains.  It is important to note that this function does NOT provide an accurate timing mechanism.   Although the delay loop is 3 instruction cycles long, the execution time of the loop will vary dramatically depending upon the application’s interrupt environment (the loop will be interrupted unless run with interrupts disabled and this is generally an unwise thing to do) and also the current system clock rate and flash timings (wait states and the operation of the prefetch buffer affect the timing)

    Do note as well that when System Clock exceeds 40MHz - 'Wait States' may be inserted - lessening the benefits of  that higher frequency...

    Tag:  '123 User Manual's listing of the limitations suffered by SysCtlDelay().