CC2640R2F: UART flow control and loss of data

I should have also said that I increased the size of UART_MAX_READ_SIZE to 2000. I didn't see any RAM issues with this. 

Hello,

It could be interesting to confirm if some data is dropped instrumenting the function SimpleStreamServer_sendData() (I think toggle a GPIO when some data is dropped can help).

For the rest, and as you mentioned, the example drops without warning all the data it cannot handle. Using the SimpleStreamServer_sendData(), you can identify when some data is dropped and take some actions.

I hope this will help,

Hi Phil,

Starting with the application in question, it will always restart the read, no matter if the sendData call fail (it will simply drop this data). You increasing the UART_MAX_READ_SIZE would not give you any reliability increase, it would just increase the possible maximum chunks you get (which is not a good thing).

As you need to allocate space for this data PLUS space for the BLE packet that is going to carry it, you would not really benefit from getting a 2 kB packet (i doubt you did get such a packet but just putting it out there).

This would also strip roughly 1.8 kB of the available heap which means the application should have around 7 KB when you have compiled the application (you could check the .map file for this). Take away the 4 KB headroom and you have theoretically 3 KB of heap left for your application before the SSS profile would start to reject you. Keep in mind that it is not only the UART and SSS profile here that uses the heap, so this first 3 KB could disappear rather quickly as you connect to devices etc. Once the 4 KB limit is reached, the SSS profile would reject any data sent into it and the application would then drop it. 

In a scenario where you need to be able to buffer more data "in the back" in between the read calls, you need to increase the internal ring buffer. How to do this is described in the "server" readme file.

Thanks for the responses so far.

Also thanks for clarifying the different buffers. I understand about the buffer sizes and obviously, there is always going to be a limit on how much data that can be held in these buffers but I thought the uart flow control would deal with this..

Over the last few days, I have tried changing the ringbuffer size (to 1500) which is about 50 bytes larger than my 1450 byte message. This still did not fix the problem - the Android app. still never gets the last few bytes of the message.

After the last message has been sent from the external processor, I always get a final call with SSSS_OUTGOING_DATA that then calls the function SimpleStreamServer_sendData  to move the uart buffer into the output queue. From what I can see, it is ONLY SimpleStreamServer_sendData that transfers the buffer (I have proved this by adding another test pin in sendData). Therefore, if no more data is sent from the external processor there will not be another request to move the pending data into the output queue. In my case, it appears that the previous attempt to send data failed due to the buffer size

i.e. (SimpleStreamNode_t*) SimpleStreamServer_allocateWithHeadroom(sizeof(SimpleStreamNode_t) + len) returns NULL

When this fails, I only get the continuous calls to transmit whatever is in the output queue, but the data still in the uart read buffer never gets to the queue so never gets sent. The only way I can get it to send is if I add a 50ms delay on the last few bytes (I presume the buffer is being empty to allow space for the extra few bytes). Another question would be why is the data taking so long to be transmitted in the first place?

I was expecting to see the UART flow control pins try to hold up the external processor from sending more data if the buffer is full. If these pins only work at the uart buffer level (not on the output queue), then they are of no real use.

I am thinking of driving the RTS/CTS pin directly from the application and disable them in the uart settings.

If I were to set the pin for RTS if the output queue is full (detected in SimpleStreamServer_sendData) and then clear it in SimpleSerialSocketServer_processConnEvt in the case of CONNECTION_EVENT_REGISTRATION_CAUSE(FOR_STREAM), would this be a better approach? Is there a danger of holding up the external processor indefinitely?

Thanks again for your help..

I just tried this again and can confirm it still fails with a UART_MAX_READ_SIZE of 64, uartCC26XXRingBuffer size of 1500. MIN_HEAP_HEADROOM is set to 4000.

I put my test pin in SimpleStreamServer_sendData and set it if the buffer size test returned NULL

    newNode = (EDTStreamNode_t*) EDTStreamServer_allocateWithHeadroom(sizeof(EDTStreamNode_t) + len);
    if (newNode == NULL) TestPin(true);

It seems this is set after only about 230 bytes have been sent to the uart (not 1500) as I was expecting with the above settings. Has this example been tested with RingBuffer sizes of > 256 bytes?

Here is the scope trace with this test pin.

Also, is there a quick and easy way to read the size of the uart read buffer in the _processConnEvt event? I tried to use uartCurrentMsg->len but it didn't seem to work.

Thanks again.

Thank you for your detailed reply.

I think I have been expecting too much from the hardware flow control pins.

I now have UART_MAX_READ_SIZE=32, MIN_HEAP_HEADROOM=4000, uartCC26XXRingBuffer size = 256.

