• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 32 subscribers
  • Views 937 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.

TM4C1294NCPDT: Tivaware and SYSCTL#22 clock limitations

Peter Johansen
Intellectual 935 points
Part Number: TM4C1294NCPDT


For a SSI peripheral we need precisely 16,0MHz clock. It fit's nicely when having a clock for the processor of 96MHz / 6. (SSInClk = SysClk / (CPSDVSR * (1 + SCR)) ). fxtal = 25MHz. Now using the latest Tivaware this frequency is not possible any more. This is due to the errata SYSCTL#22. As we still need the 96MHz clock we need a work around.

The description in the errata does not fully explain the behaviour as it just states:

“When generating system clock from the PLL, the user programs the system control register bits RSCLKCFG.PSYSDIV to divide the PLL output. This register value may not be loaded into the physical divider causing the system clock to be divided by 2. This condition will cause the system clock to be out of specification.”

The clock is calculated :

fIN = fXTAL/(Q+1)(N+1) , 5MHZ>fIN<30MHz

MDIV = MINT + (MFRAC / 1024)

fVCO =(fIN * MDIV)

SysClk = fVCO/(PSYSDIV + 1)

As we have been programming the PSYSDIV successfully for years, there might be some conditions for faulty behaviour. So some questions arise:

1. Is it possible to check for correct programming of PSYSDIV and reprogram if not correct ?

And if yes

2. If the real issue is the SysClk becoming higher than 120MHz, the programming of the PSYSDIV could take place at a lower fVCO initially ?

If we are forced to find the 96MHz as close as possible by forcing/keeping PSYSDIV to the value 1, we will need different values of fVCO. The data sheet does not give the min/max values for fVCO, but it seems that tha max value is 240MHz due to SYSCTL#22.

3. Is the max value for fVCO still 480MHz ?

4. Any min value for fVCO ?

PS. Playing with the numbers and adjusting the crystal by 8 PPM to 24.9998063 MHz, I can get a sysclk of 112MHz precisely to divide by 7 to get the 16MHz needed. Then PSYSDIV = 2, Q=2, N=0.

  • 0
    Guru 56043 points

    Hi Peter,

    Wonder why you don't use 16Mhz PIOSC alternate clock source for SSI module? After recalibration at a specific MCU temperature PIOSC maintains 1% precision.

    #22: The issue will be caused if ROM_SysCtlClockFreqSet or SysCtlClockFreqSet API provided in TivaWare 2.1.2 or earlier is used.

  • 0
    TI__Guru*** 135355 points

    Hello Peter,

    1. Yes. If the PSYSDIV is programmed to a value other than 2 and the PLL’s M, N and Q divider show that the output VCO is 480MHz, then a reprogramming must be done to avoid the errata.
    2. The issue is with System Clock becoming more than 120 MHz. Hence PSYSDIV must be kept at 2.
    3. The maximum value of fVCO is 480 MHz
    4. The minimum value is 100 MHz (Errata ELEC #06).

    You may select a value for the VCO that gives 96MHz system clock. For that the fVCO must be 4 times of the system clock so that Q divider divides it down by 2 and PSYSDIV divider divides it down by 2. This results in a VCO of 384 MHz. With a Crystal value of 25 MHz that may not be possible, but it should be possible with another crystal frequency.

    However, if Ethernet is a must, then the 25MHz crystal is non-negotiable and hence it cannot be used to get exactly 16MHz.

  • 0 in reply to Ralph Jacobi
    Intellectual 935 points
    The idea of using the internal oscillator does not give us the precision required. Yes, we need the 25MHz crystal for the Ethernet interface.

    I would like to have question one more clarified:

    1a. When the comment goes for a division of 2 by setting the parameter PSYSDIV, I guess you mean setting the register PSYSDIV to the value 1 thereby giving a division of 2 ?

    1b. As we have been using the old Tivaware for a long period without noticing problems, we would like to understand the root problem. Is the problem that it is not always programmed correct, and if yes, can we just try again, maybe after some waiting ?
  • 0 in reply to Peter Johansen
    TI__Guru*** 135355 points
    Hello Peter,

    1A) Yes, that is what I had meant, sorry for the lack of clarity.

    1B) The problem arises under any of two conditions:
    1. The device goes through a system reset
    2. The PLL is unlocked and locked again for any run time change to the system clock
    Furthermore, the issue appearance varies from device to device, so just because you are not observing it currently doesn't mean your design is permanently safe from it either. The only 'bullet-proof' way to avoid the errata possibly occurring is to implement the provided workarounds.