• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 82 subscribers
  • Views 1124 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

TMS320F280049C: SCI TX / RS-485 Transceiver Issue

Wesley C
Intellectual 925 points
Part Number: TMS320F280049C
Other Parts Discussed in Thread: C2000WARE,

Hi all,

I'm having a SCI TX issue with a custom board that includes an RS-485 Transceiver set for half-duplex communication.

The SCI is set to use FIFOs on both TX and RX. The code that I have works on the TMS320F280049C Evaluation board with a RS-485 transceiver eval board connected. I based my code off of the echoback examples in the C2000Ware library. I made the code such that a carriage return character will cause the echoback to occur.

When I port the code to our custom board, I'm seeing the transmit issue. The data is being received as expected and getting placed into the FIFO by the code, but the data isn't being transmitted as expected. One key indicator is that I'm seeing every 6th character in my PuTTY window instead of the full message.

Ex: 'abcdefghijklmnopqrstuvwxz\r' comes back as 'ekqw\r'

Note, on my eval board I'm seeing all the characters come back, thus my conundrum. The main differences between the two boards are the oscillator frequency and pinout.

The pinout is correct for each. The oscillator has been initialized by setting different parameters for the InitSysPll call (from F28004x_sysctrl.c). So I'm a bit at a loss.

Any help would be appreciated.

Thanks!

-Wes

  • 0
    Intellectual 925 points
    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.
  • 0 in reply to Wesley C
    TI__Mastermind 32995 points
    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
  • 0 in reply to Sal Pezzino
    Intellectual 925 points

    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++;
    }

  • 0 in reply to Wesley C
    Intellectual 925 points
    Note, I use the 'RS485' and 'CUSTOM' as predefined symbols in my project.
  • 0 in reply to Wesley C
    TI__Mastermind 32995 points
    Wesley,

    Apparently there is something wrong with your board set-up. If you can get the software working on the eval board or controlCARD, then the software is functional. There must be something wrong with your TX connection.

    Scope the TX connection to try to debug this. See what is coming out of the TX pin and at what frequency.

    sal
  • 0 in reply to Sal Pezzino
    Intellectual 925 points

    Thanks Sal,

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

  • 0 in reply to Sal Pezzino
    Intellectual 925 points
    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
  • 0 in reply to Wesley C
    TI__Mastermind 32995 points
    Wesley,

    Glad you have narrowed it down.

    sal