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

TM4C129XNCZAD: SysCtlClockFreqSet always switches to SYSCTL_OSC_INT (PIOSC)

Klaus Breining64693
Intellectual 540 points
Part Number: TM4C129XNCZAD

I try to set the system clock to about 8MHz, using an external 25MHz crystal (result should be then 8.33MHz). I am using TivaWare 2.1.4.178 with the following code:

g_ui32SysClock = SysCtlClockFreqSet((SYSCTL_OSC_MAIN | SYSCTL_USE_OSC | SYSCTL_XTAL_25MHZ), SYSFREQ_STANDBY);

The result is 5,365MHz, however, which is a result of PIOSC/3 (16MHz/3), but the function returns 8.33MHz.

Checking the code of the library, I saw, that everything is set-up correctly, but then in the last line of the function there is:

    //
    // Finally change the OSCSRC back to PIOSC
    //
    HWREG(SYSCTL_RSCLKCFG) &= ~(SYSCTL_RSCLKCFG_OSCSRC_M);

If I look into older versions of the driverlib (2.1.2.111), this code is missing and the function works fine. Has there a bug been introduced or is there some strange intention behind this last line?

Regards

Klaus

  • 0
    TI__Guru 72500 points
    Hi Klaus,
    Thank you for pointing this out. It does not look right to me either. I am having this looked into.
  • 0
    TI__Guru**** 244400 points
    Hello Klaus,

    The change has been made in TivaWare 2.1.3.156 onwards for the SysCtl#22 and SysCtl#23 errata.
  • 0 in reply to Amit Ashara
    Intellectual 540 points

    Hi Amit,

    I understand this has been done for fixing SysCtl#22 and 23. Nevertheless I think the fix is wrong for some cases: whenever you want to use the main oscillator, this statement leads to a switching back to PIOSC. It is not possible to use the main oscillator without PLL. And even worse: The return value is the wrong frequency.

    By the way, in my opinion, there is another bug in the same function (not critical for me, as I am using a 25MHz oscillator):

    //
    // Increase the drive strength for MOSC of 10 MHz and above.
    //
    if(i32XtalIdx >= (SysCtlXtalCfgToIndex(SYSCTL_XTAL_10MHZ) -
             (SysCtlXtalCfgToIndex(SYSCTL_XTAL_5MHZ))))

    I think the subtraction of the 5MHz index is wrong. The subtraction leads to a value of 7, which means, that the drive strength is switched at a frequence of >= 4.9152MHz instead of 10MHz.

    Best Regards

    Klaus

  • 0 in reply to Klaus Breining64693
    TI__Guru**** 244400 points
    Hello Klaus

    The SYSCTL#23 explicitly states that using the MOSC for the Oscillator Source is not a valid combination (See the first line in the Workaround(s)).

    As for the code piece, I agree that is incorrect. It should have been a simple compare.
  • 0 in reply to Amit Ashara
    Intellectual 540 points

    Ok, thanks. I just now saw the content of SYSCTL#23, as there is the new document. My old one ended with SYSCTL#21. I will  have to check the power dissipation of the PLL, as I wanted to use the MOSC for a lower frequency in standby mode. But the accuracy of the other oscillators is not good enough.

    Thanks and Best Regards

    Klaus