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

Problem using SysCtlClockFreqSet() when updating from TivaWare 2.1.2.111 to TivaWare 2.1.3.156

Simon Einfeldt
Prodigy 215 points

Using TivaWare version 2.1.2.111 I have been setting my clock frequency to 96 MHz using SysCtlClockFreqSet() with no problem. After updating to TivaWare 2.1.3.156, the clock frequency is now being set to 80 MHz.

The code I use:

g_ui32SysClock = SysCtlClockFreqSet((SYSCTL_XTAL_25MHZ | SYSCTL_OSC_MAIN | SYSCTL_USE_PLL | SYSCTL_CFG_VCO_480), 96000000);

Executing this line of code using TivaWare 2.1.2.111, the value returned to g_ui32SysClock will be 96000000, but when executing using TivaWare 2.1.3.156, the value returned to g_ui32SysClock will be 80000000.

I know that the SysCtlClockFreqSet() function has been updated in the new version of TivaWare, but it seems as if this update broke something.

Regards,
Simon

  • 0
    TI__Guru 59540 points
    Hi Simon,

    Early in the discussion of the workaround for the SysCtl #22 errata, it was mentioned that the work around created an issue for some frequency settings. Specifically, this was mentioned in one of the threads:

    "There is some restriction that may not be evident which is what we are addressing. E.g. 96MHz is not possible as 240/2 = 120 and 240/3 = 80MHz."

    As it states, this was to be evaluated and addressed but I am not certain how it was addressed. I am going to forward your question to Amit who will be better able to discuss issues regarding the workaround since he worked directly on the debug of the issue and the workaround.
  • 0
    TI__Guru**** 244400 points
    Hello Simon

    Well that is a limitation of the workaround in the function as Chuck also mentioned. The system clock would now be 240MHz/(PSYSDIV+1) or 160MHz/(PSYSDIV+1). This is a trade-off compared to the issue where the system may not work after the system clock is configured.

    Regards
    Amit
  • 0
    TI__Guru 59540 points
    Hello Simon,

    To add on to Amit's comments below, if your application must run at 96MHz, you could choose to continue using the ROM based version of the function without the workaround. Of course, this would come with the risk of being impacted by the errata as described in SYSCTL#22 and SYSCTL#23 so this decision must be made at your own discretion knowing the potential failure modes discussed those erratas.
  • 0 in reply to Chuck Davenport
    Prodigy 215 points

    Thank you for the replies Chuck and Amit.

    Our application hinges on running at 96MHz, so we will have to keep using the old implementation of SysCtlClockFreqSet() with the accompanying risks of error.

    It would have been nice if the limitation (only being able to run at 80MHz or 120MHz) of the new implementation of SysCtlClockFreqSet() had been mentioned explicitly in section 1.3.4 of the release notes for TivaWare 2.1.3.156.

    Regards,
    Simon

  • 0 in reply to Simon Einfeldt
    TI__Guru**** 244400 points
    Hello Simon,

    I can understand that the limitation brought by the new implementation can be annoying and we should have taken steps to add it to the release notes. But if the known errata are not an issue then you can still use the ROM version of the API.

    Regards
    Amit