UART between nrf9160 and nrf52840 on custom board only working for nrf52-nrf91

Question

Hi!

I have a custom board based mostly of the nrf9160DK, where I need communication between nrf52849 and nrf9160 processor.

I have used the code from this ticket that Simon provided in a zip-file uart.zip.

Since it is a custom board I have changed the overlay-files to configure to different pins.

The code is working for for sending from the nrf52 to nrf91 but not in opposite direction (nrf91 to nrf52), and i can't grasp why only one direction.

The nrf9160_pca10090ns.overlay is set to:

&uart2 {
	current-speed = <115200>;
	status = "okay";
	tx-pin = <29>;
	rx-pin = <28>;
	rts-pin = <27>;
	cts-pin = <26>;
};

with the prj.conf file:

CONFIG_SERIAL=y
#CONFIG_TRUSTED_EXECUTION_NONSECURE=y
CONFIG_UART_INTERRUPT_DRIVEN=y
#CONFIG_MAIN_STACK_SIZE=4096
CONFIG_DEBUG_OPTIMIZATIONS=y

CONFIG_SPI_2=n
CONFIG_I2C_2=n
CONFIG_UART_2_NRF_UARTE=y


CONFIG_UART_2_NRF_FLOW_CONTROL=y

# J-TAG DEBUG
CONFIG_USE_SEGGER_RTT=y

And the nrf52840 are based on pca10056 board so the nrf52840_pca10056.overlay is:

&uart1 {
	current-speed = <115200>;
	status = "okay";
	tx-pin = <27>;
	rx-pin = <14>;
	rts-pin = <15>;
	cts-pin = <5>;
};

with the prj.conf:

CONFIG_SERIAL=y
#CONFIG_TRUSTED_EXECUTION_NONSECURE=y
CONFIG_UART_INTERRUPT_DRIVEN=y
#CONFIG_MAIN_STACK_SIZE=4096

#CONFIG_BOARD_PCA10090_INTERFACE0_MCU=y
#CONFIG_BOARD_PCA10090_INTERFACE1_MCU=y
CONFIG_UART_1_NRF_UARTE=y

#CONFIG_UART_1_NRF_FLOW_CONTROL=y
CONFIG_UART_1_NRF_FLOW_CONTROL=n

# J-TAG DEBUG 
CONFIG_USE_SEGGER_RTT=y

I removed the config for interface0 and 1 since it based of a pca10056 board.

Can it be because the overlay of nrf9160 are using the same pins as default for uart0?

Is it a problem that VCOM1 is "non-configurable" accoridng to docs here.

main.c is exactly the same as the example from the ticket so it looks like this:

#include <zephyr.h>
#include <sys/printk.h>
#include <drivers/uart.h>
#include <string.h>
#include "SEGGER_RTT.h"

static u8_t uart_buf[1024];

static struct device *uart_dev; //Figure out why you should/should not use static


int send_data(const u8_t *buf, size_t size)
{
	//printk("size of output_buffer: %d\n", size);
	if (size == 0) {
		return 0;
	}
	for(int i = 0; i < size; i++){
		//printk("Writing %c on position %d\n", buf[i], i);
		uart_poll_out(uart_dev, buf[i]);
	}

	return 0;
}

void uart_cb(struct device *x)
{
	uart_irq_update(x);
	int data_length = 0;

	if (uart_irq_rx_ready(x)) {
		data_length = uart_fifo_read(x, uart_buf, sizeof(uart_buf));
		uart_buf[data_length] = 0;
	}
	printk("%s", uart_buf);
	SEGGER_RTT_WriteString(0, uart_buf);

}

void main(void)
{
	
	char hey[] = "hey from 9160\n";
	
	uart_dev = device_get_binding("UART_2");
        if (!uart_dev) {
          printk("Could not get UART 2\n");
	}
	uart_irq_callback_set(uart_dev, uart_cb);
	uart_irq_rx_enable(uart_dev);
	printk("UART 9160 [3] start!\n");
	
	while (1) {
		send_data(hey, sizeof(hey));
		k_sleep(1000);
	}
}

Can you please help me understand where the issue might occur that it is only sending from nrf52 and recieving on nrf91?

Kind regards, Ellinor

Einar Thorsrud · Accepted Answer

Hi Ellinor, 
 It seems odd UART communication works in one direction. Have you checked with a logic analyzer on the UART line to see if data is transmitted, even though not received? If so it would also be interesting to measure close to the nRF52 to see if there could be a issue with the physical connection. 
 Can it be because the overlay of nrf9160 are using the same pins as default for uart0? 
 If you are using the nrf9160dk_nrf9160 board file (as it seems), then yes. You could either use delete-property or disable uart0 in your overlay, or perhaps more cleanly, make a new board file for your custom board (see Out Of Tree Board sample ). 
 Is it a problem that VCOM1 is "non-configurable" accoridng to docs here . 
 No, that is related to how the signals are routed on the DK, and should not be relevant for your custom board.

UART between nrf9160 and nrf52840 on custom board only working for nrf52->nrf91

Top Replies