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.

TMS320F28377S: Unable to receive data on SCIA

Part Number: TMS320F28377S
Other Parts Discussed in Thread: C2000WARE

I am using SCIA to display data and receive commands.  Right now I'm using TeraTerm to send and receive data, but have also tried PuTTY. 

I am able to send data from the board and display it correctly in the TeraTerm window, but to date I am unable to send data from TeraTerm to the board.  I have confirmed that the signal is getting to the processor via oscilloscope, but SciaRegs.SCIRXST.bit.RXRDY is NOT being set and I have no data. in SciaRegs. 

I have tried this with both my target board (multiple boards) and a TMS320F28377S Launchpad (LAUNCHXL-F28377S). 

UART settings at as follows:

SciaRegs.SCICCR = 0x07     (8 bits data, Idle-line mode, LOOPBK disabled, parity disabled, one stop bit)

SciaRegs.SCICTL1 = 0x23  (RXENA, TXENA set, sleep disabled, TXWAKE not selected, SWRESET also set after configuration, RXERRINT disabled) 

SciaRegs.SCICTL2 = 0x00C0  (TXINT disabled, RXBKINT disabled, TXEMPTY and TXRDY are both 1)

SciaRegs.SCIHBAUD = 0

SciaRegs.SCILBAUD = 0x35 (This should correspond to a 115200 baud rate, with a 50MHz LSPCLK)

The FIFOs are, for now, disabled. 

As I said, I am able to display data but am unable to receive any data.  Do I have the peripheral set correctly, or am I missing something? 

