TMS570LC4357: SCI1, SCI2 receive and transmit lost bytes

Hello Ugo,

The difference between SCI1/SCI2 and SCI3/SCI4 is that:

1. SCI1/SCI2 can be used for both SCI and LIN

2. SCI1/SCI2 supports multi-buffered mode

Do you use the same test code for SCI1/2 and SCI3/4? Do you use the SCI drivers generated by HALCoGen?

Hello, 

We made sure when doing the test that the sci configuration were the same, which the code was generated through halcogen. 

The code that is used is also the same, we only switched the SCI port that was used for the communication.

As I mentioned, this is an intermittent issue, and happens every now and then.

Best, 

Hello,

Is there any byte lost if you use same length?

When you change the transfer length in transmitter side, how does the receiver know the length? 

If the same frame is sent, it does not seems that there is a lost of bytes, however if there are different same size frames, then there is a lost of bytes. 

It really seems like the transmitter stops transmitting. i.e it will send the first X bytes, but not the rest of the frame.

We verified that all interrupts were effectively rising. We also turned off the interrupt routine for transmit, and no changes. We also reconfirmed that it was not an hardware issue on our side as we get the same issue when using the TMS570LC43 Devkit. 

Hello Ugo,

Yes, this is the SW related issue. 

In transmit side, the change of the frame length doesn't take effect if only the first X bytes (previous length) is transmitted.

You can define your own transmission protocol to send the frame length before sending the frame data. Otherwise, the receiver will ignore the extra bytes in the frame or hang up waiting or the new data (new length is smaller).

Can you share your code with us?

Hello QJ, 

I will try to find a way to share some code, as it is highly integrated. 

Regarding sending the frame length, it is not possible as it is a Modbus server and thus follow the protocol. 

However, one thing that still bothers me is why would I have an issue with the sci1,sci2 ports, but not the sci4 if it was to be software? The only thing on the software side that is changed is the assignment of the port for the application. 

Thanks

Hi Ugo,

If multi-buffer is not used, the SCI1/2 act the same as SCI4. I'd like to know the root cause.

Hi QJ, 

We do not use multi-buffer mode,

We did run some additional test, and the issue seems to be with the higher baudrates (57200, 115200) on sci1, irrespective of the number of stop bits/parity. 

Here is the Halcogen generated init. it is the same for sci4

    /** - bring SCI1 out of reset */
    sciREG1->GCR0 = 0U;
    sciREG1->GCR0 = 1U;

    /** - Disable all interrupts */
    sciREG1->CLEARINT    = 0xFFFFFFFFU;
    sciREG1->CLEARINTLVL = 0xFFFFFFFFU;

    /** - global control 1 */
    sciREG1->GCR1 =  (uint32)((uint32)1U << 25U)  /* enable transmit */
                  | (uint32)((uint32)1U << 24U)  /* enable receive */
                  | (uint32)((uint32)1U << 5U)   /* internal clock (device has no clock pin) */
                  | (uint32)((uint32)(2U-1U) << 4U)  /* number of stop bits */
                  | (uint32)((uint32)0U << 3U)  /* even parity, otherwise odd */
                  | (uint32)((uint32)0U << 2U)  /* enable parity */
                  | (uint32)((uint32)1U << 1U);  /* asynchronous timing mode */

    /** - set baudrate */
    sciREG1->BRS = 40U;  /* baudrate */

    /** - transmission length */
    sciREG1->FORMAT = 8U - 1U;  /* length */

    /** - set SCI1 pins functional mode */
    sciREG1->PIO0 = (uint32)((uint32)1U << 2U)  /* tx pin */
                 | (uint32)((uint32)1U << 1U); /* rx pin */

    /** - set SCI1 pins default output value */
    sciREG1->PIO3 = (uint32)((uint32)0U << 2U)  /* tx pin */
                 | (uint32)((uint32)0U << 1U); /* rx pin */

    /** - set SCI1 pins output direction */
    sciREG1->PIO1 = (uint32)((uint32)0U << 2U)  /* tx pin */
                 | (uint32)((uint32)0U << 1U); /* rx pin */

    /** - set SCI1 pins open drain enable */
    sciREG1->PIO6 = (uint32)((uint32)0U << 2U)  /* tx pin */
                 | (uint32)((uint32)0U << 1U); /* rx pin */

    /** - set SCI1 pins pullup/pulldown enable */
    sciREG1->PIO7 = (uint32)((uint32)0U << 2U)  /* tx pin */
                 | (uint32)((uint32)0U << 1U); /* rx pin */

    /** - set SCI1 pins pullup/pulldown select */
    sciREG1->PIO8 = (uint32)((uint32)1U << 2U)  /* tx pin */
                 | (uint32)((uint32)1U << 1U);  /* rx pin */

    /** - set interrupt level */
    sciREG1->SETINTLVL = (uint32)((uint32)0U << 26U)  /* Framing error */
                      | (uint32)((uint32)0U << 25U)  /* Overrun error */
                      | (uint32)((uint32)0U << 24U)  /* Parity error */
                      | (uint32)((uint32)0U << 9U)  /* Receive */
                      | (uint32)((uint32)0U << 8U)  /* Transmit */
                      | (uint32)((uint32)0U << 1U)  /* Wakeup */
                      | (uint32)((uint32)0U << 0U);  /* Break detect */

    /** - set interrupt enable */
    sciREG1->SETINT = (uint32)((uint32)0U << 26U)  /* Framing error */
                   | (uint32)((uint32)0U << 25U)  /* Overrun error */
                   | (uint32)((uint32)0U << 24U)  /* Parity error */
                   | (uint32)((uint32)1U << 9U)  /* Receive */
                   | (uint32)((uint32)0U << 1U)  /* Wakeup */
                   | (uint32)((uint32)0U << 0U);  /* Break detect */

    /** - initialize global transfer variables */
    g_sciTransfer_t[0U].mode   = (uint32)1U << 8U;
    g_sciTransfer_t[0U].tx_length = 0U;
	g_sciTransfer_t[0U].rx_length = 0U;

    /** - Finaly start SCI1 */
    sciREG1->GCR1 |= 0x80U;

 We would also like to know the root cause. 

Thanks

Hello,

You use interrupt for both TX and RX. There is no problem in this code generated by HALCoGen.

For receiving, you need to call sciReceive() to update the length before the transmitter changes the frame length.