nRF52DK nRF52832 UART asynchronous receive

RE: nRF52DK nRF52832 UART asynchronous receive

Sarkar — Tue, 18 Mar 2025 12:59:59 GMT

Hi zazas321

Can I have your code for testing.

Actually I tried this code only then noticed a my_gpio header file so asking for your help to understand the code.

I am also trying for the UART part.

RE: nRF52DK nRF52832 UART asynchronous receive

Edvin — Thu, 01 Feb 2024 13:49:14 GMT

Hello,

Andreas is currently busy with other tasks, so I will have a look at this ticket.

Please note that there is a lot of information here, but I have tried to get a reasonable overview.

[quote user="zazas321"]POINT 1[/quote]

Yes. This is a very simplified application. I suspect you are looking for functionality closer to the one found in ncs\nrf\samples\bluetooth\peripheral_uart. Please note that this doesn't echo the data back on the UART, but it will transmit the UART data over BLE to the connected device. Please see the sample description.

[quote user="zazas321"]POINT 2[/quote]

Noted. I agree.

[quote user="zazas321"]POINT 3[/quote]

This makes sense, actually.

printf, in your case uses the UART backend, so every time you send a message, or possibly a character, over UART, it will trigger a new callback to the very same uart callback that printed the character in the first place. Therefore, I recommend, if you want to use the log while using the UART, you should use the logging module (LOG_INF()) with RTT backend (and not UART backend). To see how to do this, look at how it is done in the ncs\nrf\samples\bluetooth\peripheral_uart sample.

[quote user="zazas321"]Is this expected behaviour that a few printf statements in uart_cb causes weird behaviour as have been shown above?[/quote]

I wouldn't recommend using printf(), which will trigger uart callbacks inside the uart_cb.

[quote user="zazas321"] If above is true, I am concerned about other high priority tasks or callbacks interrupting the UART reception and causing similar issues even when all print statements are removed from the callback itself. Is ASYNC UART affected by other Zephyr RTOS threads running or it is independent and not affected at all?[/quote]

I don't think you will see similar issues with other high priority interrupts, as long as they are not triggered recursively via the UART callback.

[quote user="zazas321"]During the discussion above it has been mentioned that it is recommended to use larger UART_BUF_SIZE but that did not help in any way. The only thing that does is just simply requires more serial data to be received before it fills up and eventually breaks.[/quote]

I agree. That will just postpone the issue.

[quote user="zazas321"]I would highly appreciate if someone with good Zephyr and ASYNC UART knowledge could shed some light here and cover the issues that I have encountered and the solutions that I have found.[/quote]

I agree that this seems like a good solution for this need. However, I suggest not using the UART for log messages at all inside the uart callback handler. Either use no log, or use the RTT backend.

Best regards,

Edvin

RE: nRF52DK nRF52832 UART asynchronous receive

zazas321 — Thu, 01 Feb 2024 06:43:43 GMT

It has been a while but I still believe some things are not fully clear regarding ASYNC UART. Perhaps some things will be clarified at some point:

POINT 1

