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.

TMS570LS1227: SCI loopback modes

Part Number: TMS570LS1227

I am using the SCI port for  a RS422 serial port with an external interface component.  SCIRX(PINW3) and SCITX(PINN2).   While performing the loopback test the data on the RX pin affects the pass/fall outcome on the test, even though the manual states the that the loopback connection is made internal to the uC.  Why is this?

  • Hello Bill,

    Loopback can be configured as either analog-loopback (loopback through the pin-level input/output buffers) or digital loopback (internal to the SCI module).

    During analog-loopback testing, it should be ensured that none of the SCI pins are driven by any other device connected to them. Otherwise, the testing will fail and may damage the device.

  • Can you please  point me to the register where it is configured for there specific I/O pins.

    I could not find for the

  • SPRU515C:

    30.7.22 Input/Output Error Enable (IODFTCTRL) Register

  • I am writing 500HEX to this register  which is just a write back to the default value.  It should be digital loopback which should ignore data on  the SCIRX.

    Why does data on the SCIRX affect loopback?

  • Hello QJ Wang,

    I was able to duplicate this issue on a TMDX570LS12HDK Development Kit using the Hercules Safety MCU Demos v4.0.0 software. The attached file contains the source files mentioned below and a picture of the CCS property pages.  Can you explain what is happening and how to fix the issue.

    Thanks!

    Rick

    Setup:

    1)      To eliminate as much of our software and hardware from the failure scenario as possible, we utilized a TI TMDX570LS12HDK Development Kit and the Hercules Safety MCU Demos v4.0.0 software as a test platform.

    2)      The TI demo software was compiled using CCS Version: 6.1.2.00015 and setup as follows:

    3)      Issues with macros in the pinmux.c file were resolved and the code compiled successfully. The new pinmux.c file is attached.

    4)      The code was loaded onto the Development Kit and we confirmed the demos ran as expected.

    Failure Duplication:

    1)      Our loopback test was then added to the sci.c file and code to invoke the loopback test was added to sys_main.c. Both files are attached.

    2)      The invocation code simply runs the test repeatedly, using the on board LEDs to indicate test pass/fail.

    3)      We used connector J11 pin 44 to access Pin W3 on the TMS570LS1227.

    4)      With nothing connecte4d to J11 Pin 44 the tests run repeatedly without failure.

    5)      As soon as J11 Pin 44 is connected to ground via a 5k resistor the test fails.

    Analysis:

    1)      Using the debugger we confirmed that the ODFTCTRL register was set to 0x00000500, indicating the SCI was using digital loopback mode

    2)      The observed failure was reception of wrong data. The first byte value transmitted is 0x00. The received value was 0x01.

    3)      The debugger was used to force the test to continue rather than exit on failure. It was observed that all other bytes were received correctly.

    4)      The failure scenario is repeatable.https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/312/1754.TMS570LS1227_2D00_Loopback_2D00_Failure.7z

     

  • Hello,

    I remember I posted my test case couple days ago. It was not posted successfully.

    Attached is my test case for three loopback modes: internal, digital, and analog.

    57804.sys_main.c

  • BTW, there is no change to sci.c. For analog loopback testing, you don't need to connect TX and RX which are connected internally.

  • 1) I did not change any existing code in sci.c, I just added my loopback test. I now moved my test to sys_main.c and restored sci.c to the TI demo version .

    2) I saw that you were checking the IDLE flag. I added this check to my code and this fixed one issue I was seeing where the first transmit failed..

    3) I still see corrupt data however. It doesn't happen every time the test is run but it appears to always be the first byte of the test. I modified your code5811.sys_main.c to run continuously and it fails within 10 seconds. The attached file shows the modifications I made to your code. It looks like you are using a different code base that I have so you will also see some changes I had to make to compile.

  • Hello Rick,

    I will take a look tomorrow.

  • Hello Rick,

    To receive SCI data using polling mode, the RXRDY bit in FLR register should be used to check if the data is ready to read. I noticed that I commended out the RXRDY checking instruction and used a delay instead.  

    This is my new code which should solve your issue:

    int main(void)
    {
    /* USER CODE BEGIN (3) */
    unsigned int Task_Number, i, err=0;

    for (i=0; i<len; i++)
    rxdata[i] = 0;

    _enable_interrupt_();
    sciInit(); /* initialize sci/sci-lin */

    //disable RX interrupt, to use polling mode to receive SCI RX data
    UART->SETINT = 0x00000000;

    Task_Number = 3;
    switch(Task_Number)
    {
    case 1:
    UART->GCR1 &= 0xFFFEFFFF;
    UART->GCR1 |= (0x1 << 16); //internal loopback (inside SCI module)
    break;
    case 2:
    sciEnableLoopback(UART, Digital_Lbk); //digital loopback
    break;
    case 3:
    sciEnableLoopback(sciREG, Analog_Lbk); //analog loopback
    break;
    default:
    break;
    }

    for (i=0; i<len; i++)
    {
    while ((UART->FLR & 0x4) == 4); /* wait until busy */
    while ((UART->FLR & (uint32)SCI_TX_INT) == 0U);
    UART->TD = text[i];

    while ((UART->FLR & (uint32)SCI_RX_INT) == 0U);
    rxdata[i] = (UART->RD & 0x000000FFU);
    };

    for(i=0; i<len; i++){
    if(rxdata[i] != text[i])
    err++;
    }
    /* USER CODE END */

    return 0;
    }