Thank you in advance for any assistance. 

  • Additional settings:
    GpioCtrlRegs.GPCGMUX2.bit.GPIO85 = 1
    GpioCtrlRegs.GPCMUX2.bit.GPIO85 = 1
    GpioCtrlRegs.GPCQSEL2.bit.GPIO85 = 3
  • Hi Andrew,

    Have you tried directly running the SCI echoback example in C2000ware? This example will take characters from the host PC and send them right back to the PC. Even if you don't run it, you can compare the settings vs. your configurations.

    This is not through the FTDI virtual com port, correct? If it is not virtual, what RS-232 transceiver are you using? How are you powering this?
  • I am running this through an FTDI virtual comm port. On my target board I'm using an FTX230X. The FTX230X signals are isolated via an ISO7221.

    I have observed identical results using the 28377S Launchpad, which has the FT2232H on board.

    I'll check out the SCI echoback, thanks.
  • Hi Andrew,

    You posted GPIO configs for GPIO85 (SCIRX). Are you also configuring GPIO84 (SCITX)?
  • Devin,

    thanks for your help thus far. 

    GPIO84 settings:

    GpioCtrlRegs.GPCGMUX2.bit.GPIO84 = 1

    GpioCtrlRegs.GPCMUX2.bit.GPIO84 = 1

    GpioCtrlRegs.GPCQSEL2.bit.GPIO84 = 3

    In addition:

    GpioCtrlRegs.GPCDIR.bit.GPIO84 = 1

    GpioCtrlRegs.GPCDIR.bit.GPIO85 = 0

  • Also, please note that I m able to transmit data to both TeraTerm and PuTTY, on both my target board AND the 28377 Launchpad.
  • Hi Andrew,

    Gpio Mux settings seem correct. You might just double check the register settings in the expressions window to ensure the settings are making it into the registers (if not, a common cause would be a missing 'EALLOW').

    You can also do a wiggle test to confirm pin hookup by using the expression window to temporarily set the GPIO mux settings to 0,0 (GPIO) and the gpio direction to 1 (output) and then use the GPIO data registers to toggle the pin back and forth. I doubt this is the issue since you see this behavior on both boards.

    Your baud rate settings also seem correct. The SCI module, FTDI chip, and PC should all be able to support this, but you might try a slower baud until you get things working. You are clocking off of an external XTAL or oscillator? Have you verified that the SYSCLK is the expected frequency by enabling XCLKOUT? Have you confirmed the observed baud rate on the scope capture?

    For the other SCI specific settings, there are quite a few ways you could set things up. Have you tried the TI provided example code to see if that works for you?
  • I have had some success, and can get sci_ex3_echoback to run on both the Launchpad and my target board.  I suspect a register setting somewhere, perhaps the FIFOs because echoback sets them and I don't. 

    The data to and from TeraTerm (or PuTTY) is corrupted and not the ASCII data I'm entering, so maybe it is a baud issue, which I'll check.

    Thanks!!

  • I've made some good progress.  I am able to run sci_ex3_echoback on my target board successfully.  This demonstrates that my target board, my FTDI UART interface, and TeraTerm are not the problem.  I have also confirmed the baud rate.  SCIA and GPIO register settings for both sci_ex3_echoback and my application have been confirmed to be identical, with the exception of SCIFFTX, which I'm currently not using (see below). 

    is there something about using the TXFIFO that can explain this behavior, maybe using the FIFO clears a flag or something?  I can't see anything in the echoback project that does this, although I can't examine the SCI_writeCharArray function as it's embedded in a library.

    sci_ex3_echoback register settings:

      

    application register settings:

  • apparently my register settings didn't come through. From my application code:

    The only difference is in SCIFFTX, where echoback sets it for 0xE000 and I set it at 0xA000

    /***** GPIO Configuration ***********************************************/
    GpioCtrlRegs.GPCLOCK.bit.GPIO84 = 0;
    GpioCtrlRegs.GPCLOCK.bit.GPIO85 = 0;

    GpioCtrlRegs.GPCCR.bit.GPIO84 = 0;
    GpioCtrlRegs.GPCCR.bit.GPIO85 = 0;

    GpioCtrlRegs.GPCCSEL3.bit.GPIO85 = 0;
    GpioCtrlRegs.GPCGMUX2.bit.GPIO85 = 0x0001;
    GpioCtrlRegs.GPCMUX2.bit.GPIO85 = 0x0001;
    GpioCtrlRegs.GPCDIR.bit.GPIO85 = 0;
    GpioCtrlRegs.GPCPUD.bit.GPIO85 = 1;
    GpioCtrlRegs.GPCQSEL2.bit.GPIO85 = 0x003;

    GpioCtrlRegs.GPCCSEL3.bit.GPIO84 = 0;
    GpioCtrlRegs.GPCGMUX2.bit.GPIO84 = 0x0001;
    GpioCtrlRegs.GPCMUX2.bit.GPIO84 = 0x0001;
    GpioCtrlRegs.GPCDIR.bit.GPIO84 = 1;
    GpioCtrlRegs.GPCPUD.bit.GPIO84 = 1;
    GpioCtrlRegs.GPCODR.bit.GPIO84 = 0;
    GpioCtrlRegs.GPCQSEL2.bit.GPIO84 = 0x003;

    GpioCtrlRegs.GPCCR.bit.GPIO84 = 1;
    GpioCtrlRegs.GPCCR.bit.GPIO85 = 1;

    GpioCtrlRegs.GPCLOCK.bit.GPIO84 = 1;
    GpioCtrlRegs.GPCLOCK.bit.GPIO85 = 1;
    /**************************************************************************/

    /***** SCIA Configuration ***********************************************/
    SciaRegs.SCICTL1.bit.SWRESET = 0; /* Put the SCI in reset mode */
    SciaRegs.SCICTL1.bit.SWRESET = 1; /* to clear any errors */

    SciaRegs.SCICCR.bit.SCICHAR = 7; /* 8 data bits */
    SciaRegs.SCICCR.bit.ADDRIDLE_MODE = 0; /* Idle-line selected */
    SciaRegs.SCICCR.bit.LOOPBKENA = 0; /* Loopback disabled */
    SciaRegs.SCICCR.bit.PARITYENA = 0; /* Parity disabled */
    SciaRegs.SCICCR.bit.PARITY = 0; /* Odd parity */
    SciaRegs.SCICCR.bit.STOPBITS = 0; /* One stop bit */

    SciaRegs.SCICTL1.bit.SWRESET = 0; /* Put the SCI in reset mode */
    SciaRegs.SCICTL1.bit.RXENA = 1; /* Enable RX */
    SciaRegs.SCICTL1.bit.TXENA = 1; /* Enable TX */
    SciaRegs.SCICTL1.bit.SLEEP = 0; /* Disable sleep mode */
    SciaRegs.SCICTL1.bit.TXWAKE = 0; /* Disable TXWAKE */

    SciaRegs.SCICTL2.bit.TXINTENA = 0; /* Disable TX interrupt */
    SciaRegs.SCICTL2.bit.RXBKINTENA = 0; /* Disable Rx interrupt */

    SciaRegs.SCIHBAUD.all = ( (BaudVal & 0xFF00)>>8 );
    SciaRegs.SCILBAUD.all = (BaudVal & 0x00FF);
    /**************************************************************************/

    /***** SCIA FIFO Configuration ******************************************/
    SciaRegs.SCIFFTX.bit.SCIRST = 0;
    SciaRegs.SCIFFTX.bit.SCIFFENA = 0;
    SciaRegs.SCIFFTX.bit.TXFIFORESET = 0;
    SciaRegs.SCIFFTX.bit.TXFFINTCLR = 1;
    SciaRegs.SCIFFTX.bit.TXFFIENA = 0;
    SciaRegs.SCIFFTX.bit.TXFFIL = 0;
    SciaRegs.SCIFFTX.bit.TXFIFORESET = 1;
    SciaRegs.SCIFFTX.bit.SCIRST = 1;

    SciaRegs.SCIFFRX.bit.RXFIFORESET = 0;
    SciaRegs.SCIFFRX.bit.RXFFOVRCLR = 1;
    SciaRegs.SCIFFRX.bit.RXFFINTCLR = 1;
    SciaRegs.SCIFFRX.bit.RXFFIENA = 0;
    SciaRegs.SCIFFRX.bit.RXFFIL = 0x001F;
    SciaRegs.SCIFFRX.bit.RXFIFORESET = 1;

    SciaRegs.SCIFFCT.bit.CDC = 0;
    SciaRegs.SCIFFCT.bit.FFTXDLY = 0;
    /**************************************************************************/

    SciaRegs.SCICTL1.bit.SWRESET = 1; /* Release from Reset */
  • Hi Andrew,

    A few options:

    Give the bitfield SCI echoback example a try. This should allow you to observe how the code is doing all the interactions with the underlying SCI registers:
    C:\ti\c2000\C2000Ware_1_00_05_00\device_support\f2837xs\examples\cpu1\sci_echoback

    Can you just use the provided SCI_writeCharArray driverlib function to do your transmission?

    You can dump the SCI register sets in from both code sets. To do this, add &SciaRegs and &ScibRegs to the expressions window. The difference is the size of the module register set. Navigate in the memory explorer to whatever address &SciaRegs resolves to. Then right click on the memory and select 'save to file'. Save a number of words that corresponds to the module size you determined. You can then line up both memory dumps side-by-side in excel to see exactly what bits are set differently.