This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TMS320F280039C: Actual SCI baud rate is significantly different from expected baud rate

Part Number: TMS320F280039C
Other Parts Discussed in Thread: C2000WARE

I am working with the SCI modules available on the Launchpad.
I set a particular baud rate, and send data via the SCI-TX pin on the launchpad to view it in a logic analyzer.
I see that the expected baud rate and actual baud rate are significantly different.

For example, say I have set the baud rate to 9600 (SCIHBAUD & SCILBAUD set to 0x5 and 0x15 respectively), SYSCLK is set to 100MHz, LSPCLK is set to SYSCLK/1 making it 100MHz and character length per frame is 8 bits.

The waveform is as shown below: (Header 'S' is shown here)
image.png
The first bit is the start bit (0), followed by 'S' in bit form (01010011) sent from LSB first to MSB last and then comes the stop bit (1). No parity bit is set.

The width of one bit determines the baud rate, seen above as 115us, which when converted to baud rate, becomes 8695, instead of 9601 (9% error). 

When I use this actual baud rate (8695) to convert back to the LSPCLK being used in the SCI module (8695 = (LSPCLK)/(BRR+1)/8, BRR is 1301) LSPCLK comes out as 90.5671MHz, instead of the 100MHz set.

I know that the actual SCI baud rate will not be exactly the same as expected baud rate, but this much error is not expected.
Even the TRM for F28003x states that for LSPCLK at 100MHz, and set baud rate of 9600, the expected baud rate is 9601, with an error of 0.01% as shown below:
image.png
I have checked the same for other baud rates as well, and every one of them has significantly more error than expected.

I am beginning to wonder whether there is something wrong with LSPCLK itself, the source of the CLK used by the SCI module to send data. Unfortunately, I don't see a method to view its waveform in the TRM (there is one method to use GPIO for other clock signals like PLL ones, but not for LSPCLK). 

Let me know what you think of this, because it is becoming difficult to set a proper baud rate when receiving this data elsewhere, like PuTTY, as the difference is significant.

Thanks and regards,
Sumukh.

  • Hi Sumukh,

    Can you verify the sampling rate of your logic analyzer is set to the highest sampling rate to eliminate any issues related to sampling bandwidth. 

    There is an XCLKOUT which you can use to verify clocking frequencies on the device. If you have configured the INTOSC you may experience some degraded performance compared to external crystal, so it would be good to ensure that you are using XTAL for highest accuracy. Are you using our DriverLib for setting the BAUDRATE? It will attempt to assign the closest BAUD rate based on your input and I want to see if this may improve your error. You can reference our C2000WARE SCI examples

    Regards,

    Peter

  • Hi Peter,
    After changing to XTAL, the baud rate is coming up as expected:

    The sampling rate is 4MS/s and baud rate is 9600, so I believe that is fine.

    Is XTAL always recommended for SCI because INTOSC appears to provide degraded clock?
    This should be the general recommendation I suppose, because I don't know whether it was failing because INTOSC was never meant to be used for SCI or INTOSC performance degrades with time and does not work at expected rates over time.

    Thanks
    Sumukh.

  • Hi Sumukh,

    The INTOSC in most cases for SCI should be sufficient especially at 9600 BAUD since it is relatively slow. It also depends on your device revision since older versions may not have had sufficient testing/trimming to maximize the INTOSC performance. If you have an earlier revision board, this might be the reason. It could also be that the code you are leveraging is expecting XTAL (like in the device.h) but if you do not configure it in the main.c then there becomes a conflict

    Regards,

    Peter