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.

Receiving data through the SCI port in TMS320F28335

Hello,

I am using the scia_loopback example in control suite, and have made a small addition to the code as follows

for(;;)
{
**while(SciaRegs.SCIRXST.bit.RXRDY != 1){}
**while(SendChar <= 0x00FF)
**{

Breakpointscia_xmit(SendChar);
Breakpoint**while(SciaRegs.SCIFFRX.bit.RXFFST !=1) { } // wait for RRDY/RXFFST =1 for 1 data available in FIFO

// Check received character
Breakpoint ReceivedChar = SciaRegs.SCIRXBUF.all;
if(ReceivedChar != SendChar) error();

// Move to the next character and repeat the test
SendChar++;
// Limit the character to 8-bits
SendChar &= 0x00FF;
LoopCount++;
**}

**SendChar=0;
}

The lines beginning with a ** indicate insertions on my part.

What I expect it to do is, instead of sending the same sequence of words repeatedly, to wait for a symbol to be transmitted from my PC terminal. which, I believed will be flagged by the SCIFFRXST going from 0 to 1. However, when I send a symbol from my terminal application, I get an indicator in hardware on the PC side that the bit has been sent, but the DSP module does not respond.

I presume that the SCI module is capable of communication in either direction; why else would it be programmed otherwise when loopback is a desired function? There must be something I have not Can someone please point me in the right direction on this?

Thanks for reading,

Tim

  • Hi Tim,

    Please check whether the above SCI code satisfies or obeys these steps:

    Rx

    Tx

    In the above code what is the initial value of SendChar.  Also, try using an if loop instead of while for SendChar conditioning.

    Regards,

    Gautam

  • Hi Tim,

    Hint: Pls try to check for hardware delays (needed) sometimes before flags are available to be read in software. 

  • Thanks for the pointers, Gautam,

    SendChar is initiallized to zero, as in the scia_loopback sample project.

    The code included in my original post hangs at the breakpoint, indicating the the RXRDY register bit never goes high.

    I then tried to debug the code in the original scia_loopback project I observed the SCIRXST register, where the rxrdy bit is located does not seem to change when I run the code in my original post. I observed the registers at before at the red breakpoints. The receiver must be working properly. Otherwise the debug process would have thrown an error.

    I noticed that, while SCIRXST did not change, and remained at 0, the SCIFFRX register changed from 8207 to 8463. What I think is strange about this is that the RXFFIE (Receiver FIFO interrupt enable) bit changes state between the two points. It seems that this should be a write only bit, and there is no reason obvious to me for which it would automatically change. If anybody can postulate why this is happening, I would also appreciate that.

    Thanks again,

    Tim

  • Tim,

    Please forgive me if this is a stupid question, but you did turn off Loopback Mode, yes?

    Does a simple DSP program, where you send out a character, say, once a second, work correctly?

    Regards,

    Bill

  • Bill,

    Thanks for the suggestion. I did not turn off Loopback because I had assumed that all communication layers would be tested when it was enabled, and that it would not interfere with the registers. It appears that I was wrong.

    When I disabled loopback mode, the RXRDY does not change, but the program proceeds. Moreover, the RXFFST bit changes notably, which may suffice as a flag.

    At this stage in the development of my application, I want to write a program that waits for any data to be sent over the serial link, and to use the receipt as a flag to sequence through sending a range of values. When the range has been sent, the chip would revert to its original state and wait for more arbitrary data from the PC to do the same thing.

    scia_loopback compiled and worked fine for me. I was able to read out repeated sequences of integers ranging from 0 to 255.

    Thanks again for your suggestion. I will let you know how using RXFFST, instead of RXRDY as a flag goes.

    Tim