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

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);

  • Hi Nick

    This sounds like what the timeout parameter in the UART async driver was designed for, to forward the data in the buffers to the application if there has been no activity on the bus for a pre-determined amount of time. 

    Have you tried this? 

    You might also want to have a look at an example I made which intends to streamline the UART interface when using the ASYNC driver:
    https://github.com/too1/ncs-uart-handler

    Best regards
    Torbjørn

  • Hey Tobjørn,
    Thanks for sharing this library with me it looks like it could help alleviate a lot of my concerns.

    What version of NRF connect sdk has this been tested on? It appears the configuration suggested in the readme isn't relevant to 2.4.2: ZEPHYR_EXTRA_MODULES doesn't seem to exist and when I add it to ZEPHYR_MODULES it causes other issues.

    Thanks,
    Nick

  • Hi Nick

    I think it was tested on v2.3.0, but I just tested the simple and the peripheral_uart samples for the nRF52840DK and I can build the samples without any issues. 

    Did you try to build one of the included samples to see if they work? 

    If you try to include the module in your own sample it is important to get the relative location of the module correct, unless you keep it identical to the existing samples. 

    If you are still unable to get it to work, could you share the build output? 

    Best regards
    Torbjørn

  • Tobjørn,

    I was able to get this configured and working in my project and it seems to have resolved my issue!  Many thanks!

    It still seems to have some odd behavior, framing errors and overruns, if you send frames to it while it's in the middle of handling it's buffers; I'm testing limiting the UART sender so it allows for processing time between packets which seems to work.  I've never had so many issues with UART on other platforms before,  I guess my past experience is that the data is immediately (isr) taken out of peripheral register buffers and placed into RAM or that the peripheral has a byte level ring buffer inside of it that causes this not to be an issue.

    Anyways I'm not complaining I swear.  This library has made the best of a bad situation.  Thanks again my friend.

    All the best,
    Nick

  • Hi Nick

    You mean you are running into issues when using the ncs-uart-handler library I shared earlier?

    What UART baudrate are you running, and have you made any changes to the buffer configuration? 

    I have done testing to verify that the library should work even with constant coms at 1Mbaud, but I haven't really tested in a scenario with a lot of other things happening in the application. Are you running a lot of other peripherals, RF protocols etc on the side? 

    If the UART async callbacks are delayed too much by other interrupts in the system it will fail at some point, but ideally it should be possible to scale the buffers according to the worst case delay in order to avoid issues. 

    Best regards
    Torbjørn

Related