Sending data without a delimiter using the nordic uart service (NUS) sample - Dropping bytes

[jnenick]

I'm developing my application using the NRF Connect SDK in VS code.  SDK Version 2.4.2.  The NRF52832f we're using is integrated into a module made by fanstel and it has been assembled on our own internal ECU that interfaces with another microcontroller.  We're wanting to use the nordic uart service (NUS) to transfer data from one device to another,  in this case using two circuit boards but in the future one of the boards will be replaced by a smart phone.

In our project we're sending binary data using the nordic uart service profile with the peripheral uart service sample application connected to the central uart service sample application on a different evaluation board.  I added a periodic uart flush which disables the uart (code example below) because I don't have a delimiter character to indicate data is done being sent but I think this potentially makes me drop bytes when the central may receive bytes over it's physical UART between the time I disable the UART and before it's enabled again.  I see bytes drop frequently, using a BLE sniffer and also confirmed via inspection in the RTT console, which is causing serious throughput issues.

Does anyone have any experience with this?  I'm also concerned that even if I do designate a delimiter like \r\n the process of disabling/renabling the uart in the uart interrupt as is done in the sample project will still make bytes drop if more messages are sent in short succession after this.  Does anyone have the UART peripheral running without enable/disable anywhere and without delimiters?  Thanks in advance!

void uart_timeout_flush(void)
{
	for (;;) {
		if(uart_bytes_read > 0u)
		{
			uart_bytes_read = 0;
			LOG_INF("UART Flush: ");
			disable_req = true;
			uart_rx_disable(uart);
		}
		k_sleep(K_MSEC(50));
	}
}

K_THREAD_DEFINE(uart_timeout_flush_thread_id, UART_FLUSH_STACKSIZE, uart_timeout_flush, NULL, NULL,
		NULL, UART_FLUSH_PRIO, 0, 0);

[jnenick]

Torbjørn,

Correct.

Running very slow, 115200, even parity, no changes to the buffer configuration though I am reconfiguring the project as a central instead of a peripheral making a sort of "phone emulator" application.

There's essentially nothing going on outside tx/rx servicing in the application.  The main loop just reads a fifo (K_FOREVER) populated by the uart callback, sends the data to the nordic service and the bt callback frees the buffer after it's done being sent.

Maybe I'll try to change buffers but I even have problems sending fixed length 14 character strings once every 10ms.

Thanks,

Nick

[ovrebekk]

Hi Nick

This could be related to an issue in the UART async driver when using the default interrupt based byte counting method. You can optionally enable a hardware counting feature which uses more peripherals, but ensures byte counting is handled without CPU interaction required. 

In order to enable this you can have a look at these configuration parameters.

Could you add these configs and see if it solves the issue? 

Please note you need to change the name of the parameters if you want to use a different UART or TIMER module. 

Best regards
Torbjørn 

[jnenick]

Hey Torbjørn,

I meant to respond a while ago but:

I think I discovered the issue.  I was calling bt_nus_send directly in the callback,  I think it blocks too long from time to time and that causes the issue.

I'm now using a fifo and doing the sends from the main loop and everything looks great, with and without the configuration parameters you suggested.  (I was using UART0 btw so it made sense as is).

Hardware counting also was required to get it to work correctly or we would lose data.

Many thanks for all your help and your library,
Nick