K24 packet loss issue on UART1

[praveenkajjam]

We are facing some timing
issues on UART1 interfaced to BLE module of BlueGiga. We observed some packet
loss issues on data when we received in mobile over the air. We hooked up a
serial logic analyzer on UART1 and able to find clear timing issue on CTS. K24
is unable to handle the short RTS pulse from BLE module at higher bauds (115K).
Refer the attached images of LA capture for the behavior of CTS for good packet
transfer Vs bad packet transfer. UART1 behavior is stable until 38400 baud and
never observer any packet loss issue.

          
Also referred the silicon errata of K24 but it gave workaround for data
reception on UART1 but not for transmission. Please let us know how we can
handle this issue? This project is on critical path and this issue is holding
us to exit validation phase. Request you to quickly step into this issue and
provide us a quick resolution.

[krishnakishore]

Solved: Re: BLE112: CTS asserted too late - Silicon Labs Community 

link to the similar problem with K24 where we have some workarounds.

[isaacavila]

Hello Praveen,

It seems to me that next statement that is mentioned on RM is related to this issue:

In this case, if you look at your image in the failure condition, there is a minimum time between the stop bit for last successfully sent byte (second 0x77 byte) and CTS deassertion signal, so probably, this time (between stop bit and CTS desassertion) is not big enough to be detected for UART module before it can send the next byte. In this case, UART will continue to send next data (because UART module detected the CTS deassertion event once the third 0x77 byte has started to be sent) and before this data is sent completely, the CTS value asserts again and "communication" will continue. It is still pending to validate this issue with UART module's designers. (Because there is no "minimum time between last stop bit and CTS deassertion" that can confirm this theory). Following this theory, UART module didn't detect the CTS deassertion event and "communication" is not suspended.

When lower baud rates are used, the time between last stop bit and CTS deassertion event is bigger and could be identify for the module.

I will try to corroborate this theory with experts and also it would be good if you can tell me next conditions:

• Are you using both CTS and RTS signals for hardware control or only CTS is used?
• Are you using UART module with FIFO and/or DMA functionality? How do you configure the UARTx_MODEM register?

I will let you know when any update is received!

Regards,

Isaac

[krishnakishore]

Hi Isaac,

Thanks for your reply, somehow my timing analysis contradicts with your theory the time difference between the STOP bit and the CTS deassertion is always 1uS in all cases, please find the attached image for more details.

- Yes, I am using CTS and RTS signals for hardware flow control.

- Yes I am using UART with FIFO plz  find the code snippet of the UART init routine.

regards

kk

[isaacavila]

Hello Krishna,

I think you forgot to attach the image and code snippet.

Regards,

Isaac

[praveenkajjam]

Hi Isaac,

     Please find the attachment UART waveform capture. Below is the code snippet used for UART initialization.

#define BLE_UART_INSTANCE               1

void configure_uart_pins(uint32_t instance)
{
  switch(instance) {
    case 1:
      PORT_HAL_SetMuxMode(PORTE,00u,kPortMuxAlt3);          // UART1_TX
      PORT_HAL_SetMuxMode(PORTE,01u,kPortMuxAlt3);          // UART1_RX
      PORT_HAL_SetMuxMode(PORTE,02u,kPortMuxAlt3);          // UART1_CTS
      PORT_HAL_SetMuxMode(PORTE,03u,kPortMuxAlt3);          // UART1_RTS
      break;
    default:
      break;
  }
}

static void ble_configure_pins_mux (void)
{
    // Configure respective RS232 for BLE communication.
    // PTE 0, 1, 2 & 3 as TX, RX, CTS & RTS respectively
    configure_uart_pins (BLE_UART_INSTANCE);
}

uart_status_t ble_comm_init (uint32 u32_baudRate)
{
    uart_user_config_t BleUartConfig;
    UART_Type * const  BaseAddr = g_uartBase[BLE_UART_INSTANCE];
    uart_status_t      RetVal =

    ble_configure_pins_mux();

    BleUartConfig.baudRate        = u32_baudRate;
    BleUartConfig.bitCountPerChar = kUart8BitsPerChar;
    BleUartConfig.parityMode      = kUartParityDisabled;
    BleUartConfig.stopBitCount    = kUartOneStopBit;

    // Initialize the UART
    RetVal = UART_DRV_Init(BLE_UART_INSTANCE, &BleUartState, &BleUartConfig);

    // Enable RTS
    UART_HAL_SetReceiverRtsCmd(BaseAddr, 1);

    // Enable CTS
    UART_HAL_SetTransmitterCtsCmd(BaseAddr, 1);

    return RetVal;
}

int32 main()
{
    uart_status_t RetVal = ble_comm_init(115200);
    uint08        u08_data[10];
    if (RetVal == 0)
    {
        UART_DRV_SendData(BLE_UART_INSTANCE, u08_data, sizeof(u08_data));
    }
    return 0;
}

Thanks & Regards,

Praveen Kajjam

[isaacavila]

Hello Praveen,

First of all, it is important to mention that UART module works to start a transmission internally, so, from UART's perspective a "transmission" has started before data actually comes out on the Tx line. Data to be transmitted is loaded into the shift register and after that, you are at a point of no return.

Ideally, in order to prevent transmission of extra characters, the receiving device would negate CTS while it is in process of receiving the LAST character that it will be able to handle.

According to this, BLE device should assert CTS while it is receiving the third byte that appears on the image, so, before BLE receives the data completely, UART module can detect CTS assertion and prevent to load next data in the shift register.

What is it really happening on your tranmission?:

• UART module sends the third data and before it is completely received in BLE device, UART module polls for CTS' state, like it is still in low state, UART module can continue with its process, so next data is loaded in the shift register.
• Once BLE device receives the data, it changes CTS' state to inform UART that it cannot handle more data, however, at this point, next data was already loaded in the shift register and UART will send it out.
• In the good condition, this CTS pulse is insignificant (it returns to low state before first bit is sent) and BLE device can receive data.
• In failure condition, this CTS is returned to low state once some bits were already transmitted, so BLE device was unable to catch these bits. Before the current transmission is finished, BLE device returns to low level the CTS signal, so UART can be able to load the next byte.

Basically, in both cases, UART was unable to "catch" this CTS high level value, and it didn't pause the transmission. Difference between good and failure condition is the time needed for BLE to save the receiving data. Does it make sense to you?

I assume that you do not have so much to do with the CTS timing on the BLE module (you cannot control this signal to be set before the LAST character is being received completely), so you will have to slow down the data on the K24 side. That is why you do not miss data when lower baud rates are chosen.

I hope this can help you!

Regards.

Isaac Avila