• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Subscribers 31 subscribers
  • Views 1959 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.

TMS570LS3137 SCI2 Loop Back Not Working

Cagil Koroglu
Prodigy 80 points
Other Parts Discussed in Thread: HALCOGEN

Hello,


I was testing the SCI2 module and noticed that the device was not operating as required in loop back mode. Here is the sys_main.c file of a simple program to illustrate the issue:

/* Include Files */

#include "sys_common.h"

/* USER CODE BEGIN (1) */

#include "sci.h"
#include "sys_dma.h"

/* USER CODE END */

/* USER CODE BEGIN (2) */
uint32 i = 0U;
/* USER CODE END */

void main(void)
{
/* USER CODE BEGIN (3) */

    sciInit();
    scilinREG->GCR1 |= (uint32)((uint32)1 << 16);    /* Loop back enable */
    while(!sciIsTxReady(scilinREG));
    scilinREG->TD = (uint32)'a';

    while(!sciIsRxReady(scilinREG));
    i = scilinREG->RD;

    while(1);

/* USER CODE END */
}

What the code is supposed to do is enable the loop back mode of SCI2, write data on the transmit buffer and read it on the receive buffer. However, the data never appears on SCIRD, so the RXRDY flag is never set and the program gets stuck in the second while loop.

At first I thought the cause of the problem might be because I set the LOOP BACK bit after initializing SCI, but I have also tried doing this before the SWnRST bit is set and got the same result, so I do not know why this may be happening. I am using HALCoGen 04.00.00, CCS v5 and the XDS100v2 USB emulator. Attached is the CCS project for the program.

Any help would be much appreciated. Thanks in advance.


Cagil

SCI_DMA_4.zip
  • 0
    TI__Guru 59540 points

    Hello Cagil,

    Can you try replacing the code to set loop back mode in GCR1 with a call to the function:

    void sciEnableLoopback(sciBASE_t *sci, loopBackType_t Loopbacktype)

    This function configures the module in analog loopback mode such that you should be able to monitor the communication at the external pin.

    The loopback mode bit in GCR1 register is a digital loopback mode where you won't be able to probe the pin to see the data signals. This makes debug difficult.

  • 0 in reply to Chuck Davenport
    Prodigy 80 points

    Hello Chuck,


    Thanks for the answer. I have tried calling sciEnableLoopback() as you suggested but the result is the same.
     Unfortunately, I do not currently have the equipment required to monitor pin states, so I can't tell you what is going on in the SCI pins.


    Is there anything wrong in the original code that prevents loop back from working properly? Isn't this how you would normally enable digital loop back?


    Thanks again,


    Cagil

  • 0 in reply to Cagil Koroglu
    TI__Guru 59540 points

    Hello Cagil,

    In general I don't see any major issues with your code. The only thing that seems to go against the TRM statements is that you are enabling loopback mode after the TXENA and RXENA bits are set so, in theory, the SCI is enabled but not necessarily active. The statement in the TRM description of the loopback bit in GCR1 states that setting this bit while TX or RX is active that there could be errors. My interpretation of this is that it does not apply to your case since the SCi TX and RX are idle when you change this bit. To be certain, however, you could move this register right into the sciInit() function just before RXENA and TXENA are written to a 1. Alternatively, you could write RXENA and TXENA to 0 external to the init function, update the loopback bit, then re-enable RX and TX.

    Also a minor point that is probably not affecting the result, you have not assigned a type to the value 16 in the shift operation for writing to the loopback bit. To be safe, you should indicate that this value is 16U.

    I've also asked a colleague to have a look at the code and to compare to some validation code not generated with Halcogen that enables loopback mode. I'll post if there is anything enlightening discovered.

  • 0 in reply to Chuck Davenport
    Prodigy 80 points

    Hello Chuck,

    As I stated in the original post, I have tried setting the LOOP BACK bit during software reset (by doing this in sciInit() before SWnRST is set), with no luck. I am not sure if I did it before setting the RXENA and TXENA bits, however. I do not think  this is where the problem lies, but I will try this tomorrow, just to be sure, and let you know the result.

    You are right about the type of 16. I will change the code as you suggested, but I can confirm that this does not affect the result as I have used this type of assignment multiple times before, without the U appended, and it does work as intended.

    Waiting for your update on the issue.

    Thanks a lot,

    Cagil

  • 0 in reply to Cagil Koroglu
    Prodigy 80 points

    Hello Chuck,

    Just wanted to let you know that I have tried setting the LOOP BACK bit before RXENA and TXENA are set, and the result is still the same.

    Thanks,

    Cagil

  • 0 in reply to Cagil Koroglu
    TI__Guru 59540 points

    Hello Cagil,

    Unfortunately, I have only had small opportunities to play with this code today and have not identified the root cause why this code is not working. I have imported your project, built it, and ran through some debug; but still nothing to offer in regard to the solution. I will continue looking at this on Monday and let you know when I find the issue.

  • 0 in reply to Chuck Davenport
    Prodigy 80 points

    Hello Chuck,

    Thanks for taking the time trying to figure out the problem. I will be keeping an eye on this thread for any update you may have.

    Regards,

    Cagil

  • 0
    TI__Genius 14205 points

    Hi Cagil,

    Add wait for IDLE for the first time, i.,e immediately after you are out of sciInit(); function.

    while(sciIsIdleDetected(sciBASE_t *sci));

  • 0 in reply to Prathap
    TI__Guru 59540 points

    Cagil,

    Please give Prathap's guidance a try. I have added this to the code and confirmed that it is working in my setup.

  • 0 in reply to Chuck Davenport
    Prodigy 80 points

    Hello Chuck and Prathap,

    Thanks a lot for your help regarding this issue. Never thought the idle state of the receiver could be causing the problem. I do not currently have access to the MCU and am unable to test the code myself, but since the Prathap's solution seems to work for both of you, I don't see any reason why it wouldn't work for me; so I am verifying Prathap's answer.

    Many thanks,

    Cagil