LAUNCHXL-F280049C: POR may not lock PLL at the intended speed.

This code in SysCtl_setClock() may be the reason for PLL issues after POR event. Why are SYSCTRL CLKCFG registers not in x49c GEL file? How can anyone confirm the OSCCLK is setup correctly or what PPL divisor was set and if clock sources are enabled? 

What if the return condition is false during POR hard landing when the XTAL has not stabilized? Would it be prudent to 4 loop few thousand cycles to see if OSCCLK has even started before flagging an error? It's supposed to force a retry though INTOS2 was running 10MHz after firmware load, perhaps after POR the XTAL harmonic is 40MHz or 2x the Nyquist frequency. Yes that's a wild thought though some very strange things are occurring mostly after POR so... 

//
// Don't proceed to the PLL initialization if an MCD failure is detected.
//
if(SysCtl_isMCDClockFailureDetected())
{
//
// OSCCLKSRC2 failure detected. Returning false. You'll need to clear
// the MCD error.
//
status = false;
}

//*****************************************************************************
//
//! Get the missing clock detection Failure Status
//!
//! \note A failure means the oscillator clock is missing
//!
//! \return Returns \b true if a failure is detected or \b false if a
//! failure isn't detected
//
//*****************************************************************************
static inline bool
SysCtl_isMCDClockFailureDetected(void)
{
//
// Check the status bit to determine failure
//
return((HWREGH(CLKCFG_BASE + SYSCTL_O_MCDCR) & SYSCTL_MCDCR_MCLKSTS) != 0U);
}

I regret I am unable to understand exactly what your issue is. At POR, source for OSCCLK is indeed INTOSC2 and SYSPLLMULT.IMULT is 0, therefore PLL is bypassed. SYSCLKDIVSEL.PLLSYSCLKDIV = 2 upon reset giving an effective divisor of /4. Therefore, SYSCLK out of reset should be around 2.5 MHz. This is the device behavior, not accounting for anything the .gel files may be doing. There is an erratum titled “PLL: PLL May Not Lock on the First Lock Attempt” (see page 18 of www.ti.com/lit/SPRZ439). Please evaluate if this could be impacting your system. If you use the Driverlib functions in the latest C2000WARE, it already incorporates the workaround. 

Hi Hareesh,

Hareesh Janakiraman said:

Please evaluate if this could be impacting your system. If you use the Driverlib functions in the latest C2000WARE, it already incorporates the workaround. 

The INTOS2 is running 10MHz out of UniFlash load firmware and resets do not seem to load the driverlib set clock or PLL higher speeds until after a POR event. The application runs wild yet SCIA-B clock source for baud rate remains consistent either way. 

Where is the debug GEL file update to access to SYSCTRL registers in debug mode they are missing. How can I even verify the PLL is at the correct divisor or what clock source is being used? 

Hareesh Janakiraman said:

There is an erratum titled “PLL: PLL May Not Lock on the First Lock Attempt” (see page 18 of www.ti.com/lit/SPRZ439)

Why is this not in the index under PLL? I checked the advisory tables but no PLL issues listed, then closed the PDF . Must have missed it or was thinking of another issue advisory.

Anyway the PLL over clock frequency issue is persistent at POR. The CPU auto executes some functions that have not been called by the application even in CCS debug this occurs. That is a symptom of overclocking the CPU not listed in the Advisory notes.

The PLL lock workaround is not correcting POR issue, seems to lock PLL on a harmonic of the 20MHz XTAL. Seemingly the workaround is overclocking the CPU >100MHz, hard to know for sure. Applicaiton runs as expected after UniFlash SW reset or CCS debug SW resets, until a POR then all sorts of bad things happen.

//
// Check PLL Frequency using DCC
//
status = SysCtl_isPLLValid(oscSource,
(config &
((uint32_t)SYSCTL_IMULT_M |
(uint32_t)SYSCTL_FMULT_M |
(uint32_t)SYSCTL_ODIV_M)));

Genatco said:

Has there been any extensive testing of PLL locking stability after POR?

Yes.

Genatco said:

What can be done in the clock setting code to ensure the PLL locks after POR on all x49c MCU, not just a select few? 

This device is 5+ years old. With the exception of the erratum mentioned in the device errata, there are no other known issues in the PLL. When the workaround is implemented, PLL will lock correctly. When the Driverlib functions are used, there is no way the device will run at speeds in excess of 100 MHz (of course accounting for the correct input frequency). 

Genatco said:

Why is this not in the index under PLL? I checked the advisory tables but no PLL issues listed, then closed the PDF

Sorry I don't understand. There is no index in the Errata. There is a table for Advisories Matrix on page, which lists this erratum. 

It is highly unlikely this is an issue with the device; likely a s/w issue with the PLL settings such as multiplier and divider.

Hi Hareesh,

I found the cause of POR #pragma control data corruption again only occurred at POR events. Perhaps is more low speed clock related? Adding 800µs-1000µs delay prior to calling SysCtl_setClock() also made no difference with 400µs delay when calling    SysCtl_setLowSpeedClock(SYSCTL_LSPCLK_PRESCALE_2); right after setting the high-speed clock. Anyway, the application was misbehaving during low-speed clock right after run to main loads #pragem control data.