I made this change in SimpleSerialSocketServer_processAppMsg to set the RTS pin as suggested

	case SSSS_OUTGOING_DATA:
	{
		// You could do processing of data here ...

		// For now, just Send the data read from UART over the air
		bStatus_t status = SimpleStreamServer_sendData(connHandle, &uartReadBuffer, pMsg->arg0);

		// If status is not successful, register for connection events for further processing
		if (status != SUCCESS) {
		        RtsPin(true);           // Hold off sending more data to the BLE
			SimpleSerialSocketServer_RegisterToAllConnectionEvent(FOR_STREAM);
		}
		else
		{
		    // Start another read but only if there is still space in the ring buffer
		    UART_read(uartHandle, uartReadBuffer, UART_MAX_READ_SIZE);
		}
		break;
	}

But I could not quite work how to call _sendData with the correct parameters. Here is what I tried (is this the correct interpretation of your suggestion?) I am not sure if the last parameter (uartCurrentMsg->len) is correct.

if (CONNECTION_EVENT_REGISTRATION_CAUSE(FOR_STREAM))
{
    // retry sendData in case there is data remaining in the UARTread buffer
TestPin(true);

	// The stream is active, process the stream at every connection event.
	bStatus_t status = SimpleStreamServer_processStream();

	// If status is successful there is no data pending for processing
	if (status == SUCCESS)
	{

	    bStatus_t sendStatus = SimpleStreamServer_sendData(connHandle, &uartReadBuffer, uartCurrentMsg->len);
	    if (sendStatus == SUCCESS)
	    {
	        RtsPin(false);                                                      // Release RTS to allow BLE to receive more uart data
	        UART_read(uartHandle, uartReadBuffer, UART_MAX_READ_SIZE);          // restart another uart read  here
	        SimpleSerialSocketServer_UnRegisterToAllConnectionEvent(FOR_STREAM);
	    }
	}
TestPin(false);
}

Unfortunately, it gave me other problems as the stream gets dropped half way through a message. 
This scope trace shows the full picture (stream gets dropped too soon). Test pin on connection event is around 50ms



This zoom of the first part shows the RTS is also doing something a bit strange. It goes high (and low) every 8 bytes or so. The only other place in the code that clears RTS is when a link is made and closed. 
It almost looks as though RTS is still being driven by the uart at this point (occurs at same time as a UART_read. My .ctsPin and .rtsPin have PIN_UNASSIGNED in the code.



What is the best way to get the space remaining in the buffers? 

I am using BLE5 (with SDK 4_10_0_10) .

Thanks
Phil

It seems we might need to be a bit more picky on the if statement here (actually, it made sense from the beginning, my suggestion was simply to simple). 

Consider the "sendData" function. It can return you a bunch of errors, it is really only one return value that should prompt us to stall the UART and that is memory errors (we do not care if the error says that we are out of notification slots for this). That means you likely want to do something like this:

// If status is not successful, register for connection events for further processing
if (status != SUCCESS) {
    SimpleSerialSocketServer_RegisterToAllConnectionEvent(FOR_STREAM);
}
    
if (status == bleMemAllocError)
{
    RtsPin(true);           // Hold off sending more data to the BLE
}
else
{
    // Start another read but only if there is still space in the ring buffer
    UART_read(uartHandle, uartReadBuffer, UART_MAX_READ_SIZE);
}

The thing with this is that "sendData" can return this error due to two reasons:

1) It failed to store the UART data internally. THIS is what we want to catch.
2) It failed to allocate the notification message struct.

While we are really only interested in 1), there should be no harm (that I see now) with reacting to the second in the same way. They both signal that there is a lack of heap. In fact, 2) does not take headroom into consideration so it should always require 1) to happen first anyway.

This should give you a bit more stable RTS pin. Now, in the connection event handler we also need to take the state of the RTS pin into consideration. We only want/need to do anything special IF the RTS is set, right?

if (CONNECTION_EVENT_REGISTRATION_CAUSE(FOR_STREAM))
{
    // retry sendData in case there is data remaining in the UARTread buffer
TestPin(true);

    // The stream is active, process the stream at every connection event.
    bStatus_t status = SimpleStreamServer_processStream();

    // If status is successful there is no data pending for processing
    if ((status == SUCCESS) && rtsPinSet())
    {
        bStatus_t sendStatus = SimpleStreamServer_sendData(connHandle, &uartReadBuffer, **LAST_UART_READ_LEN**);
        if (sendStatus == SUCCESS)
        {
            RtsPin(false);                                                      // Release RTS to allow BLE to receive more uart data
            UART_read(uartHandle, uartReadBuffer, UART_MAX_READ_SIZE);          // restart another uart read  here
            SimpleSerialSocketServer_UnRegisterToAllConnectionEvent(FOR_STREAM);
        }
    }
   else if (status == SUCCESS) 
  {
      SimpleSerialSocketServer_UnRegisterToAllConnectionEvent(FOR_STREAM); 
   }

TestPin(false);
}

Note the variable **LAST_UART_READ_LEN**, this is only there to highlight that you need to store away the read length globaly when setting the RTS pin so that you can later re-use it. Once you leave the "SSSS_OUTGOING_DATA", this information will be lost unless you do.