MOSC UART Baudrate

HI bob,

Seems you missed the entire point of post was just as you have stated, best practice of Tivaware call alone causes the DAP to lock the JTAG port out. Only by including the missing MOSC checks Tivaware omits from v121171 and v214178 does MOSC properly power up without locking the DAP. Each time the DAP was locked by removing HWREG calls the MCU must be once again unlocked.

Review of v214178 reveals there is no PIOSC run time check prior to SYSCTL_OSC_MAIN being passed into SysCtlClockFreqSet(). It assumes PIOSC is the POR default for System clock source even though MOSC has power and provides frequency into the MCU. As a result PIOSC is present prior to clock gating being enabled into peripherals, or is it perhaps bypassing the gating control logic after POR? 

Point of post was to point out the VCO frequency check Get is not detecting a possible VCO phasing condition assumed to be a PLL lock state issue. Again even though MOSC had fully powered up via PUP wait loop the PLL was seemingly not fully locked to 480MHz after Tivaware SysCtlClockFreqSet() configured PLL states and run time application seemed mostly unaffected. Apparently some part of DAP control is why the UART was choking on 32 bytes after 16 bytes were buffered from reads of the FIFO. After device unlock the UART started to work correctly thereafter and every time fully buffered 32 bytes each and every time it was command to do so. 

I don't believe that is the case as so many people are successfully using the TivaWare functions to configure the PLL. Please provide a test case and I will look at your claim.

There are multiple clock sources for use in the microcontroller. The Run and Sleep Mode Configuration Register (RSCLKCFG) can be used to configure the required clock source for the device after Power-On Reset, as well as the system clock divisor encodings. The available clock sources are as follows:

■ Precision Internal Oscillator (PIOSC). The precision internal oscillator is an on-chip clock source that the microcontroller uses during and following POR. It is the clock source in effect at the start of reset vector fetch and the start of code application execution. It does not require the use of any external components and provides a clock that is 16 MHz ±FPIOSC across temperature (see Table 27-19 on page 1835). The PIOSC allows for a reduced system cost in applications that require an accurate enough clock source. If the main oscillator is required, software must enable the main oscillator following reset and allow the main oscillator to stabilize before changing the clock reference. If the Hibernation Module clock source is a 32.768-kHz oscillator, the precision internal oscillator can be trimmed by software based on a reference clock for increased accuracy. Regardless of whether or not the PIOSC is the source for the system clock, the PIOSC can be configured to be an alternate clock source for some of the peripherals. See the section called “Peripheral Clock Sources” on page 234 for more information on peripherals that can use the PIOSC as an alternate clock.

This next odd statement (Blue) seems to counter the purpose of SysCtlClockFreqSet() when 25Mhz is the MOSC. 

■ Main Oscillator (MOSC). The main oscillator provides a frequency-accurate clock source by one of two means: an external single-ended clock source is connected to the OSC0 input pin, or an external crystal is connected across the OSC0 input and OSC1 output pins. If the PLL is being used, the crystal value can be any frequency between 5 MHz to 25 MHz (inclusive). Refer to Table 5-7 on page 238 for recommended crystal values and PLL register programming. If the PLL is not being used, the crystal may be any one of the supported frequencies between 4 MHz to 25 MHz. The single-ended clock source range is from DC through the specified speed of the microcontroller.

5.3 Initialization and Configuration
The PLL is configured using direct register writes to the PLLFREQn, MEMTIM0, and PLLSTAT registers. The steps for initializing the system clock from POR to use the PLL from the main oscillator
is as follows:
1. Once POR has completed, the PIOSC is acting as the system clock.
2. Power up the MOSC by clearing the NOXTAL bit in the MOSCCTL register.
3. If single-ended MOSC mode is required, the MOSC is ready to use. If crystal mode is required,
clear the PWRDN bit and wait for the MOSCPUPRIS bit to be set in the Raw Interrupt Status
(RIS), indicating MOSC crystal mode is ready.
4. Set the OSCSRC field to 0x3 in the RSCLKCFG register at offset 0x0B0.
5. If the application also requires the MOSC to be the deep-sleep clock source, then program the
DSOSCSRC field in the DSCLKCFG register to 0x3.
6. Write the PLLFREQ0 and PLLFREQ1 registers with the values of Q, N, MINT, and MFRAC to
the configure the desired VCO frequency setting.
7. Write the MEMTIM0 register to correspond to the new system clock setting.
8. Wait for the PLLSTAT register to indicate the PLL has reached lock at the new operating point
(or that a timeout period has passed and lock has failed, in which case an error condition exists
and this sequence is abandoned and error processing is initiated).
9. Write the RSCLKCFG register's PSYSDIV value, set the USEPLL bit to enabled, and MEMTIMU
bit.

