• State
  • Locked Locked
  • Replies 1 reply
  • Subscribers 82 subscribers
  • Views 632 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Linux/TMS320F28377S: SCI SERIAL COMMUNICATION WITH LINUX PC VIA TTY

Neil Josiah
Prodigy 10 points
Part Number: TMS320F28377S

Tool/software: Linux

I am using an  F28377S and have configured it with SCI-A since it is muxed with USB via GPIO 85 AND 84 and i could use the same debugging usb line for transmission . I am using it to receive a 32 bit pattern from a linux pc via tty . The third frame or the third 32 bit buffer on reception gets corrupted.Dunno whether it gets corrupted when it leaves the PC or after reaching the ti board. I m using a simple POSIX serial communication code. All baud rates and channels are correct .I have checked for as much as flags i can. Do i have to configure specifically flags in the ti board and on my linux communication program.Where are the flags mentioned in the SCI example code. Are hardware control and software control sorted out automatically .I keep hearing about a control card between the ti board and pc for such an application.Kindly help me with this or if you could suggest another approach

  • 0
    TI__Guru 60865 points
    Hi Neil,

    From a SCI HW perspective, you can configure the word length, parity type, and number of stop bits. A good debug step would be to capture the serial message from the PC with an oscilloscope or logic analyzer and compare the actual message vs. the HW settings.

    When you capture the message, you can also measure the bit timings and ensure that what is coming from the PC has the expected baud rate. If those are good, you can then also check the F28377S timings. You can measure the input clock on X1, the (divided down) output clock on XCLOCKOUT, and then the actual SCI timings by sending a message from the SCI and measuring the bit timings.

    The SCI does have flags to potentially determine why a message failed. These are parity, overrun, framing, and break detection. You should check these bits after each message to see if there is an error. One thing that could happen is that an error in the second message could leave the SCI in an unexpected state when the 3rd message arrives.