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.

TMS320F28075: There is variation in the pulse width of the TX port high/low.

Expert 2680 points
Part Number: TMS320F28075
Other Parts Discussed in Thread: C2000WARE

Tool/software:

Hi All,

Currently, transmission is being performed at a speed of 9600 bps, but there is variation in the pulse width of the TX port high/low (fluctuating in the range of approximately 90 μs to 104 μs).
The error is about 10 μs, ±10%. Is this within the acceptable range according to the specifications?

We also checked for fluctuations in the CPU clock, but no major issues were found, and the cause has not been identified.

Best Regards,

Ito

  • Hi Ito,

    To confirm, your SCI pulse lengths are varying within a single communication transmission, is that correct? What are your LSPCLK and BRR configured to be?

    Best Regards,

    Allison

  • Hi Allison,

    Thank you for your reply.

    your SCI pulse lengths are varying within a single communication transmission, is that correct?

    Yes,

    What are your LSPCLK and BRR configured to be?

    LSPCLK : 120MHz(120000000L)
    BRR : 9600bps(1562) 

    Best Regards,

    Ito

  • Hi Ito,

    LSPCLK and BRR values look good, thanks for clarifying.

    To follow up, error % should be minimized to prevent miscommunication in SCI as this is an asynchronous protocol. If error is significant, this can cause erroneous data. The C2000 SCI uses a 'majority voting' system to determine the values of data bits as described in the TRM:

    Hence, if the error is large enough, the data can be corrupted. A few follow up questions:

    • Can you confirm if this variation occurs within every single transmission?
    • Are you seeing errors in data received on the RX device?
    • Do you also see this occur when running one of our C2000Ware SCI examples and scoping the signal?
    • How are you scoping the signals? Which GPIOs are you looking at?
    • How have you checked the CPU clock (you are using INTOSC?)? Are you scoping XCLKOUT?

    Best Regards,

    Allison

  • Hi Allison,

    Regarding UART communication, it was found that using general-purpose IO instead of the SCI port and
    simulating UART communication with software caused
    a slight delay in the waveform depending on the timing of the interrupt.

    Best Regards,

    Ito