UART isue

RE: UART isue

Hakon — Sun, 06 Feb 2022 13:32:41 GMT

[quote user="vitaliy-f"]1. How did you connect to the board? Was it using regular USB cable?[/quote]

Yes, the J-Link interface USB.

[quote user="vitaliy-f"]2. What is the state of the switches on your board?[/quote]

I believe it should be visible from the picture. Let me know if it's not clear.

[quote user="vitaliy-f"]3. Which OS & driver are you using?[/quote]

I run Linux from a virtual machine, using a windows 10 host and bridging the COM port. The driver should be the J-Link CDC driver for windows.

RE: UART isue

Vitaliy Freidovich — Fri, 04 Feb 2022 14:21:21 GMT

OK, this is great!

Now we can try to figure out the difference in the environments -
1. How did you connect to the board? Was it using regular USB cable?

2. What is the state of the switches on your board?

3. Which OS & driver are you using?

RE: UART isue

Hakon — Fri, 04 Feb 2022 13:36:49 GMT

Yes, it looks fine. This is what I get

This is from the code you sent. It is different from the serial output you first posted though, but I don't get any errors and the data is echoed as expected.

RE: UART isue

Vitaliy Freidovich — Fri, 04 Feb 2022 10:19:23 GMT

Hi, any update on this one?

RE: UART isue

Vitaliy Freidovich — Sun, 30 Jan 2022 15:40:28 GMT

Hi again and thanks for trying to reproduce this!

Yes, you're right - as I wrote above - I first modified the ncs/zephyr/dts/arm/nordic/nrf52833.dtsi file directly for testing purposes, and thanks for pointing me out that I should have created an overlay file instead, I was not aware of that.

In any case this is not relevant anymore, as I reverted this change to the original state, as I saw that it makes no impact on the UART issue I'm experieincing.

So to summarize - you will have an identical environment to mine without any modifications to the ncs/zephyr/dts/arm/nordic/nrf52833.dtsi file, or additional overlay files.

I hope this is clear, and thanks again for helping me out!

RE: UART isue

Hakon — Sun, 30 Jan 2022 15:27:52 GMT

But as you said earlier

[quote user=""]I have modified the nrf25833,dtsi file to contain the following uart&lpuart sections:[/quote]

Did you modify the dts file directly, instead of writing the changes to an overlay file? The dts file is not supposed to be modified directly. It might not matter at all, but I just want to make sure I have your exact setup before I proceed.

RE: UART isue

Vitaliy Freidovich — Fri, 28 Jan 2022 17:56:05 GMT

Yes, it's the only overlay file that I have, and you're right, I think it's not even used by the IDE (Visual Studio Code).

RE: UART isue

Hakon — Thu, 27 Jan 2022 14:35:53 GMT

[quote user="vitaliy-f"]rv32m1_vega_ri5cy.overlay:[/quote]

Is this the correct file? It's not for the nrf52833 board, and you don't include the uart configurations here.

RE: UART isue

Hakon — Thu, 27 Jan 2022 14:11:27 GMT

Thank you, I'll have a look.

RE: UART isue

Vitaliy Freidovich — Wed, 26 Jan 2022 15:00:01 GMT

Sure!

Here's the source code:
.

#include <zephyr.h>
#include <device.h>
#include <drivers/uart.h>

#include <string.h>

/* change this to any other UART peripheral if desired */
#define UART_DEVICE_NODE DT_CHOSEN(zephyr_shell_uart)

#define MSG_SIZE 32

/* queue to store up to 10 messages (aligned to 4-byte boundary) */
K_MSGQ_DEFINE(uart_msgq, MSG_SIZE, 10, 4);

static const struct device *uart_dev = DEVICE_DT_GET(UART_DEVICE_NODE);

/* receive buffer used in UART ISR callback */
static char rx_buf[MSG_SIZE];
static int rx_buf_pos;

/*
 * Read characters from UART until line end is detected. Afterwards push the
 * data to the message queue.
 */