The async UART lesson in the code academy (https://academy.nordicsemi.com/courses/nrf-connect-sdk-fundamentals/lessons/lesson-4-serial-communication-uart/topic/exercise-1-5/)
can only be used in cases where the fixed length serial data is being received which is not what most UART use cases are like.

POINT 2

In order to use async UART when trying to receive varying length serial data (strings) with terminator, double buffer approach should be used because we need to handle a scenario where the buffer fills up but the full message hasnt been received and we need to stitch 2 buffers together to build a complete message.

I have created some test code to test this out:

/*
 * Copyright (c) 2012-2014 Wind River Systems, Inc.
 *
 * SPDX-License-Identifier: Apache-2.0
 */

#include <zephyr/kernel.h>
#include <zephyr/drivers/gpio.h>
#include "stdio.h"
#include "my_gpio.h"
#include "zephyr/drivers/uart.h"
#include <zephyr/sys/ring_buffer.h>

#define LOG_LEVEL 4
#include <zephyr/logging/log.h>
LOG_MODULE_REGISTER(nrf52_learning);

#define UART_BUF_SIZE 24

#define UART_RX_TIMEOUT_MS 1000
K_SEM_DEFINE(rx_disabled, 0, 1);

// UART RX primary buffers
uint8_t uart_double_buffer[2][UART_BUF_SIZE];

uint8_t *uart_buf_next = uart_double_buffer[1];

uint8_t complete_message[UART_BUF_SIZE];
uint8_t complete_message_counter = 0;
bool currently_active_buffer = 1; // 0 - uart_double_buffer[0] is active, 1 - uart_double_buffer[1] is active

static const struct device *dev_uart;

static void uart_cb(const struct device *dev, struct uart_event *evt, void *user_data)
{

	switch (evt->type)
	{

	case UART_TX_DONE:
		printf("transmission complete \n");
		break;

	case UART_TX_ABORTED:
		// do something
		break;

	case UART_RX_RDY:

		printf("Received %i bytes \n", evt->data.rx.len);
		printf("Offset = %i  \n", evt->data.rx.offset);

		printf("Constructing a complete message \n");
		if (currently_active_buffer == 0)
		{
			// read all characters one by one till new line is found
			for (int i = 0 + evt->data.rx.offset; i < UART_BUF_SIZE; i++)
			{
				complete_message[complete_message_counter] = uart_double_buffer[0][i];
				complete_message_counter++;
				if (uart_double_buffer[0][i] == '\n')
				{
					printf("new line found at buffer 0 index = %i \n", i);
					complete_message_counter = 0;
					printf("complete_message = %s \n", complete_message);
					memset(&complete_message, 0, sizeof(complete_message)); // clear out the buffer to prepare for next read.
					break;
				}
			}
		}

		if (currently_active_buffer == 1)
		{
			// read all characters one by one till new line is found
			for (int i = 0 + evt->data.rx.offset; i < UART_BUF_SIZE; i++)
			{
				complete_message[complete_message_counter] = uart_double_buffer[1][i];
				complete_message_counter++;
				if (uart_double_buffer[1][i] == '\n')
				{
					printf("new line found at buffer 1 index = %i \n", i);
					complete_message_counter = 0;
					printf("complete_message = %s \n", complete_message);
					memset(&complete_message, 0, sizeof(complete_message)); // clear out the buffer to prepare for next read.
					break;
				}
			}
		}

		break;

	case UART_RX_BUF_REQUEST:
		uart_rx_buf_rsp(dev_uart, uart_buf_next, UART_BUF_SIZE);
		currently_active_buffer = !currently_active_buffer;
		if (currently_active_buffer == 0)
		{
			printf("currently active buffer is uart_double_buffer[0] \n");
		}
		else
		{
			printf("currently active buffer is uart_double_buffer[1] \n");
		}
		break;

	case UART_RX_BUF_RELEASED:
		printf("Old buffer has been released \n");
		uart_buf_next = evt->data.rx_buf.buf;
		break;

	case UART_RX_DISABLED:
		printf("rx disabled \n");
		k_sem_give(&rx_disabled);
		break;

	case UART_RX_STOPPED:
		// do something
		break;

	default:
		break;
	}
}

void app_uart_init()
{
	dev_uart = DEVICE_DT_GET(DT_NODELABEL(uart0));

	if (!device_is_ready(dev_uart))
	{
		return 0;
	}

	int err;
	err = uart_callback_set(dev_uart, uart_cb, NULL);
	if (err)
	{
		return err;
	}
	uart_rx_enable(dev_uart, uart_double_buffer[0], UART_BUF_SIZE, UART_RX_TIMEOUT_MS);
}

int main(void)
{
	app_uart_init();
}

and prj.conf

CONFIG_SERIAL=y
CONFIG_UART_ASYNC_API=y
CONFIG_LOG=y

And I have tested it out on the nRF52840DK NRF52840

The problem with the above code is that once the buffer fills up (UART_BUF_SIZE set to 24), the complete message will not be constructed properly out of 2 buffers. This can be easily observed here:

POINT 3

After many hours of debugging the code above, I have figured out what was causing the issues. It turned out to be printf staments. I have removed most of the printf statements and only left the complete_message print. The full code:

/*
 * Copyright (c) 2012-2014 Wind River Systems, Inc.
 *
 * SPDX-License-Identifier: Apache-2.0
 */

#include <zephyr/kernel.h>
#include <zephyr/drivers/gpio.h>
#include "stdio.h"
#include "my_gpio.h"
#include "zephyr/drivers/uart.h"
#include <zephyr/sys/ring_buffer.h>

#define LOG_LEVEL 4
#include <zephyr/logging/log.h>
LOG_MODULE_REGISTER(nrf52_learning);

#define UART_BUF_SIZE 24

#define UART_RX_TIMEOUT_MS 1000
K_SEM_DEFINE(rx_disabled, 0, 1);

// UART RX primary buffers
uint8_t uart_double_buffer[2][UART_BUF_SIZE];

uint8_t *uart_buf_next = uart_double_buffer[1];

uint8_t complete_message[UART_BUF_SIZE];
uint8_t complete_message_counter = 0;
bool currently_active_buffer = 1; // 0 - uart_double_buffer[0] is active, 1 - uart_double_buffer[1] is active

static const struct device *dev_uart;

static void uart_cb(const struct device *dev, struct uart_event *evt, void *user_data)
{

	switch (evt->type)
	{

	case UART_TX_DONE:
		//printf("transmission complete \n");
		break;

	case UART_TX_ABORTED:
		// do something
		break;

	case UART_RX_RDY:

		//printf("Received %i bytes \n", evt->data.rx.len);
		//printf("Offset = %i  \n", evt->data.rx.offset);

		//printf("Constructing a complete message \n");
		if (currently_active_buffer == 0)
		{
			// read all characters one by one till new line is found
			for (int i = 0 + evt->data.rx.offset; i < UART_BUF_SIZE; i++)
			{
				complete_message[complete_message_counter] = uart_double_buffer[0][i];
				complete_message_counter++;
				if (uart_double_buffer[0][i] == '\n')
				{
					//printf("new line found at buffer 0 index = %i \n", i);
					complete_message_counter = 0;
					printf("complete_message = %s \n", complete_message);
					memset(&complete_message, 0, sizeof(complete_message)); // clear out the buffer to prepare for next read.
					break;
				}
			}
		}

		if (currently_active_buffer == 1)
		{
			// read all characters one by one till new line is found
			for (int i = 0 + evt->data.rx.offset; i < UART_BUF_SIZE; i++)
			{
				complete_message[complete_message_counter] = uart_double_buffer[1][i];
				complete_message_counter++;
				if (uart_double_buffer[1][i] == '\n')
				{
					//printf("new line found at buffer 1 index = %i \n", i);
					complete_message_counter = 0;
					printf("complete_message = %s \n", complete_message);
					memset(&complete_message, 0, sizeof(complete_message)); // clear out the buffer to prepare for next read.
					break;
				}
			}
		}

		break;

	case UART_RX_BUF_REQUEST:
		uart_rx_buf_rsp(dev_uart, uart_buf_next, UART_BUF_SIZE);
		currently_active_buffer = !currently_active_buffer;
		if (currently_active_buffer == 0)
		{
			//printf("currently active buffer is uart_double_buffer[0] \n");
		}
		else
		{
			//printf("currently active buffer is uart_double_buffer[1] \n");
		}
		break;

	case UART_RX_BUF_RELEASED:
		//printf("Old buffer has been released \n");
		uart_buf_next = evt->data.rx_buf.buf;
		break;

	case UART_RX_DISABLED:
		//printf("rx disabled \n");
		k_sem_give(&rx_disabled);
		break;

	case UART_RX_STOPPED:
		// do something
		break;

	default:
		break;
	}
}

void app_uart_init()
{
	dev_uart = DEVICE_DT_GET(DT_NODELABEL(uart0));

	if (!device_is_ready(dev_uart))
	{
		return 0;
	}

	int err;
	err = uart_callback_set(dev_uart, uart_cb, NULL);
	if (err)
	{
		return err;
	}
	uart_rx_enable(dev_uart, uart_double_buffer[0], UART_BUF_SIZE, UART_RX_TIMEOUT_MS);
}

int main(void)
{
	app_uart_init();
}

and prj.conf:

CONFIG_SERIAL=y
CONFIG_UART_ASYNC_API=y
CONFIG_LOG=y

And when I try to send the exact same sequence of messages using serial terminal, it seems to work fine even after the UART buffer fills up:

POINT 4

4. Additionally, I have found out that if you add options :

CONFIG_UART_0_ASYNC=y
CONFIG_UART_0_NRF_HW_ASYNC=y
CONFIG_UART_0_NRF_HW_ASYNC_TIMER=2
CONFIG_NRFX_TIMER2=y

in the prj.conf, then the complete messages will be received even if I use many printf statements. I do not fully understand why and how which is quite frustrating.

The full code:

/*
 * Copyright (c) 2012-2014 Wind River Systems, Inc.
 *
 * SPDX-License-Identifier: Apache-2.0
 */

#include <zephyr/kernel.h>
#include <zephyr/drivers/gpio.h>
#include "stdio.h"
#include "my_gpio.h"
#include "zephyr/drivers/uart.h"
#include <zephyr/sys/ring_buffer.h>

#define LOG_LEVEL 4
#include <zephyr/logging/log.h>
LOG_MODULE_REGISTER(nrf52_learning);

#define UART_BUF_SIZE 24

#define UART_RX_TIMEOUT_MS 1000
K_SEM_DEFINE(rx_disabled, 0, 1);

// UART RX primary buffers
uint8_t uart_double_buffer[2][UART_BUF_SIZE];

uint8_t *uart_buf_next = uart_double_buffer[1];

uint8_t complete_message[UART_BUF_SIZE];
uint8_t complete_message_counter = 0;
bool currently_active_buffer = 1; // 0 - uart_double_buffer[0] is active, 1 - uart_double_buffer[1] is active

static const struct device *dev_uart;

static void uart_cb(const struct device *dev, struct uart_event *evt, void *user_data)
{

	switch (evt->type)
	{

	case UART_TX_DONE:
		printf("transmission complete \n");
		break;

	case UART_TX_ABORTED:
		// do something
		break;

	case UART_RX_RDY:

		printf("Received %i bytes \n", evt->data.rx.len);
		printf("Offset = %i  \n", evt->data.rx.offset);

		printf("Constructing a complete message \n");
		if (currently_active_buffer == 0)
		{
			// read all characters one by one till new line is found
			for (int i = 0 + evt->data.rx.offset; i < UART_BUF_SIZE; i++)
			{
				complete_message[complete_message_counter] = uart_double_buffer[0][i];
				complete_message_counter++;
				if (uart_double_buffer[0][i] == '\n')
				{
					printf("new line found at buffer 0 index = %i \n", i);
					complete_message_counter = 0;
					printf("complete_message = %s \n", complete_message);
					memset(&complete_message, 0, sizeof(complete_message)); // clear out the buffer to prepare for next read.
					break;
				}
			}
		}

		if (currently_active_buffer == 1)
		{
			// read all characters one by one till new line is found
			for (int i = 0 + evt->data.rx.offset; i < UART_BUF_SIZE; i++)
			{
				complete_message[complete_message_counter] = uart_double_buffer[1][i];
				complete_message_counter++;
				if (uart_double_buffer[1][i] == '\n')
				{
					printf("new line found at buffer 1 index = %i \n", i);
					complete_message_counter = 0;
					printf("complete_message = %s \n", complete_message);
					memset(&complete_message, 0, sizeof(complete_message)); // clear out the buffer to prepare for next read.
					break;
				}
			}
		}

		break;

	case UART_RX_BUF_REQUEST:
		uart_rx_buf_rsp(dev_uart, uart_buf_next, UART_BUF_SIZE);
		currently_active_buffer = !currently_active_buffer;
		if (currently_active_buffer == 0)
		{
			printf("currently active buffer is uart_double_buffer[0] \n");
		}
		else
		{
			printf("currently active buffer is uart_double_buffer[1] \n");
		}
		break;

	case UART_RX_BUF_RELEASED:
		printf("Old buffer has been released \n");
		uart_buf_next = evt->data.rx_buf.buf;
		break;

	case UART_RX_DISABLED:
		printf("rx disabled \n");
		k_sem_give(&rx_disabled);
		break;

	case UART_RX_STOPPED:
		// do something
		break;

	default:
		break;
	}
}

void app_uart_init()
{
	dev_uart = DEVICE_DT_GET(DT_NODELABEL(uart0));

	if (!device_is_ready(dev_uart))
	{
		return 0;
	}

	int err;
	err = uart_callback_set(dev_uart, uart_cb, NULL);
	if (err)
	{
		return err;
	}
	uart_rx_enable(dev_uart, uart_double_buffer[0], UART_BUF_SIZE, UART_RX_TIMEOUT_MS);
}

int main(void)
{
	app_uart_init();
}

and prj.conf:

CONFIG_SERIAL=y
CONFIG_UART_ASYNC_API=y
CONFIG_LOG=y



CONFIG_UART_0_ASYNC=y
CONFIG_UART_0_NRF_HW_ASYNC=y
CONFIG_UART_0_NRF_HW_ASYNC_TIMER=2
CONFIG_NRFX_TIMER2=y

Despite the solution being found, it is still not fully clear to me what is the best way to handle ASYNC UART varying length data reception. I could not find enough information/examples available to fully understand the different methods of handling ASYNC UART reception and I am hoping to get some clarifications regarding this.

Is this expected behaviour that a few printf statements in uart_cb causes weird behaviour as have been shown above?

If above is true, I am concerned about other high priority tasks or callbacks interrupting the UART reception and causing similar issues even when all print statements are removed from the callback itself. Is ASYNC UART affected by other Zephyr RTOS threads running or it is independent and not affected at all?

During the discussion above it has been mentioned that it is recommended to use larger UART_BUF_SIZE but that did not help in any way. The only thing that does is just simply requires more serial data to be received before it fills up and eventually breaks.

Throughout this discussion, other things have been suggested such as using additional config options:

CONFIG_UART_0_ASYNC=y
CONFIG_UART_0_NRF_HW_ASYNC=y
CONFIG_UART_0_NRF_HW_ASYNC_TIMER=2
CONFIG_NRFX_TIMER2=y

which seem to help when having multiple print statements in the callback.

I would highly appreciate if someone with good Zephyr and ASYNC UART knowledge could shed some light here and cover the issues that I have encountered and the solutions that I have found. I believe the solutions that I have discovered are not the most optimal and not the best way to handle UART ASYNC data reception. I also believe that this should be relevant for other developers who are working with ASYNC UART.

RE: nRF52DK nRF52832 UART asynchronous receive

AHaug — Wed, 08 Nov 2023 09:57:45 GMT

Achim Kraus Thank you for the input, it's been very valuable to the discussion

Regarding answering directly to a specific comment, you can use the quote funcitonality.

[quote user="zazas321"]AHaug Hello. It has been a while. Perhaps you had some time to look at our latest discussion with Achim Kraus ?

We have discovered some interesting things about ASYNC UART and it would be really nice to get to the bottom of this.[/quote]

@zazas321, I've seen the discussion that has been ongoing here and I have nothing more to contribute to it other than the items that has already been discussed.

I find in my own experiments as well that a larger buffer is required to allow for enough time to pass so that the buffers can fill, send, swap and empty properly

Kind regards,
Andreas

RE: nRF52DK nRF52832 UART asynchronous receive

zazas321 — Tue, 07 Nov 2023 19:29:26 GMT

AHaug Hello. It has been a while. Perhaps you had some time to look at our latest discussion with Achim Kraus ?

We have discovered some interesting things about ASYNC UART and it would be really nice to get to the bottom of this.

RE: nRF52DK nRF52832 UART asynchronous receive

zazas321 — Sat, 28 Oct 2023 12:19:57 GMT

Hello. Thank you very much for all your insights.

I have played around more with my project (Async_UART_debug) branch and I have found something interesting. printk and prinf statements have huge effect on it.

Even replacing printk statements with cause the Async UART reception to behave differently.

The full code (also available in my repository, UART_async_working branch.

/*
 * Copyright (c) 2012-2014 Wind River Systems, Inc.
 *
 * SPDX-License-Identifier: Apache-2.0
 */

#include <zephyr/kernel.h>
#include <zephyr/drivers/gpio.h>
#include "stdio.h"
#include "my_gpio.h"
#include "zephyr/drivers/uart.h"
#include <zephyr/sys/ring_buffer.h>

#define LOG_LEVEL 4
#include <zephyr/logging/log.h>
LOG_MODULE_REGISTER(nrf52_learning);

#define UART_BUF_SIZE 20

#define UART_RX_TIMEOUT_MS 1000
K_SEM_DEFINE(rx_disabled, 0, 1);

// UART RX primary buffers
uint8_t uart_double_buffer[2][UART_BUF_SIZE];

uint8_t *uart_buf_next = uart_double_buffer[1];

uint8_t complete_message[UART_BUF_SIZE];
uint8_t complete_message_counter = 0;
bool currently_active_buffer = 1; // 0 - uart_double_buffer[0] is active, 1 - uart_double_buffer[1] is active

static const struct device *dev_uart;

static void uart_cb(const struct device *dev, struct uart_event *evt, void *user_data)
{

	switch (evt->type)
	{

	case UART_TX_DONE:
		break;

	case UART_TX_ABORTED:
		// do something
		break;

	case UART_RX_RDY:

		printk("Received %i bytes \n", evt->data.rx.len);
		printk("Offset = %i  \n", evt->data.rx.offset);

		if (currently_active_buffer == 0)
		{
			// read all characters one by one till new line is found
			for (int i = 0 + evt->data.rx.offset; i < UART_BUF_SIZE; i++)
			{
				complete_message[complete_message_counter] = uart_double_buffer[0][i];
				complete_message_counter++;
				if (uart_double_buffer[0][i] == '\n')
				{
					complete_message_counter = 0;
					printk("complete_message = %s \n", complete_message);
					memset(&complete_message, 0, sizeof(complete_message)); // clear out the buffer to prepare for next read.
					break;
				}
			}
		}

		if (currently_active_buffer == 1)
		{
			// read all characters one by one till new line is found
			for (int i = 0 + evt->data.rx.offset; i < UART_BUF_SIZE; i++)
			{
				complete_message[complete_message_counter] = uart_double_buffer[1][i];
				complete_message_counter++;
				if (uart_double_buffer[1][i] == '\n')
				{
					complete_message_counter = 0;
					printk("complete_message = %s \n", complete_message);
					memset(&complete_message, 0, sizeof(complete_message)); // clear out the buffer to prepare for next read.
					break;
				}
			}
		}

		break;

	case UART_RX_BUF_REQUEST:
		uart_rx_buf_rsp(dev_uart, uart_buf_next, UART_BUF_SIZE);
		currently_active_buffer = !currently_active_buffer;
		break;

	case UART_RX_BUF_RELEASED:
		uart_buf_next = evt->data.rx_buf.buf;
		break;

	case UART_RX_DISABLED:
		k_sem_give(&rx_disabled);
		break;

	case UART_RX_STOPPED:
		// do something
		break;

	default:
		break;
	}
}

void app_uart_init()
{
	dev_uart = DEVICE_DT_GET(DT_NODELABEL(uart0));

	if (!device_is_ready(dev_uart))
	{
		return 0;
	}

	int err;
	err = uart_callback_set(dev_uart, uart_cb, NULL);
	if (err)
	{
		return err;
	}
	uart_rx_enable(dev_uart, uart_double_buffer[0], UART_BUF_SIZE, UART_RX_TIMEOUT_MS);
}

int main(void)
{
	app_uart_init();
}

and my prj.conf:

CONFIG_SERIAL=y
CONFIG_UART_ASYNC_API=y
CONFIG_LOG=y

I have removed most debugging printf/prink statements and only left one or two. You can see that it seems to work now. I am able to send/receive messages and uart_event.rx.len/uart_event.rx.offset seems to be correct now.

It would be very interesting to hear response from nordic about what exactly is happening and also about the additional options that you have suggested:

CONFIG_UART_0_ASYNC=y
CONFIG_UART_0_NRF_HW_ASYNC=y
CONFIG_UART_0_NRF_HW_ASYNC_TIMER=2
CONFIG_NRFX_TIMER2=y

UPDATE

I can confirm that after adding additional prj.conf options that you have suggested, it works much better. I have even managed to get it to work with additional printf/printk statements just by adding these extra options.

I have even tested it out on my master branch (the branch where I had all the issues initially).

See the full code below:

/*
 * Copyright (c) 2012-2014 Wind River Systems, Inc.
 *
 * SPDX-License-Identifier: Apache-2.0
 */

#include <zephyr/kernel.h>
#include <zephyr/drivers/gpio.h>
#include "stdio.h"
#include "my_gpio.h"
#include "zephyr/drivers/uart.h"
#include <zephyr/sys/ring_buffer.h>

#define LOG_LEVEL 4
#include <zephyr/logging/log.h>
LOG_MODULE_REGISTER(nrf52_learning);

#define UART_BUF_SIZE 20

#define UART_RX_TIMEOUT_MS 1000
K_SEM_DEFINE(rx_disabled, 0, 1);

// UART RX primary buffers
uint8_t uart_double_buffer[2][UART_BUF_SIZE];

uint8_t *uart_buf_next = uart_double_buffer[1];

uint8_t complete_message[UART_BUF_SIZE];
uint8_t complete_message_counter = 0;
bool currently_active_buffer = 1; // 0 - uart_double_buffer[0] is active, 1 - uart_double_buffer[1] is active

static const struct device *dev_uart;

static void uart_cb(const struct device *dev, struct uart_event *evt, void *user_data)
{

	switch (evt->type)
	{

	case UART_TX_DONE:
		printf("transmission complete \n");
		break;

	case UART_TX_ABORTED:
		// do something
		break;

	case UART_RX_RDY:

		printf("Received %i bytes \n", evt->data.rx.len);
		printf("Offset = %i  \n", evt->data.rx.offset);

		printf("evt->data.rx.buf: [");
		for (int i = 0; i < UART_BUF_SIZE; i++)
		{
			printf("%u, ", evt->data.rx.buf[i]);
		}
		printf("] \n");

		printf("uart_double_buffer[0]: [");
		for (int i = 0; i < UART_BUF_SIZE; i++)
		{
			printf("%u, ", uart_double_buffer[0][i]);
		}
		printf("] \n");

		printf("uart_double_buffer[1]: [");
		for (int i = 0; i < UART_BUF_SIZE; i++)
		{
			printf("%u, ", uart_double_buffer[1][i]);
		}
		printf("] \n");

		printf("Constructing a complete message \n");
		if (currently_active_buffer == 0)
		{
			// read all characters one by one till new line is found
			for (int i = 0 + evt->data.rx.offset; i < UART_BUF_SIZE; i++)
			{
				complete_message[complete_message_counter] = uart_double_buffer[0][i];
				complete_message_counter++;
				if (uart_double_buffer[0][i] == '\n')
				{
					printf("new line found at buffer 0 index = %i \n", i);
					complete_message_counter = 0;
					printf("complete_message = %s \n", complete_message);
					memset(&complete_message, 0, sizeof(complete_message)); // clear out the buffer to prepare for next read.
					break;
				}
			}
		}

		if (currently_active_buffer == 1)
		{
			// read all characters one by one till new line is found
			for (int i = 0 + evt->data.rx.offset; i < UART_BUF_SIZE; i++)
			{
				complete_message[complete_message_counter] = uart_double_buffer[1][i];
				complete_message_counter++;
				if (uart_double_buffer[1][i] == '\n')
				{
					printf("new line found at buffer 1 index = %i \n", i);
					complete_message_counter = 0;
					printf("complete_message = %s \n", complete_message);
					memset(&complete_message, 0, sizeof(complete_message)); // clear out the buffer to prepare for next read.
					break;
				}
			}
		}

		break;

	case UART_RX_BUF_REQUEST:
		uart_rx_buf_rsp(dev_uart, uart_buf_next, UART_BUF_SIZE);
		currently_active_buffer = !currently_active_buffer;
		if (currently_active_buffer == 0)
		{
			printf("currently active buffer is uart_double_buffer[0] \n");
		}
		else
		{
			printf("currently active buffer is uart_double_buffer[1] \n");
		}
		break;

	case UART_RX_BUF_RELEASED:
		printf("Old buffer has been released \n");
		uart_buf_next = evt->data.rx_buf.buf;
		break;

	case UART_RX_DISABLED:
		printf("rx disabled \n");
		k_sem_give(&rx_disabled);
		break;

	case UART_RX_STOPPED:
		// do something
		break;

	default:
		break;
	}
}

void app_uart_init()
{
	dev_uart = DEVICE_DT_GET(DT_NODELABEL(uart0));

	if (!device_is_ready(dev_uart))
	{
		return 0;
	}

	int err;
	err = uart_callback_set(dev_uart, uart_cb, NULL);
	if (err)
	{
		return err;
	}
	uart_rx_enable(dev_uart, uart_double_buffer[0], UART_BUF_SIZE, UART_RX_TIMEOUT_MS);
}

int main(void)
{
	app_uart_init();
}

and my prj.conf:

# nothing here
CONFIG_GPIO=y
CONFIG_SERIAL=y


CONFIG_LOG=y

CONFIG_UART_ASYNC_API=y
CONFIG_UART_0_ASYNC=y
CONFIG_UART_0_NRF_HW_ASYNC=y
CONFIG_UART_0_NRF_HW_ASYNC_TIMER=2
CONFIG_NRFX_TIMER2=y

See the logs below:

As you can see from the logs above, I have bunch of printf statements but that does not have any negative effect on receiving data. And yes, I am aware that using printf statements in callback itself is not a good practise, but that is just for testing purposes!

RE: nRF52DK nRF52832 UART asynchronous receive

Achim Kraus — Fri, 27 Oct 2023 17:21:42 GMT

> At this point, I am not sure how exactly uart_event.rx.len and uart_event.rx.offset works as it does not seem to show proper values once I change to second dual buffer.

I've tested with your example.

I understand now the irritation, I would consider it also as bug.

When the buffers are switched, it seems that only the first received byte is forwarded. And the others then with the next UART_RX_RDY. Looks like the number of available byte is calculated wrong, when the buffers are swapped.

Edited:

I've checked my "working example" and the difference in the "prj.conf" is

CONFIG_UART_0_ASYNC=y
CONFIG_UART_0_NRF_HW_ASYNC=y
CONFIG_UART_0_NRF_HW_ASYNC_TIMER=2
CONFIG_NRFX_TIMER2=y

with that, also your example works as you expect and the irritation is gone. :-).

RE: nRF52DK nRF52832 UART asynchronous receive

Achim Kraus — Fri, 27 Oct 2023 11:48:18 GMT

After checking the implementation in uart_nrfx_uart.c my understanding is, that the new buffer is already requested, when the first buffer is initially used or the buffers are actually swapped. Anyway, I guess, using something larger will help.

RE: nRF52DK nRF52832 UART asynchronous receive

Achim Kraus — Fri, 27 Oct 2023 11:42:27 GMT

The weird behaviour disappears, if you run my code with larger buffers ;-).

