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.

LAUNCHXL-F28379D: SCI-A transmitting issue

Part Number: LAUNCHXL-F28379D
Other Parts Discussed in Thread: C2000WARE

Hi , 

I am using LAUNCHXL-F28379D. I have configured SCI-A for baudrate : 2M.

SciaRegs.SCIHBAUD.all = 0x0000;
SciaRegs.SCILBAUD.all = 0x0002;

Tested the code. Data is transmitting & receiving properly.

void main(void)
{

InitSysCtrl();

InitGpio();


GPIO_SetupPinMux(43, GPIO_MUX_CPU1, 15);
GPIO_SetupPinOptions(43, GPIO_INPUT, GPIO_PUSHPULL);

GPIO_SetupPinMux(42, GPIO_MUX_CPU1, 15);
GPIO_SetupPinOptions(42, GPIO_OUTPUT, GPIO_ASYNC);


DINT;


InitPieCtrl();


IER = 0x0000;
IFR = 0x0000;


InitPieVectTable();

EALLOW;
CpuSysRegs.PCLKCR7.bit.SCI_A = 1;
EDIS;


LoopCount = 0;


EALLOW;
scia_uart_initialisation();
EDIS;

EINT; // Enable Global interrupt INTM
ERTM; // Enable Global realtime interrupt DBGM


msg = "\r\n Testing SCI Communication...!!! \n\r";
scia_msg(msg);


char snum[10];
while(1)
{
unsigned long int ii=0;
for (ii = 0; ii < 250000; ii++)
{
ltoa(ii,snum);
scia_msg(snum);
scia_msg("\n\r");
memset(snum,0,sizeof(snum));

}

void scia_uart_initialisation()
{

EALLOW; // This is needed to write to EALLOW protected registers
PieVectTable.SCIA_RX_INT = &sciaRxFifoIsr;
EDIS; // This is needed to disable write to EALLOW protected registers

EALLOW;
scia_fifo_init(); // Initialize the SCI FIFO

PieCtrlRegs.PIECTRL.bit.ENPIE = 1; // Enable the PIE block
PieCtrlRegs.PIEIER9.bit.INTx1 = 1; // PIE Group 9, INT1
PieCtrlRegs.PIEIER9.bit.INTx2 = 1; // PIE Group 9, INT2
IER |= 0x100; // Enable CPU INT
EINT;
}

void scia_xmit(int data)
{
while (SciaRegs.SCIFFTX.bit.TXFFST != 0) {}
SciaRegs.SCITXBUF.all = data;
}

void scia_fifo_init()
{
SciaRegs.SCICCR.all = 0x0007; // 1 stop bit, No loopback, No parity,8 char bits, async mode, idle-line protocol
SciaRegs.SCICTL1.all = 0x0003; // enable TX, RX, internal SCICLK, Disable RX ERR, SLEEP, TXWAKE
// SciaRegs.SCICTL2.all = 0x0003;
SciaRegs.SCICTL2.bit.TXINTENA = 1;
SciaRegs.SCICTL2.bit.RXBKINTENA = 1;

SciaRegs.SCIHBAUD.all = 0x0000;
SciaRegs.SCILBAUD.all = 0x0002;

SciaRegs.SCIFFTX.all = 0xE040;
SciaRegs.SCIFFRX.all = 0x0021;
SciaRegs.SCIFFCT.all = 0x0;


SciaRegs.SCICTL1.all = 0x0023; // Relinquish SCI from Reset

SciaRegs.SCIFFRX.bit.RXFIFORESET = 1;
}

//
// scia_msg - Transmit message via SCIA
//
void scia_msg(char * msg)
{
int i = 0;
while(msg[i] != '\0')
{
scia_xmit(msg[i]);
i++;
}
}


interrupt void sciaRxFifoIsr(void)
{
ReceivedChar = SciaRegs.SCIRXBUF.all; // Read data
scia_xmit(ReceivedChar); // For Debugging
SciaRegs.SCIFFRX.bit.RXFFOVRCLR=1; // Clear Overflow flag
SciaRegs.SCIFFRX.bit.RXFFINTCLR=1; // Clear Interrupt flag
PieCtrlRegs.PIEACK.all|=0x100; // Issue PIE ack

}

But on continuous transmission the data transmission fails. Please help me to solve the issue.

Regards,

Vijesh

  • Hi Vijesh,

    Can you elaborate a little bit on exactly what you mean by 'continuous transmission'? How does this differ from the working case where transmission is correct?

    Can you elaborate on how the transmission fails? If you scope the pins, is there no transmission, is the sent transmission corrupt, or is the received transmission corrupt?
  • Hi Devin Cottier,

    Thank you for your response.

    When I am trying to transmit the data from to 0 to 2000 with an increment by 1, i am receiving the data correctly.

    If i am trying to transfer the data from 0 to 25000 with an increment by 1, i am receiving the data correctly upto 2000 - 2500 values. After that the uart doesn't transmits the data. It can be verified with the led provided in the launchpad. I have checked with the oscilloscope also. 

    Thanks & Regards,

    Vijesh

  • Hi Vijesh,

    Does the transmission always fail on the same number? Does it fail if you count down instead of up? Does it fail if you start counting up at 2000, and if so, when (same place, or ~2000 messages in)?

    If it always fails after ~2000 messages, regardless of start location or direction, maybe the stack is overflowing? Does ltoa dynamically allocate a buffer and does memset truly deallocate it?

    If it is always the same location, maybe check that ltoa is producing the correct result? If that is true, strobe a GPIO when you send the first frame you expect to fail and use the scope to capture that data packet?
  •  

    Hi Devin ,

    Now I used Putty software to log the data. On testing I am getting the data continuously but with packet missing.

    Increased the stack size to 0x800 (Properties -> CCS Build -> C2000 Linker -> Basic Options -> stack size) & tested but same issue persists.

    Removed the ltoa() function with c code - packing missing persists.

    How can I verify whether the stack overflow occurs?

    Test Conducted

    Transmitted the data from 0 to 25000 with an increment by 1 , logged the received values using putty. 

    For the first time it will transmit up to 2220 count without any error or missing.After that on transmitting consecutive 4068 bytes , the data missing happens.

    Observation:

        Received Packets Count Missing Packets count No of bytes transmitted
    0 2220 2220 1652  
    3872 4550 678 1397 4068
    5947 6625 678 989 4068
    7614 8292 678 1132 4068
    9424 10087 663 778 4065
    10865 11446 581 749 4067
    12195 12776 581 843 4067
    13619 14200 581 825 4067
    15025 15606 581 862 4067
    16468 17049 581   4067

    Please give the suggestions to solve the issue.


    Thanks & Regards,

    Vijesh 

  • Hi Vijesh,

    If you doubled the stack size and the transmission failure rate is about the same, probably the issue isn't a stack overflow.

    If you wanted to investigate the stack anyway, a quick and dirty way would be to fill the upper unused part of the stack memory with some pattern (e.g. 0x1234) at the start of the program. Then let the program run for awhile. When you stop the program, you should be able to see which memory locations got used because they will no longer have the same pattern.

    Is there some other periodic ISR in your program with period that is roughly 4068 SCI packets? Some other high-energy periodic external signal?

    In your table, it looks like there are 1652 packets missing from 0 to 2200? Is that correct; I interpret the rest of your text to say that 0 to 2200 has no missing packets or errors? Also, is the primary issue that packets go missing, or that they are corrupt when they are received? If they are corrupt, what is wrong with them? Do they have single bit errors or inversions, or are they all 0's or 1's, or is the whole packet nonsense?
  • Hi Devin,

    Thank you for the reply.

    From table above

    Packets received without errors : from 0 to 2220 ,3872 to 4550, 5947 to 6625 and so on..

    Packets lost  was from 2220 to 3872(1652 packets), 4550 to 5947(1397 packets), 6625 to 7614(989 packets) and so on..

    No other ISR . I am using the example code provided in the C2000ware.

    If i reduced the baud rate to 250000 then i am receiving the data without any packet loss from 0 to  25000 and more.

    Thanks & Regards,

    Vijesh

  • Hi Vijesh,

    Understood. My understanding is that 2M baud should be possible for the SCI module itself.

    What clock are you using: Internal oscillator or an external XTAL or oscillator into X1?

    Is the device running at the full 200MHz SYSCLK?

    Have you verified that the SYSCLK is as expected via the XCLKOUT pin (this will be divided down, not the raw SYSCLK...default is SYSCLK/8):
    GpioCtrlRegs.GPCGMUX1.bit.GPIO73 = 0;
    GpioCtrlRegs.GPCMUX1.bit.GPIO73 = 3;
    GpioCtrlRegs.GPCDIR.bit.GPIO73 = 0;

    Does the transceiver you are using support up to 2M baud?

    Are you sure the receiver HW supports 2M baud?
  • Hi Devin,

    SYSCLK : 200MHz

    LPSCLK : 50MHz

    I am using Delfino Launchpad - external XTAL.

    I haven't verified the SYSCLK via the XCLKOUT pin.Will check & update you.

    Delfino is connected to the PC(receiver side) via inbuilt USB provided in launchpad(XDS100v2 OnBoard).

    Thanks & Regards

    Vijesh

  • Hi Vijesh,

    Checking XCLKOUT on the launchpad is a bit tricky since GPIO73 doesn't come out to a header. You have to do this by directly probing at the pin.

    It looks like the FTDI device on the board can do 2 or 3M baud:
    www.ftdichip.com/.../index.html

    But it looks like it needs to be exactly these bauds, as the resolution in baud rate selection for the chip is lower as the baud rate goes higher (same thing is true for selecting the baud on the SCI module).

    This thread also has some discussion:
    e2e.ti.com/.../579093

    I'm not able to find anything that specifies the exact max baud you can achieve on the XDS100. You might need to determine this experimentally or ask another e2e question specifically about the XDS100.

    It'd be interesting to send <4000 bytes, then wait, then send <4000 bytes, then wait .... etc. If this works you might conclude that the FTDI chip is getting overwhelmed by the continuously bridging transmissions between serial and USB at high baud.
  • Hi Devin,

    Thank you for your support.

    Changed the Delfino baud rate so as to match with the FTDI chip & is working fine with 500k & 1M baudrate.

    Thanks & Regards

    Vijesh