void serial_cb(const struct device *dev, void *user_data)
{
	uint8_t c;

	if (!uart_irq_update(uart_dev)) {
		return;
	}

	while (uart_irq_rx_ready(uart_dev)) {

		uart_fifo_read(uart_dev, &c, 1);

		if ((c == '\n' || c == '\r') && rx_buf_pos > 0) {
			/* terminate string */
			rx_buf[rx_buf_pos] = '\0';

			/* if queue is full, message is silently dropped */
			k_msgq_put(&uart_msgq, &rx_buf, K_NO_WAIT);

			/* reset the buffer (it was copied to the msgq) */
			rx_buf_pos = 0;
		} else if (rx_buf_pos < (sizeof(rx_buf) - 1)) {
			rx_buf[rx_buf_pos++] = c;
		}
		/* else: characters beyond buffer size are dropped */
	}
}

/*
 * Print a null-terminated string character by character to the UART interface
 */
void print_uart(char *buf)
{
	int msg_len = strlen(buf);

	for (int i = 0; i < msg_len; i++) {
		uart_poll_out(uart_dev, buf[i]);
	}
}

void main(void)
{
	char tx_buf[MSG_SIZE];

	if (!device_is_ready(uart_dev)) {
		printk("UART device not found!");
		return;
	}

	/* configure interrupt and callback to receive data */
	uart_irq_callback_user_data_set(uart_dev, serial_cb, NULL);
	uart_irq_rx_enable(uart_dev);

	print_uart("Hello! I'm your echo bot.\r\n");
	print_uart("Tell me something and press enter:\r\n");

	/* indefinitely wait for input from the user */
	while (k_msgq_get(&uart_msgq, &tx_buf, K_FOREVER) == 0) {
		print_uart("Echo: ");
		print_uart(tx_buf);
		print_uart("\r\n");
	}
}

prj.conf:

CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=4096

# BT configuration 
CONFIG_BT=y
CONFIG_BT_DEBUG_LOG=y
CONFIG_BT_SMP=y
CONFIG_BT_SIGNING=y
CONFIG_BT_PERIPHERAL=y
CONFIG_BT_DIS=n
CONFIG_BT_ATT_PREPARE_COUNT=5
CONFIG_BT_BAS=n
CONFIG_BT_HRS=n
CONFIG_BT_PRIVACY=y
CONFIG_BT_DEVICE_NAME="AAA"
CONFIG_BT_DEVICE_APPEARANCE=833
CONFIG_BT_DEVICE_NAME_DYNAMIC=y
CONFIG_BT_DEVICE_NAME_MAX=128
CONFIG_BT_KEYS_OVERWRITE_OLDEST=y
CONFIG_BT_SETTINGS=y
CONFIG_BT_L2CAP_TX_MTU=252
CONFIG_BT_BUF_ACL_RX_SIZE=256

CONFIG_FLASH=y
CONFIG_FLASH_PAGE_LAYOUT=y
CONFIG_FLASH_MAP=y
CONFIG_NVS=y
CONFIG_SETTINGS=y

CONFIG_PRINTK=y
CONFIG_LOG_PRINTK=y
CONFIG_LOG=y
CONFIG_LOG_MODE_IMMEDIATE=y
CONFIG_LOG_MAX_LEVEL=4
CONFIG_USE_SEGGER_RTT=y
CONFIG_RTT_CONSOLE=y
CONFIG_UART_CONSOLE=y

CONFIG_BOOTLOADER_MCUBOOT=y
CONFIG_SECURE_BOOT=y
CONFIG_MCUMGR=y
CONFIG_MCUMGR_CMD_OS_MGMT=y
CONFIG_MCUMGR_CMD_IMG_MGMT=y
CONFIG_MCUMGR_SMP_BT=y
CONFIG_MCUMGR_SMP_BT_AUTHEN=n

CONFIG_IMG_MANAGER=y

CONFIG_NRFX_TEMP=y

CONFIG_SERIAL=y
CONFIG_UART_INTERRUPT_DRIVEN=y
CONFIG_UART_USE_RUNTIME_CONFIGURE=y
CONFIG_USB_CDC_ACM=n

rv32m1_vega_ri5cy.overlay:

