TMS320F280049C: SCI TX / RS-485 Transceiver Issue

Note, if I use fewer than 6 characters, I often get noise indicators in PuTTY. Also, I sometimes see noise characters after the returned 'ekqw' messages.

Also I have my TX FIFO set up to send on having 1 character in the buffer, so as quickly as characters are placed there.

Do you mean you are using the TXFIFO interrupt?

If you have the same code running properly on one board and improperly on the other, it is difficult to say what the issue is from my side. It would appear the issue is the board or your configuration of the software for each board.

The TXFIFO interrupt will trigger when there is less words in the FIFO than the FFIL (FIFO interrupt level).

I would begin to ensure that your faulty board is receiving all the characters properly first, and then once you ensure it is, figure out why it is not sending them all.

Hope this helps.
sal

Hi Sal,

I agree. The issue is with the board or our configuration of the software. Right now, I am just trying to eliminate one of these potential areas. The easiest would be the software settings.

I don't use the TXFIFO interrupt but do use the TX FIFO buffer. Also, I am using the C2000Ware driverlib functions but with some modifications for our board which has a 10MHz oscillator (versus the control card's 20MHz).

The issue with the board is that it is receiving all of the characters as expected. I see them all in the internal buffer while Debugging. All the characters are there just as I expect them to be, but when we transmit them, the characters do not appear to be coming out correctly on the TX line.

Since I was having problems with my code, I went back and reworked part of the sci_ex1_echoback.c example, but this shows similar issues.

I only changed the device.h and sci_ex1_echoback.c file as follows:

device.h:

//*****************************************************************************
//
// Defines related to clock configuration
//
//*****************************************************************************
//
// 20MHz XTAL on controlCARD. For use with SysCtl_getClock().
//
#ifdef CUSTOM
#define DEVICE_OSCSRC_FREQ          10000000U
#else
#define DEVICE_OSCSRC_FREQ          20000000U
#endif

//
// Define to pass to SysCtl_setClock(). Will configure the clock as follows:
// PLLSYSCLK = 20MHz (XTAL_OSC) * 10 (IMULT) * 1 (FMULT) / 2 (PLLCLK_BY_2)
//
#ifdef CUSTOM
#define DEVICE_SETCLOCK_CFG         (SYSCTL_OSCSRC_XTAL | SYSCTL_IMULT(20) |  \
                                     SYSCTL_FMULT_NONE | SYSCTL_SYSDIV(2) |   \
                                     SYSCTL_PLL_ENABLE)
#else
#define DEVICE_SETCLOCK_CFG         (SYSCTL_OSCSRC_XTAL | SYSCTL_IMULT(10) |  \
                                     SYSCTL_FMULT_NONE | SYSCTL_SYSDIV(2) |   \
                                     SYSCTL_PLL_ENABLE)
#endif

//
// 100MHz SYSCLK frequency based on the above DEVICE_SETCLOCK_CFG. Update the
// code below if a different clock configuration is used!
//
#ifdef CUSTOM
#define DEVICE_SYSCLK_FREQ          ((DEVICE_OSCSRC_FREQ * 20 * 1) / 2)
#else
#define DEVICE_SYSCLK_FREQ          ((DEVICE_OSCSRC_FREQ * 10 * 1) / 2)
#endif

For the sci_ex1_echoback.c, I modified the SCI TX and RX pins from 28 and 29 to other SCI-A allowded pins and added a direction pin. I removed all the *msg writes to make things more streamlined due to having a half-duplex system, and then added my direction pin toggles around the SCI_writeCharBlockingFIFO call. Note the delays are probably unnecessary, but I've been changing them to see if it changes any behaviour. The answer is 'not much.' See below for code snippet.

#ifdef CUSTOM
    GPIO_setMasterCore(25, GPIO_CORE_CPU1);
    GPIO_setPinConfig(GPIO_25_SCIRXDA);
    GPIO_setDirectionMode(25, GPIO_DIR_MODE_IN);
    GPIO_setPadConfig(25, GPIO_PIN_TYPE_STD);
    GPIO_setQualificationMode(25, GPIO_QUAL_ASYNC);
#else
    //
    // GPIO28 is the SCI Rx pin.
    //
    GPIO_setMasterCore(28, GPIO_CORE_CPU1);
    GPIO_setPinConfig(GPIO_28_SCIRXDA);
    GPIO_setDirectionMode(28, GPIO_DIR_MODE_IN);
    GPIO_setPadConfig(28, GPIO_PIN_TYPE_STD);
    GPIO_setQualificationMode(28, GPIO_QUAL_ASYNC);
#endif

