UART communication with external sensor + USB debug

[JClarky]

Hi

I am new to the nRF52832 + nRF Connect and have recently purchased the nRF52 DK. Sorry if this is a simple question, but I want some clarification.

I have an external device connected to the nRF52 DK UART port, as it requires serial communication for AT commands. I can receive data from this external device without a problem, but it doesn't seem to receive anything I transmit.

From my understanding, the nRF52832 only has one UART (UART0), also used for USB debugging. If so, is there an arrangement that can be made so I still receive logs/debugs from the nRF chip while utilising the only available UART for the external device? I am just concerned that with my current arrangement, the external device is not receiving the commands as the USB is receiving them. 

Maybe this is obvious, but any guidance would be appreciated.

Thanks,

Jayden

[Einar Thorsrud]

Hi,

As long as you have a Segger debugger attached you can do logging via RTT, avoiding using the UART for this. See Logging in nRF Connect SDK.

[JClarky]

Hi Einar,

Thanks, I did try this; however, I no longer had any communication with the external device.

Can you clarify the prj.conf to enable RTT logging but use UART for device connection?

Is it fine to use the default UART ports, or should I change these?

Once again, I tried both of the above and lost all communication, so I'd love some clarification to ensure I implemented it correctly.

Thanks

[Einar Thorsrud]

Hi,

In principle, all you need to do to use RTT instead of UART for logging is to add this to your prj.conf:

CONFIG_USE_SEGGER_RTT=y
CONFIG_RTT_CONSOLE=y
CONFIG_UART_CONSOLE=n

If that does not work we need to look more into your project. Particularily when you write y ou lost all communication, what does that mean exactly? What type of communication and how? If refering to the UART, which API are you usingfor that  and how is it configured?

In addition to details on that, it could be interesting to look at the generated .config in your build folder with and without RTT logging to understand which configs you are using in both caes.

[JClarky]

Hi,

Thanks for clarifying; this worked as expected, but there was still no communication with the module.

My project involves connecting a SIMCOM 7080G  to the nRF52 DK, where communication to the module is done over the UART protocol. The SIMCOM module is powered externally, but both share a common ground. This SIMCOM kit supports 3.3V logic. It has auto-bauding, but I find it works best at 9600, which is configured in the overlay file. Currently, my goal is to establish a simple "AT OK" response. 

In saying I lost all communication, I meant that previously, I could receive data from the SIMCOM (not transmit) over UART, but once I used RTT, I could no longer receive anything from the SIMCOM over UART. I have tried reestablishing this previous communication state, but for some reason, I cannot, so now I have no response/data from the module over UART.

Connections to the SIMCOM are as follows:

SIMCOM - nRF52 DK

TX - P0.08 (I have also tried using P0.10, reconfiguring in overlay)

RX - P0.06 (I have also tried using P0.09, reconfiguring in overlay)

GND - GND

PWR_KEY - P0.12

This is the current prj.conf:

CONFIG_USE_SEGGER_RTT=y
CONFIG_RTT_CONSOLE=y
CONFIG_UART_CONSOLE=n

CONFIG_SERIAL=y
CONFIG_UART_ASYNC_API=y

This is the current main.c file, not fully developed, but should at least print anything that is received.

#include <zephyr/kernel.h>
#include <zephyr/drivers/uart.h>
#include <zephyr/drivers/gpio.h>
#include <hal/nrf_gpio.h>
#include <zephyr/sys/printk.h>

// Communication to SIMCOM 7080G chip using UART

const struct device *uart = DEVICE_DT_GET(DT_NODELABEL(uart0));

#define PWR_PIN         NRF_GPIO_PIN_MAP(0, 12)

#define RECEIVE_BUFF_SIZE 100
#define RECEIVE_TIMEOUT 100
static uint8_t rx_buf[RECEIVE_BUFF_SIZE] = {0};
static uint8_t tx_buf[] =  {"AT\r\n"};


static void uart_callback(const struct device *dev, struct uart_event *evt, void *user_data)
{
	switch (evt->type) {
	
	case UART_TX_DONE:
		printk("AT Send Success\n");
		break;

	case UART_TX_ABORTED:
		printk("AT Send Abort\n");
		break;
		
	case UART_RX_RDY:
        printk("REC:%s\n", evt->data.rx.buf);
        //evt->rx.buf[rx.offset] to evt->rx.buf[rx.offset+rx.len]
		//printk(evt->data.rx.len);
		break;
		
	case UART_RX_DISABLED:
		uart_rx_enable(dev, rx_buf, sizeof(rx_buf), RECEIVE_TIMEOUT);
		break;
		
	default:
		break;
	}
}


int main(void)
{
    printk("<------------------ Welcome to the test ------------------>\n");

    nrf_gpio_cfg_output(PWR_PIN);

    // Check UART is ready
    if (!device_is_ready(uart)) {
        printk("UART NOT READY\n");
        return 0;
    }

    // Set UART callback
    int ret = uart_callback_set(uart, uart_callback, NULL);
    if (ret) {
        printk("Call back set error\n");
        return 1;
    }

    
    // Enable RX 
    ret = uart_rx_enable(uart, rx_buf, sizeof(rx_buf), RECEIVE_TIMEOUT);
    if (ret) {
        printk("RX enable error\n");
    }

    // Main comm loop
    int attempt = 0;
	while (1) 
    {
        // Restart the chip if 10 attempts have been made to contact
        if(attempt == 10)
        {
            printk("REBOOTING CHIP\n");
            nrf_gpio_pin_set(PWR_PIN);
            k_msleep(1200);
            nrf_gpio_pin_clear(PWR_PIN);
            printk("REBOOTED\n");
            attempt = 0;
        }

        // Send tx_buf to module
        printk("Trying to contact by sending AT...\n");
        if (uart_tx(uart, tx_buf, sizeof(tx_buf), SYS_FOREVER_US)) {
            printk("ERROR TRANSMITTING\n");
        }
        
        attempt++;
		k_msleep(1000);
	}
}

[Einar Thorsrud]

Hi,

I see. I do not see anything obviously wrong here. Have you had a look at the Bluetooth: Peripheral UART sample? That is relevant here as it use both the UART for something application specific and RTT for logging. Perhaps by reviewing it you will be able to spot a difference from what you are doing?

[JClarky]

Thanks, Einar

I moved the SIMCOM to a new breadboard with new jumpers, triple-checking all connections, and now it works.

No idea what the exact issue was, but thanks heaps for your help.