/*
 * Copyright 2019 NXP
 *
 * SPDX-License-Identifier: Apache-2.0
 */

&lptmr1 {
	interrupt-parent = <&intmux0_ch2>;
};

&intmux0_ch2 {
	status = "okay";
};

&intmux0_ch3 {
	status = "okay";
};

&generic_fsk {
	interrupt-parent = <&intmux0_ch3>;
	status = "okay";
};

Please let me know how it behaves for you and what you see.

Thanks!

RE: UART isue

Hakon — Fri, 21 Jan 2022 15:33:40 GMT

I can try to reproduce the issue with an nrf52833 DK. Can you include the entire project here including prj.conf and overlays?

RE: UART isue

Vitaliy Freidovich — Tue, 18 Jan 2022 13:12:35 GMT

Hi,

Any thoughts on this one?

How would you recommend to proceed?

Thanks!

RE: UART isue

Vitaliy Freidovich — Thu, 13 Jan 2022 18:29:33 GMT

I tried picocom with the same parameters, no change in results 😞

How would you advise to proceed?

RE: UART isue

Krzysztof Chruscinski — Thu, 13 Jan 2022 13:53:31 GMT

i'm using picocom, no flow control:

picocom --omap delbs -b 115200 /dev/tty0

Unfortunately, i don't have nrf52833dk to check.

RE: UART isue

Vitaliy Freidovich — Thu, 13 Jan 2022 12:54:47 GMT

- Nordic DK

- Clean zephyr repo

Are you using minicom?

Have you configured anything special?

Flow control or anything else?

Any other thoughts?

RE: UART isue

Krzysztof Chruscinski — Thu, 13 Jan 2022 12:51:29 GMT

Are you having a custom board or Nordic DK? I've been trying this zephyr sample on nrf52840dk and it works fine. Was it clean zephyr repo or with some modifications?

RE: UART isue

Vitaliy Freidovich — Wed, 12 Jan 2022 17:28:19 GMT

Hi!
I tried this example!
Similar results 😞

RE: UART isue

Krzysztof Chruscinski — Tue, 11 Jan 2022 15:21:39 GMT

Just recently an uart sample got merged to zephyr upstream. You can try to run it to see if it's working.

github.com/.../41575

RE: UART isue

Vitaliy Freidovich — Tue, 11 Jan 2022 14:58:31 GMT

You're right!
So now we need to figure out why the reception is corrupt.

Any ideas?

RE: UART isue

Krzysztof Chruscinski — Tue, 11 Jan 2022 14:49:24 GMT

Standard uart is not documented in nRF Connect SDK because it is part of zephyr. Lpuart implements the same interface so the only change is device that is used.

Now, when i looked at the code you provided, i realized that you are actually using standard UART device. In device tree overlay you configure lpuart on top of UART_1 device but in the code snippet you are using UART_0 (device_get_binding("UART_0")).

Though, not sure why reception is corrupted.

RE: UART isue

Vitaliy Freidovich — Tue, 11 Jan 2022 14:37:35 GMT

Additionally, correct me if I'm wrong, if it would have been an issue with CTS/RTS I would have received no data at all. Here it seems like a flow control / driver issue.What do you think? Perhaps it needs to be configured differently?

RE: UART isue

Vitaliy Freidovich — Tue, 11 Jan 2022 13:47:57 GMT

Thanks for your response. I understand from the documentation here https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/drivers/uart_nrf_sw_lpuart.html that LPUART supersedes regular UART, and provides the same communication API & protocol above the HW level.

If this is not the case, can you please point me to documentation regarding using regular UART in the nRF Connect SDK?
I have not found any reference to regular UART and thought that LPUART is the way to implement UART now.
I'm not using nRF5 SDK so libuarte and the similar will not work for me.

Thanks!

RE: UART isue

Krzysztof Chruscinski — Tue, 11 Jan 2022 13:33:57 GMT

Hi,

lpuart can only be used with another instance of lpuart on the other side. It implements 2 pin control protocol which replaces CTS/RTS and allows receiver to go to sleep in idle.

You need standard UART with or without flow control in that case.