#ifdef CUSTOM
    GPIO_setMasterCore(24, GPIO_CORE_CPU1);
    GPIO_setPinConfig(GPIO_24_SCITXDA);
    GPIO_setDirectionMode(24, GPIO_DIR_MODE_OUT);
    GPIO_setPadConfig(24, GPIO_PIN_TYPE_STD);
    GPIO_setQualificationMode(24, GPIO_QUAL_ASYNC);
#else
    //
    // GPIO29 is the SCI Tx pin.
    //
    GPIO_setMasterCore(29, GPIO_CORE_CPU1);
    GPIO_setPinConfig(GPIO_29_SCITXDA);
    GPIO_setDirectionMode(29, GPIO_DIR_MODE_OUT);
    GPIO_setPadConfig(29, GPIO_PIN_TYPE_STD);
    GPIO_setQualificationMode(29, GPIO_QUAL_ASYNC);
#endif

#ifdef RS485
    // Direction pin
    GPIO_setMasterCore(26, GPIO_CORE_CPU1);
    GPIO_setPinConfig(GPIO_26_GPIO26);
    GPIO_setDirectionMode(26, GPIO_DIR_MODE_OUT);
    GPIO_setPadConfig(26, GPIO_PIN_TYPE_STD);
    GPIO_setQualificationMode(26, GPIO_QUAL_ASYNC);
#endif

    //
    // Initialize interrupt controller and vector table.
    //
    Interrupt_initModule();
    Interrupt_initVectorTable();

    //
    // Initialize SCIA and its FIFO.
    //
    SCI_performSoftwareReset(SCIA_BASE);

    //
    // Configure SCIA for echoback.
    //
    SCI_setConfig(SCIA_BASE, DEVICE_LSPCLK_FREQ, 38400, (SCI_CONFIG_WLEN_8 |
                                                        SCI_CONFIG_STOP_ONE |
                                                        SCI_CONFIG_PAR_NONE));
    SCI_resetChannels(SCIA_BASE);
    SCI_resetRxFIFO(SCIA_BASE);
    SCI_resetTxFIFO(SCIA_BASE);
    SCI_clearInterruptStatus(SCIA_BASE, SCI_INT_TXFF | SCI_INT_RXFF);
    SCI_enableFIFO(SCIA_BASE);
    SCI_enableModule(SCIA_BASE);
    SCI_performSoftwareReset(SCIA_BASE);

#ifdef AUTOBAUD
    //
    // Perform an autobaud lock.
    // SCI expects an 'a' or 'A' to lock the baud rate.
    //
    SCI_lockAutobaud(SCIA_BASE);
#endif

#ifndef RS485
    //
    // Send starting message.
    //
    msg = "\r\n\n\nHello World!\0";
    SCI_writeCharArray(SCIA_BASE, (uint16_t*)msg, 17);
    msg = "\r\nYou will enter a character, and the DSP will echo it back!\n\0";
    SCI_writeCharArray(SCIA_BASE, (uint16_t*)msg, 62);
#endif

    for(;;)
    {
#ifndef RS485
        msg = "\r\nEnter a character: \0";
        SCI_writeCharArray(SCIA_BASE, (uint16_t*)msg, 22);
#endif
        //
        // Read a character from the FIFO.
        //
        receivedChar = SCI_readCharBlockingFIFO(SCIA_BASE);

#ifndef RS485
        //
        // Echo back the character.
        //
        msg = "  You sent: \0";
        SCI_writeCharArray(SCIA_BASE, (uint16_t*)msg, 13);
#endif
#ifdef RS485
        GPIO_writePin(26, 1);

        SysCtl_delay(1000);
#endif
        SCI_writeCharBlockingFIFO(SCIA_BASE, receivedChar);
#ifdef RS485

        SysCtl_delay(1000);  //1 micro s

        // Wait for Tx empty!!
        while(SCI_isTransmitterBusy(SCIA_BASE))
        {
            SysCtl_delay(1000);  //1 micro s
        }

        SysCtl_delay(1000);  //1 micro s

        GPIO_writePin(26, 0);

#endif
        //
        // Increment the loop count variable.
        //
        loopCounter++;
    }

Note, I use the 'RS485' and 'CUSTOM' as predefined symbols in my project.

Thanks Sal,

I agree. We'll scope the Tx connection and work our way from there.

Hi Sal,

After pulling some pins and separating the circuit, we found that the board is in fact causing the strange behavior when the processor and transceiver circuits are connected as they appear to work fine when attaching to external evaluation boards for the processor or transceiver. Code-wise the issue is resolved. Our team will have to figure out the board issue.

Thanks for your help.
-Wes