Obviously the PLL is not always reaching full lock state in this Launch pad. SysCtlClockFreqSet() is not double checking for PLL lock state between 2 points in time or some other odd issue between PIOSC and DAP control existed.

I was simply reporting phasing of unknown and unstable VCO was cleared after an unlock of DAP. Yet removing the MOSC warm up code HWREG calls reproduces the same DAP lock failure each time. That seemingly points to PISOC clock is not ready directly after POR and somehow locks DAP forcing the user to assert the unlock procedure.

Oddly TM4C1294KCPD of custom PCB without HIB module code or 32Khz xtal required the MOSC HWREG warm up directives but the POISC switch MOSC to System clock could be removed but not on this TM4C1249NCPDTi3 launch pad that enables the HIB module right after call to SysCtlClockFreqSet().

 	 /* Set the MOSC for High frequency oscillator */
	 HWREG(SYSCTL_MOSCCTL) |= SYSCTL_MOSCCTL_OSCRNG;
	 /* Clear Crystal PWRDWN bit in MOSCTL register*/
	 HWREG(SYSCTL_MOSCCTL) &= ~(SYSCTL_MOSCCTL_PWRDN);
	 /* Wait until the MOSC indicates RIS fully powered up */
	 while(HWREG(SYSCTL_RIS) & ~SYSCTL_INT_MOSC_PUP)
	 {
	 }
	 /* Source OSCSRC[23:20] POR defaults PIOSC. */
	 HWREG(SYSCTL_RSCLKCFG) |= SYSCTL_RSCLKCFG_OSCSRC_MOSC;

	 /* MPU uses MOSC driven PLL 480mHz/4 produce 120 MHz SYSCLK:
	    Y1 = 25mHz XTAL HIGHFREQ. */
	 g_ui32SysClock = MAP_SysCtlClockFreqSet((SYSCTL_XTAL_25MHZ |
	                                          SYSCTL_OSC_MAIN | SYSCTL_USE_PLL |
	                                            SYSCTL_CFG_VCO_480), 120000000);

	// Delay a second to allow SYSCLK/PLL to stabilize.
	MAP_SysCtlDelay(g_ui32SysClock * 1);
   

Hi Bob,

As the post shows the older version v121171 SysCtrlClokcFreqSet() was being used. This DAP lock issue was past reported but the reason for it was unclear. Tivaware v214178 adds the MOSC powered up wait for interrupt, missing in v121171.

The preflight patches were required or DAP would lock the device if not present. LMFflash would no longer work to write until first unlocking device. Adding in the delay from SysCtrlClockFreqSet() (v214178) allowed removal of pre-flight code above. So far so good.

I'm unclear as to why TI engineers would not simply add same delay into v121171 when it was discovered missing after I reported MOSC lock issue few years ago to this forum. 

So we should be able to read the manifest Tivaware v214178 and note SysCtrlClockFreqSet() was fixed for POR lockups.    

As I figured slipped the wait patch in under the radar:

Software Name: Tiva Peripheral Driver Library
Version: 2.1.4.178
License Type: BSD-3-Clause
Delivered As: Source
Modified by TI: N/A
Location: ./driverlib
Obtained From: TI

        //
        // Increase the drive strength for MOSC of 10 MHz and above.
        //
        if(i32XtalIdx >= (SysCtlXtalCfgToIndex(SYSCTL_XTAL_10MHZ) -
                          (SysCtlXtalCfgToIndex(SYSCTL_XTAL_5MHZ))))
        {
            ui32MOSCCTL |= SYSCTL_MOSCCTL_OSCRNG;
        }

        HWREG(SYSCTL_MOSCCTL) = ui32MOSCCTL;

        //
        // Timeout using the legacy delay value.
        //
        ui32Delay = 524288;

        while((HWREG(SYSCTL_RIS) & SYSCTL_RIS_MOSCPUPRIS) == 0)
        {
            ui32Delay--;

            if(ui32Delay == 0)
            {
                break;
            }
        }

        //
        // If the main oscillator failed to start up then do not switch to
        // it and return.
        //
        if(ui32Delay == 0)
        {
            return(0);
        }

Well the last part of delay code (return(0)) seems odd, as the intended objective was for MOSC to run via XTAL and not degrade back into PIOSC. That would be disastrous act in high voltage PWM inverter drives so.....

while(g_ui32SysClock == 0)
{
     /* MPU uses MOSC driven PLL 480mHz/4 produce 120 MHz SYSCLK:
      Y1 = 25mHz XTAL HIGHFREQ. */
     g_ui32SysClock = MAP_SysCtlClockFreqSet((SYSCTL_XTAL_25MHZ |
	                                      SYSCTL_OSC_MAIN | SYSCTL_USE_PLL |
	                                       SYSCTL_CFG_VCO_480), 120000000);
}