Any idea how the GEL file can include SYSCTL registers missing in the XDC110 x49c simulators?

Hareesh Janakiraman said:

There are no known issues for this device to work in low-speed either. Also, because of the PLL issue, the POR behavior has been tested fairly extensively. As mentioned before, i

Yet I reported a condition of POR that causes application to malfunction after UniFalsh or CCS debug firmware loads are disconnected, nothing out of the unusual occurs until after a POR. Adding 100µs delay before and after main OSCCLK configures PLL and the low-speed clock presets was part of the solution. Why would the application behave any differently after POR than it would by SW reset after loading firmware? Logic tells me the PLL or other has silicon hard landing and has transition issues changing SYSCLK from INTOSC2 into OSCCLK. The application was setting Boolean binary logic flag opposite from the typedef member set to 1 in main.c and completely ignored another bool logic flag in the same struct member links. It's worth some investigating!

Hareesh Janakiraman said:

You can get visibility to all SYSCTL registers using View-->Registers

The SYSCTL registers used to set the OSCCCLK are not where anyone would expect them to be located, per C2000 driverlib HWREG calls. You don't see a problem of listing SYSCTL registers right under CLB then inside CLKCFG, they are located under SysCtrlRegs in other TI MCU classes. Like putting some system control registers under CPU name when they have nothing to do with the CPU registers as all are peripheral control registers. Name conventions in C2000 GEL files are confusing do not have register names that would be expected as elaborated in TRM text. Obviously my bad for expecting consistency between various MCU classes naming conventions.

Example: The RESCAUS register is listed under CPU when it is a SYSCTL register for watchdog reset condition in TM4C listed under registers. Seemingly whoever designed the debug simulator GEL file has never viewed other TI MCU classes. So it's a bit upsetting when trying to get things done, like when you know you put car keys where always do but are not there and they're in your pocket all along .

Hi Hareesh,

It might be prudent to add a #pragma into OSCCLK driver to stop compiler global optimization level from modifying clock registers. Below current register configuration, suspicious the out divider set 1 when 2 was input into the divider macro ( SYSCTL_SYSDIV(2) ). There is also 3 SysCtlDelay() that could be changed by global optimization level 3? >>> Allow the LDO voltage regulator to stabilize prior switch to high-speed clock source, ASM delay code rings a bell. 

//
// ~200 PLLSYSCLK delay to allow voltage regulator to stabilize
// prior to increasing entire system clock frequency.
//
SysCtl_delay(40U);

//
// Set the divider to user value
//
EALLOW;
HWREGH(CLKCFG_BASE + SYSCTL_O_SYSCLKDIVSEL) =
(HWREGH(CLKCFG_BASE + SYSCTL_O_SYSCLKDIVSEL) &
~SYSCTL_SYSCLKDIVSEL_PLLSYSCLKDIV_M) | divSel;
EDIS;

#pragma FUNCTION_OPTIONS (SysCtl_setClock, "--opt_level=0 --opt_for_speed=1")
bool
SysCtl_setClock(uint32_t config)
{

Hi,

Regarding the value of PLLSYSCLKDIV in register view, the input values for dividers can be 1 or even values upto 126.

We are storing the /2 of the input divider value in the register.

As per the TRM, when the divider value is 2, PLLSYSCLKDIV holds the value 000001.

Thanks

Aswin

HI,

So the resulting PLL speed is 10x20MHz or (PLL=200Mhz/2) and PLL XCLKOUTDIV (0x3)  000011=/8 results in 12.5MHz SYSCLK speed? I was under the impression SYSCLK speed was 100MHz. Perhaps could also explain random OVFLO issues from SCIRX FIFO even from few as 4 words.

Interestingly PLL XCLKOUTDIV on reset (/8) would produce a 12.5MHz SYSCLK? So 12.5MHz SYSCLK is the (SW reset) application speed after firmware loads? And SYSCLK of 12.5MHz is POR speed after the application asserts the clock configuration code? Some logical deduction has to explain the difference between POR and SW reset events making the application behave differently in either clock mode. Seemingly 100MHz SYSCLK results in better MCU application performance with fewer issues. 

Hi Aswin,

Aswin P said:

On reset, PLL is not active and it will use 10MHz OSC2.

Right but INTOS2 feeds the PLL until INTOSC1 is powered when XTAL is detected? The TM4C SysCtlClockFreqSet() auto switches 10Mhz internal oscillator and feeds the PLL for 120Mhz SYSCLK if external XTAL is present after any reset condition. 

Yet the x49c application behaves differently after firmware load and hard reset via INT0S2 than from PLL/2 when SysCtl_setClock() executes. The XCLKOUT will tell me if the SYSCLK is running 100Mhz or some other speed?

BTW: 

Seems I past commented GPIO 18 as configured in hal.c. So it would not be used as GPIO, should not causes X2 input to fail - right?

// GPIO18->Reserve (N/A for GPIO)
//GPIO_setMasterCore(18, GPIO_CORE_CPU1);
//GPIO_setPinConfig(//GPIO_18_XCLKOUT); 
//GPIO_setDirectionMode(18, GPIO_DIR_MODE_IN);
//GPIO_setPadConfig(18, GPIO_PIN_TYPE_STD);