The point is, if you want a "seamless" DMA transfer in time, you need to request the buffers overlapping. I assume, that e.g. the new buffer is usually requested some bytes ahead (say 32) so that the app provides the new buffer and the DMA still uses the old. When the old is filled, the DMA switches very fast to the already provided new one.

But with 8 bytes, that's not working ;-).

RE: nRF52DK nRF52832 UART asynchronous receive

zazas321 — Fri, 27 Oct 2023 11:32:43 GMT

This issue is quite complex and it might not be obvious if you dont look at it close enough. The weird behaviour becomes very clear if you try to run the code and use debugger to monitor (evt->data.rx.len, evt->data.rx.offset and both uart buffers uart_double_buffer[0] and uart_double_buffer[1]

RE: nRF52DK nRF52832 UART asynchronous receive

Achim Kraus — Fri, 27 Oct 2023 11:29:56 GMT

I'm not sure, if the irritation you see is caused by a very short DMA buffer. I would try to use a larger ones. At least in my experience, the async UART works well. I use buffers with 256 bytes.

RE: nRF52DK nRF52832 UART asynchronous receive

Achim Kraus — Fri, 27 Oct 2023 11:22:24 GMT

Unfortunately this forum doesn't really allow to answer to a specific comment. My answer was for the comment 2 days ago with the red lines.

RE: nRF52DK nRF52832 UART asynchronous receive

Achim Kraus — Fri, 27 Oct 2023 11:19:17 GMT

> it does not seem to show proper values once I change to second dual buffer.

Maybe that's a misinterpretation of UART_RX_BUF_REQUEST and uart_rx_buf_rsp.

From the docu:

Provide pointer to RX buffer, which will be used when current buffer is filled.

It doesn't switch immediately after uart_rx_buf_rsp is called, but when the previous buffer is filled.

RE: nRF52DK nRF52832 UART asynchronous receive

zazas321 — Fri, 27 Oct 2023 11:16:35 GMT

Hello. What makes you think that my UART_RX_BUF_REQUEST is empty?

My UART_RX_BUF_REQUEST is as following:

	case UART_RX_BUF_REQUEST:
		uart_rx_buf_rsp(dev_uart, uart_buf_next, UART_BUF_SIZE);
		currently_active_buffer = !currently_active_buffer;
		if (currently_active_buffer == 0)
		{
			printf("currently active buffer is uart_double_buffer[0] \n");
		}
		else
		{
			printf("currently active buffer is uart_double_buffer[1] \n");
		}
		break;

And by debugging, I can see that it is switching the buffers as required. But the length and offset is still not correct.

If you have nrf52DK nRF52832 or nRF52840 NRF25840DK you can easily recreate the issue by using my code in main branch.

RE: nRF52DK nRF52832 UART asynchronous receive

Achim Kraus — Fri, 27 Oct 2023 11:12:32 GMT

Using empty UART_RX_BUF_REQUEST is causing the irritation. Once you implement the required callback uart_rx_buf_rsp, I guess the behavior will change.

RE: nRF52DK nRF52832 UART asynchronous receive

zazas321 — Fri, 27 Oct 2023 06:22:01 GMT

Thanks again for your insights. I understand what you said. I am determined to get to the bottom of this. Once we are done here, this can then become official Async UART sample project as there is currently no complete Async projects out there to look at. I am sure there are more people like myself who are confused about Async UART and how to get it to behave properly.

Lets dive a little deeper into this please. I have modified my Async UART program a little bit (removed unnecessary code) and I have added extra printf statements to see what is happening under the hood and I am slighty confused about how uart_event.rx works. In particular uart_event.rx.len and uart_event.rx.offset

Full code can be found below:

/*
 * Copyright (c) 2012-2014 Wind River Systems, Inc.
 *
 * SPDX-License-Identifier: Apache-2.0
 */

#include <zephyr/kernel.h>
#include <zephyr/drivers/gpio.h>
#include "stdio.h"
#include "my_gpio.h"
#include "zephyr/drivers/uart.h"
#include <zephyr/sys/ring_buffer.h>

#define LOG_LEVEL 4
#include <zephyr/logging/log.h>
LOG_MODULE_REGISTER(nrf52_learning);

#define UART_BUF_SIZE 8

#define UART_RX_TIMEOUT_MS 1000
K_SEM_DEFINE(rx_disabled, 0, 1);



// UART RX primary buffers
uint8_t uart_double_buffer[2][UART_BUF_SIZE];

uint8_t *uart_buf_next = uart_double_buffer[1];

uint8_t complete_message[UART_BUF_SIZE];
uint8_t complete_message_counter = 0;
bool currently_active_buffer = 1; // 0 - uart_double_buffer[0] is active, 1 - uart_double_buffer[1] is active



static const struct device *dev_uart;

static void uart_cb(const struct device *dev, struct uart_event *evt, void *user_data)
{

	switch (evt->type)
	{

	case UART_TX_DONE:
		printf("transmission complete \n");
		break;

	case UART_TX_ABORTED:
		// do something
		break;

	case UART_RX_RDY:

		printf("Received %i bytes \n", evt->data.rx.len);
		printf("Offset = %i  \n", evt->data.rx.offset);

		printf("evt->data.rx.buf: [");
		for (int i = 0; i < UART_BUF_SIZE; i++)
		{
			printf("%u, ", evt->data.rx.buf[i]);
		}
		printf("] \n");

		printf("uart_double_buffer[0]: [");
		for (int i = 0; i < UART_BUF_SIZE; i++)
		{
			printf("%u, ", uart_double_buffer[0][i]);
		}
		printf("] \n");

		printf("uart_double_buffer[1]: [");
		for (int i = 0; i < UART_BUF_SIZE; i++)
		{
			printf("%u, ", uart_double_buffer[1][i]);
		}
		printf("] \n");

		printf("Constructing a complete message \n");
			if (currently_active_buffer == 0)
		{
			// read all characters one by one till new line is found
			for (int i = 0 + evt->data.rx.offset; i < UART_BUF_SIZE; i++)
			{
				complete_message[complete_message_counter] = uart_double_buffer[0][i];
				complete_message_counter++;
				if (uart_double_buffer[0][i] == '\n')
				{
					printf("new line found at buffer 0 index = %i \n", i);
					complete_message_counter = 0;
					printf("complete_message = %s \n", complete_message);
					memset(&complete_message, 0, sizeof(complete_message)); // clear out the buffer to prepare for next read.
					break;
				}
			}
		}

		if (currently_active_buffer == 1)
		{
			// read all characters one by one till new line is found
			for (int i = 0 + evt->data.rx.offset; i < UART_BUF_SIZE; i++)
			{
				complete_message[complete_message_counter] = uart_double_buffer[1][i];
				complete_message_counter++;
				if (uart_double_buffer[1][i] == '\n')
				{
					printf("new line found at buffer 1 index = %i \n", i);
					complete_message_counter = 0;
					printf("complete_message = %s \n", complete_message);
					memset(&complete_message, 0, sizeof(complete_message)); // clear out the buffer to prepare for next read.
					break;
				}
			}
		}



		break;

	case UART_RX_BUF_REQUEST:
		uart_rx_buf_rsp(dev_uart, uart_buf_next, UART_BUF_SIZE);
		currently_active_buffer = !currently_active_buffer;
		if (currently_active_buffer == 0)
		{
			printf("currently active buffer is uart_double_buffer[0] \n");
		}
		else
		{
			printf("currently active buffer is uart_double_buffer[1] \n");
		}
		break;

	case UART_RX_BUF_RELEASED:
		printf("Old buffer has been released \n");
		uart_buf_next = evt->data.rx_buf.buf;
		break;

	case UART_RX_DISABLED:
		printf("rx disabled \n");
		k_sem_give(&rx_disabled);
		break;

	case UART_RX_STOPPED:
		// do something
		break;

	default:
		break;
	}
}

void app_uart_init()
{
	dev_uart = DEVICE_DT_GET(DT_NODELABEL(uart0));

	if (!device_is_ready(dev_uart))
	{
		return 0;
	}

	int err;
	err = uart_callback_set(dev_uart, uart_cb, NULL);
	if (err)
	{
		return err;
	}
	uart_rx_enable(dev_uart, uart_double_buffer[0], UART_BUF_SIZE, UART_RX_TIMEOUT_MS);
}

int main(void)
{
	app_uart_init();

}

and also my git repository (I updated main branch):

github.com/.../nrf52_learning

I will briefly explain the logic of my code:

I use uart_double_buffering and I have also created a new variable complete_message. I will be using combination of uart_double_buffering[0] (first buffer) and uart_double_buffering[1] (second buffer) to keep track of when the received message has rolled over as you have suggested.

I always keep track of currently active buffer by using variable currently_active_buffer.

In my UART_RX_RDY, I do the following:

	case UART_RX_RDY:

		printf("Received %i bytes \n", evt->data.rx.len);
		printf("Offset = %i  \n", evt->data.rx.offset);

		printf("evt->data.rx.buf: [");
		for (int i = 0; i < UART_BUF_SIZE; i++)
		{
			printf("%u, ", evt->data.rx.buf[i]);
		}
		printf("] \n");

		printf("uart_double_buffer[0]: [");
		for (int i = 0; i < UART_BUF_SIZE; i++)
		{
			printf("%u, ", uart_double_buffer[0][i]);
		}
		printf("] \n");

		printf("uart_double_buffer[1]: [");
		for (int i = 0; i < UART_BUF_SIZE; i++)
		{
			printf("%u, ", uart_double_buffer[1][i]);
		}
		printf("] \n");

		printf("Constructing a complete message \n");
		if (currently_active_buffer == 0)
		{
			// read all characters one by one till new line is found
			for (int i = 0 + evt->data.rx.offset; i < UART_BUF_SIZE; i++)
			{
				complete_message[complete_message_counter] = uart_double_buffer[0][i];
				complete_message_counter++;
				if (uart_double_buffer[0][i] == '\n')
				{
					printf("new line found at buffer 0 index = %i \n", i);
					complete_message_counter = 0;
					break;
				}
			}
		}

		if (currently_active_buffer == 1)
		{
			// read all characters one by one till new line is found
			for (int i = 0 + evt->data.rx.offset; i < UART_BUF_SIZE; i++)
			{
				complete_message[complete_message_counter] = uart_double_buffer[1][i];
				complete_message_counter++;
				if (uart_double_buffer[1][i] == '\n')
				{
					printf("new line found at buffer 1 index = %i \n", i);
					complete_message_counter = 0;
					break;
				}
			}
		}
		printf("complete_message = %s \n", complete_message);

		// memcpy(new_message.bytes, evt->data.rx.buf + evt->data.rx.offset, evt->data.rx.len);
		// new_message.length = evt->data.rx.len;
		// if (k_msgq_put(&uart_rx_msgq, &new_message, K_NO_WAIT) != 0)
		// {
		// 	printk("Error: Uart RX message queue full!\n");
		// }

		break;

As you can see from the code above, I looking for an endline termination to determine where is the end of the message. I also use the evt->data.rx.offset to ensure that I start reading from the last end line detected.

Please look at the logs below:

I think we are slowly but surely moving forwards to finding proper solution for this.

At this point, I am not sure how exactly uart_event.rx.len and uart_event.rx.offset works as it does not seem to show proper values once I change to second dual buffer.

I would highly appreciate if you could look at my code and the logs to see if you can make any sense out of it and understand what I am trying to achieve here 🙂

RE: nRF52DK nRF52832 UART asynchronous receive

AHaug — Thu, 26 Oct 2023 14:13:28 GMT

Hi,

[quote user="zazas321"]will no longer be correct as half of the message can be at the end of the evt->data.rx.buf and the rest rolled over to the beginning of the buffer. Then pretty much all other messages after the ring buffer has been filled will be trashed (thats exactly what we see from the logs) . Do you see what I mean? [/quote]

Yes, I see what you mean here. But the message is not trashed, you are simply starting to fill the other buffer (in the case of double buffer). What is missing here is some logic to determine if the complete message has been received and to combine the data from the two buffers into one. What you need to determine is among the following (could be other ways to do this as well, but this is at least one way to do it):

To determine the message has been completely transmitted (for instance if there is a termination on the final bit)
To determine if the message has been split, which is what you observe.
1. In this case you will need to combine the messages from both buffers, i.e find where the split message ends in the second buffer to combine the messages into one message

In Torbjørns sample (ncs 1.9.1), the one I linked to earlier, you will still have to do this combining of the message. To do this, it is typically normal to use a messaging protocol such as SLIP. SLIP uses what is called an end of frame to determine when this occurs. Instead/in addition to using a start-of-field and/or end-of-field, you can also use a length field in your data making sure that you wait until you've received all your data that consists of the complete message and then do the missing logic I've described to combine the message.

async UART coming in broken packets Is another case that somewhat describes the same thing as you see that briefly mentions what the other developer has done

[quote user="zazas321"]Please tell me if that makes sense or I am completely misunderstanding how this works or how this supposed to work.[/quote]

So to summarize: you've not misunderstood this, but we're rather missing some steps in the implementation to make the double buffering work properly and to combine the messages that starts in one buffer and ends in the other

Kind regards,
Andreas

RE: nRF52DK nRF52832 UART asynchronous receive

zazas321 — Thu, 26 Oct 2023 05:17:52 GMT

Thanks for your help. It is getting a little bit more clear, but I do not think my issues are related to the timeout. I really appreciate you taking your time to look into this!

However, I believe it is related to the way ring buffer works in Async UART.

I have increased UART_BUF_SIZE to 50, see the logs below:

What happens is that when I send messages via serial, the evt->data.rx.buf is slowly filling up. When it reaches the declared size (UART_BUF_SIZE), the condition:

memcpy(new_message.bytes, evt->data.rx.buf + evt->data.rx.offset, evt->data.rx.len);

will no longer be correct as half of the message can be at the end of the evt->data.rx.buf and the rest rolled over to the beginning of the buffer. Then pretty much all other messages after the ring buffer has been filled will be trashed (thats exactly what we see from the logs) . Do you see what I mean?

Zephyr states that Async UART is the most efficient way to use UART but I cannot see a single real world application where it could be used since it is not capable of receiving a full message properly (unless there is an issue in my code and below is not correct).

	case UART_RX_RDY:
		memcpy(new_message.bytes, evt->data.rx.buf + evt->data.rx.offset, evt->data.rx.len);
		new_message.length = evt->data.rx.len;
		if (k_msgq_put(&uart_rx_msgq, &new_message, K_NO_WAIT) != 0)
		{
			printk("Error: Uart RX message queue full!\n");
		}
		break;

Most UART applications relies on being able to receive and transmit a required size message length at once.

I was under the impression that the reason why we use double buffer is to avoid this problem and ensure that when the data rolled over, we can still get the full message at once but perhaps that is not the case.

Please tell me if that makes sense or I am completely misunderstanding how this works or how this supposed to work.

RE: nRF52DK nRF52832 UART asynchronous receive

AHaug — Wed, 25 Oct 2023 13:11:05 GMT

Thank you,

I finally had the time to look at your code. Apologies for why it took so long and to the frustration you must've felt. Response times gets a bit longer when we're nearing release of a new major version of the SDK (v2.5.0).

Your code works as expected when you're using asynch UART with static buffers (the central and peripheral_uart samples uses dynamically allocated buffers)

Why, you ask?
This is the quick and dirty explanation: The uart-cb triggers either when the timeout you've set runs out (100ms) or when the buffer you've declared (16 bit) is filled. When you enter new messages and you the timeout expires before you're finished writing the message, you will be left with a message that is separated. In theory if the timeout is sufficiently small and you match your writing speed with the timeout, the callback can trigger 16 times and separate the message into 16 characters instead of 1.

Hello (6) + ping (5) + message1 (expected to be 9) > 16: You see the callback trigger when both the timeout expires and the buffer length limit is reached

For further observation
Increase the timeout so you have time to write the new messages, and or play around with the buffer length (which is currently set to 16)

Please feel free to ask follow up questions if anything is unclear!

Kind regards,
Andreas

RE: nRF52DK nRF52832 UART asynchronous receive

zazas321 — Wed, 25 Oct 2023 08:52:19 GMT

You were right. It was private, my bad!

I have made it public now.

RE: nRF52DK nRF52832 UART asynchronous receive

AHaug — Wed, 25 Oct 2023 07:46:24 GMT

Hi,

It looks like the repo you've provided is private as the link takes me to a 404 and the nrf52_learning is not listed in your repositories. Could you make it public/share a public version of it?

Kind regards,
Andreas

RE: nRF52DK nRF52832 UART asynchronous receive

zazas321 — Wed, 25 Oct 2023 05:43:17 GMT

I have looked at the sample project you have provided. I have removed all the TX related code since I am not interested in TX (I only want to learn about RX first). The latest source code is available here:

https://github.com/krupis/nrf52_learning

I can confirm that it also does not work. Please look at the logs below:

I have underlined response in green where the response is correct and in red where the response is not as expected.

Could you please ask someone else from embedded software team from your side to look at this as this is getting a little frustrating?

Thanks for keeping this going!

RE: nRF52DK nRF52832 UART asynchronous receive

AHaug — Tue, 24 Oct 2023 10:57:33 GMT

Hi,

I did some more digging and found an older, unofficial sample created by someone in tech support showcasing how to use the Asynchronous UART Driver. Here's a version of the sample that should work in NCS v2.4.2

devzone.nordicsemi.com/.../ncs_2D00_uart_2D00_async_2D00_count_2D00_rx.zip

Kind regards,
Andreas

RE: nRF52DK nRF52832 UART asynchronous receive

zazas321 — Tue, 24 Oct 2023 06:46:26 GMT

I have tried to merge the echo_bot to the async uart sample but that is not as straight forward as it may look as it is using completely different functions.. I dont think it can be done this way.

I have posted on Zephyr Git as well as the Zephyr discord that you have recommended but there is no solution yet.. I am still waiting. If you have any more ideas let me know.

I will be sure to post back here the answer if someone replies on git or discord :)

RE: nRF52DK nRF52832 UART asynchronous receive

AHaug — Thu, 19 Oct 2023 12:47:33 GMT

Of course the echo_bot sample is what I should've suggested immediately 😆 That sample was not on my mind at all this morning!

But as you state there is a difference in using polling and the async method, and the lesson you started with from the academy course uses Async. Have you attempted to merge the lesson you started with, i.e https://academy.nordicsemi.com/courses/nrf-connect-sdk-fundamentals/lessons/lesson-4-serial-communication-uart/topic/uart-driver/, into the echo_bot?

PS: Unless you've already been recommended by users on the discord to create a ticket on the github, you can also find Zephyrs discord at zephyrproject.org, which might be an even easier way to communicate with other developers using Zephyr

Kind regards,
Andreas