TMS320F28376S: Baud rate is always half what is expected.

Tool/software:

Hi, 

We followed the example in the driverlib folder to set up a UART receiver on the SCIC pin to operate at 5MBaud. 

After receiving loads of framing errors, we set the same configuration on the TX pin and used a logic analyser which showed us the actual Baud rate was 2.5MBaud. 

// initSCIAFIFO - Configure SCIC FIFO
void initSCICFIFO()
{
    // Baud rate setting
    SCI_setBaud(SCIC_BASE, 200000000, 5000000);
    SCI_setBaud(SCIA_BASE, 200000000, 5000000);

    // 8 char bits, 1 stop bit, even parity. Baud, SYSCLK, LSPCLK defines...
    SCI_setConfig(SCIC_BASE, 200000000, 5000000, (SCI_CONFIG_WLEN_8 |
                                                        SCI_CONFIG_STOP_ONE |
                                                        SCI_CONFIG_PAR_EVEN));
    SCI_setConfig(SCIA_BASE, 200000000, 5000000, (SCI_CONFIG_WLEN_8 |
                                                        SCI_CONFIG_STOP_ONE |
                                                        SCI_CONFIG_PAR_EVEN));

    SCI_enableModule(SCIC_BASE);
    SCI_disableLoopback(SCIC_BASE);
    SCI_resetChannels(SCIC_BASE);
    SCI_enableFIFO(SCIC_BASE);

    SCI_enableModule(SCIA_BASE);
    SCI_disableLoopback(SCIA_BASE);
    SCI_resetChannels(SCIA_BASE);
    SCI_enableFIFO(SCIA_BASE);

    // RX and TX FIFO Interrupts disabled initially
    SCI_disableInterrupt(SCIC_BASE, SCI_INT_RXFF);
    SCI_disableInterrupt(SCIC_BASE, SCI_INT_RXERR);
    SCI_disableInterrupt(SCIC_BASE, SCI_INT_RXRDY_BRKDT);
    SCI_disableInterrupt(SCIC_BASE, SCI_INT_TXFF);

    SCI_disableInterrupt(SCIA_BASE, SCI_INT_RXFF);
    SCI_disableInterrupt(SCIA_BASE, SCI_INT_RXERR);
    SCI_disableInterrupt(SCIA_BASE, SCI_INT_RXRDY_BRKDT);
    SCI_disableInterrupt(SCIA_BASE, SCI_INT_TXFF);

    // Generate interrupt on receipt of three characters (8-bits each, 12-bits curr/volts).
    SCI_setFIFOInterruptLevel(SCIC_BASE, SCI_FIFO_TX3, SCI_FIFO_RX3);
    SCI_performSoftwareReset(SCIC_BASE);
    SCI_setFIFOInterruptLevel(SCIA_BASE, SCI_FIFO_TX1, SCI_FIFO_RX3);
    SCI_performSoftwareReset(SCIA_BASE);

    SCI_resetTxFIFO(SCIC_BASE);
    SCI_resetRxFIFO(SCIC_BASE);
    SCI_resetTxFIFO(SCIA_BASE);
    SCI_resetRxFIFO(SCIA_BASE);

    Interrupt_clearACKGroup(INTERRUPT_ACK_GROUP7);
    Interrupt_clearACKGroup(INTERRUPT_ACK_GROUP8);
    Interrupt_clearACKGroup(INTERRUPT_ACK_GROUP9);
}

Following this, we made the assumption something was wrong with our clock - no matter what we set the Baud rate to, it would always be half this value. 

We called the getClock functions for both SYSCLK and LSPCLK which both returned 200MHz. After scrolling through the API guide for the SysCtl, the only thing I could think of changing was the PLL clock divider. We inserted the following code after the initial setting up of the device, as such:

// Initialize device clock and peripherals
    Device_init();


    SysCtl_setLowSpeedClock(SYSCTL_LSPCLK_PRESCALE_1);
    
    // Set PLL to max frequency, argument zero = DIV by 1.
    SysCtl_setPLLSysClk(0);

    lowClockFreq = SysCtl_getLowSpeedClock(DEVICE_OSCSRC_FREQ);
    sysClockFreq = SysCtl_getClock(DEVICE_OSCSRC_FREQ);
    properClockFreq = SysCtl_getClock(SYSCTL_DEFAULT_OSC);

We re-ran the tests and found that the Baud rate is now 5MBaud, and we no longer get framing errors.

We are using the DAC to visualise the received UART data after conversion, but both DACA and DACB are constantly stuck at 3.3V. 

The getClock functions now return twice the usual value, what did read 200MHz reads 400MHz, for example. 

What has happened here? Why was my Baud rate 2.5MBaud when it should be 5Mbaud, despite the function calls showing they were both 200MHz?

Can accidentally setting the clock to 400MHz actually cause the clock to operate at that frequency, and could that damage the device causing the DAC to be 3.3V constantly?

The value of "BRR" in the register was "4", which if using a 200MHz LSPCLK, should give exactly 5MBaud.

Can someone please provide some clarification regarding what is going on here? The SCI clock doesn't even seem to be derived from PLLSYSCLK, and the function calls both showing 200MHz for the LSPCLK and SYSCLK makes me wonder exactly where this extra division by 2 may be coming from, and whether I have fixed the issue.

Best regards,

JMH