Part Number: TM4C1294KCPDT
I have a question about SysCtlClockFreqSet when configuring to use the PLL with the MOSC as its source. I see that the function does the following in that case:
I'm wondering why OSCSRC is changed to MOSC in #4 and if it's really necessary. I don't see any obvious purpose. It also seems strange to change to PIOSC and then almost immediately change to MOSC. Perhaps the second change was only intended to change PLLSRC? The errata seems to support this: "It sets the OSCCLK as MOSC which is not required".
This probably wouldn't matter in a typical system with a crystal, but I have a clock source that may take some time to come up. I do have something in place to delay calling SysCtlClockFreqSet until after the clock is ready, but I suspect that that may be failing on occasion.
I had originally expected a dead clock input to result in a timeout waiting for PLL lock in #5, but it seems that I missed the second change to OSCSRC in #4 which kills the CPU first. There is some opportunity to recover from that with a watchdog timer, but a timeout error would be more flexible. Also, a watchdog reset at that point is pretty much indistinguishable from a watchdog reset later on in application code and that makes debugging more difficult.
At the moment I'm trying to track down a rare WDT reset shortly after startup. If I can ever reproduce it, I'd like to know if it was during the clock switchover. To that end I've modified SysCtlClockFreqSet to stay on PIOSC until switching to the PLL. It seems to work fine, and I now get a specific error instead of a WDT reset if SysCtlClockFreqSet is called while the clock input is dead. I am a bit worried about possible unintended consequences. Are there any known issues this change could trigger?
EnableWatchdog(1000 /*ms*/); // reset occurs after 2 timeouts
uint32_t clockFreq = SysCtlClockFreqSet(
SYSCTL_XTAL_25MHZ | SYSCTL_OSC_MAIN | SYSCTL_USE_PLL | SYSCTL_CFG_VCO_480,
CPU_CLOCK_HZ // 120 MHz
if (clockFreq != CPU_CLOCK_HZ)
// This is supposed to handle PLL lock failures.
// With stock SysCtlClockFreqSet, it's not triggered if the clock
// input is dead (and the wait is bypassed). In that case a watchdog
// reset occurs.
BB_ To that end I've modified SysCtlClockFreqSet to stay on PIOSC until switching to the PLL.
My opinion is PIOSC should never be the main clock source when external XTAL exists or MOSC has been previously powered up. It seems we have similar issue and was wondering what version of driver lib you are running? I'm using 21171 versus newer 214178 that rudely changes previous Tivaware version PYSDIV bit and PLL frequency divisor register settings.
BB_At the moment I'm trying to track down a rare WDT reset shortly after startup. I
Have you by chance enabled the project Hold watchdog under ARM linker settings?
We are glad that we were able to resolve this issue, and will now proceed to close this thread.
If you have further questions related to this thread, you may click "Ask a related question" below. The newly created question will be automatically linked to this question.
Best Regards,Bob Crosby
In reply to Bob Crosby:
Wonderfully detailed - both by poster & vendor!
Vendor's alternative - although inspired & resourceful - (appears) to be vulnerable to, 'Watchdog Reset potentially being 'in process' (minutely prior) to that 'flag-set!' (thus (maybe) invalidating that safety mechanism - is that not true?)
Clearly anticipating - and overcoming - SO MANY 'Exacting Clock Domain DEMANDS' - proves an 'extreme (often on-going) challenge.'
In reply to cb1_mobile:
Let me expand on that just a bit. What I suggest is setting a "flag" before calling SysCtlClockFreqSet() and clearing that flag after that function completes. If you get a watchdog reset and that flag is "set", then you are reasonably assured that the watchdog reset occurred during that function call. It is true that it is possible the watchdog reset occurs before setting the flag, but then the root cause would be different than the SysCtlClockFreqSet() function.
Thank you - much appreciated.
Now it is well noted - by several here - that the 'SysCtlClockFreqSet()' has, 'Set Near Records for'
I accept your, 'in depth description' especially as you have 'allowed for a 'race or near-race' condition (hedge alert) - earlier noted.
Staff/I 'assume' that 'internal debate waged' over the, 'Depth & Breadth' - demanded by the use of a, 'SINGLE, MCU Clock-Set Function!'
In reply to BP101:
BP101It seems we have similar issue and was wondering what version of driver lib you are running? I'm using 21171 versus newer 214178 that rudely changes previous Tivaware version PYSDIV bit and PLL frequency divisor register settings.
22.214.171.124 - the latest one
BP101Have you by chance enabled the project Hold watchdog under ARM linker settings?
It doesn't seen like something you can accidentally enable for ARM targets since apparently you need to define WDTCTL_SYM for it to work, but no, it's unspecified (off). I don't enable the watchdog until after reaching main.
Bob CrosbyAs an alternative, consider dedicating a static variable that is set as a flag to indicate your are setting the PLL. If a watchdog reset occurs, check that flag to see if you were in the critical portion of code setting the PLL frequency.
That does seem like a safer alternative. Thanks.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.