• Resolved

MOSC UART Baudrate

Guru 41375 points

Replies: 10

Views: 247

Part Number: EK-TM4C1294XL

How can unlocking the DAP fix the MOSC clocking into UART block? After POR - launch pad Prints out MOSC 120Mhz, PLL 480 via questionable Tivaware calls below. Removing Pref-flight MOSC checks, the DAP locked MCU and required an unlock device each time mentioned procedure was repeated. The result of unlocking DAP mysteriously fixed UART baud rate clock or PLL frequency, take a pick. Seemingly many posts questioning the PLL frequency has not been corrected for all peripherals, even the ADC sample clock is highly suspect. The simple SysCtrlVCOGet() does not detect partially lock PLL state and clock phasing obviously occurs that effects Stable peripheral operation. Perhaps VCOGet()  should check PLL frequency between two points in time rather than 1 quick test reporting GO dog GO.  

Obviously the Tivaware MOSC/PLL frequency Get reports what you want to see rather than the true PLL state. If the PLL phases in and out of lock state the UART buad rate clock would be effected in the way previously reported, failure of  UART_FR_RXFE, UART_INT_RT flags timing with an external asynchronous device attempting to transfer 32 bytes of data into 16x8 bit FIFO.  

   MOSC Preflight checks shown below prior to SysCtrlClockFreqSet() must  exist or MCU halts and locks the DAP.  Review of SysCtrlClockFrqSet() discovers no such HWREG preflight checks of MOSC being asserted. Datasheet initialization procedure for enabling the MOSC block includes preflight checks below. Even with preflight checks the PLL was obviously not fully engaged in a locked frequency state and direcly impacted the UART phasing of the Baudrate clock frequency. 

  • Please use the TivaWare functions when configuring the oscillator and PLL. Your direct register writes are likely the source of your issues.

    Best Regards,
    Bob Crosby

  • Guru 41375 points

    In reply to Bob Crosby:

    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. 

  • In reply to BP101:

    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.

    Best Regards,
    Bob Crosby

  • Guru 41375 points

    In reply to Bob Crosby:

    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.

  • Guru 41375 points

    In reply to BP101:

    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);
       
  • Guru 41375 points

    In reply to BP101:

    I see the main difference is SysCtlClockFreqSet() clears the NOXTAL, PWRDN, OSCRNG bits in one step. Stellaris boot loader first sets the OSCRNG bit and doesn't clear the NOXTAL bit at all or until the PWRDN interrupt bit was first reset.

    Tivaware v21171 SysctlClockFreqSet() fails to wait for the PWRDWN interrupt to confirm MOSC did indeed power up.

    SysCtrlClockFreqSet():

            //
            // Clear MOSC power down, high oscillator range setting, and no crystal
            // present setting.
            //
            ui32MOSCCTL = HWREG(SYSCTL_MOSCCTL) &
                          ~(SYSCTL_MOSCCTL_OSCRNG | SYSCTL_MOSCCTL_PWRDN |
                            SYSCTL_MOSCCTL_NOXTAL);

  • Guru 41375 points

    In reply to Bob Crosby:

    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.    

  • Guru 41375 points

    In reply to BP101:

    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);
            }

  • Guru 41375 points

    In reply to BP101:

    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);
    }

  • In reply to BP101:

    Make sure you use the latest version of TivaWare for this function (currently 2.1.4.178). And for critical applications make sure you check the return value to be sure the PLL locked correctly.

    Best Regards,
    Bob Crosby