Receiving data from UART via a peripheral device


I am working with a Nordic nrf52840dk using segge and sdk 16.

I am using the nordic UART example in examples/peripheral/uart.

The issue I am having is that my data being sent to this device can not be read from the nordic board.

Below is an example of the code going into my Putty terminal from my UART peripheral device.


This device has 4 wire connections RX,TX,CTS and RTS. My connections are listed below:

Note this is the default.

#define RX_PIN_NUMBER  8
#define TX_PIN_NUMBER  6
#define CTS_PIN_NUMBER 7
#define RTS_PIN_NUMBER 5

The first thing i tried was running the code with no change to see if app_uart_get(&cr) would pull this data. Unfortunately it did not. It does however, pull data that i type into the terminal.

What I want to do is to take this data from the UART(Sensor data) and store it as a variable for handling later on.

I which to know how I can pull this data from the serial connection.

Side note when the device (UART) is plugged in printing from putty does not run. If I unplug the device then printing works fine.  Below is my main code (from example).

int main(void)
    uint32_t err_code;


    const app_uart_comm_params_t comm_params =
#if defined (UARTE_PRESENT)
#if defined (UART_PRESENT)



    printf("\r\nUART example started.\r\n");

    while (true)
        uint8_t cr;
        while (app_uart_get(&cr) != NRF_SUCCESS);
        while (app_uart_put(cr) != NRF_SUCCESS);

        if (cr == 'q' || cr == 'Q')
            printf(" \r\nExit!\r\n");

            while (true)
                // Do nothing.

    // This part of the example is just for testing the loopback .
    while (true)

  • Hi,

    It is not entirely clear to me, but the serial terminal on the PC is via the onboard debugger, right (USB connector on the left of the board)? If you are using that (or have the debugger enabled in general so that IF OFF is not asserted, then you should use different pins for the external UART device. In other words, connect the UART pins between the nRF and another device to some available GPIO pins, and update the pin number defines.

  • Thanks for your response, I am using the onboard usb connector (the one in the top-middle of the board). This is where my putty serial terminal connects to. Jlink CDC UART PORT(COM5)

    I have tried redefining the pinouts to:

    #define RX_PIN_NUMBER  NRF_GPIO_PIN_MAP(0,3)//8
    #define TX_PIN_NUMBER  NRF_GPIO_PIN_MAP(0,28)//6
    #define CTS_PIN_NUMBER NRF_GPIO_PIN_MAP(0,4)//7
    #define RTS_PIN_NUMBER NRF_GPIO_PIN_MAP(0,29)//5

    I have then connected my device to those pinout.

    However, I now no longer see that information (from the uart device) to putty, nor can I use a printf command and see the result.

    When I  run this through the dubugger after running the APP_UART_FIFO_INIT and checking the error code it goes to NRF_BREAKPOINT_COND;

    I then get this in the call stack area of the debugger.

    What other details do you need to help resolve this issue?

  • 0x0000000000004001.

    Also how does it tell me what the error is? I don't have an error code lookup table.

  • #define NRF_FAULT_ID_SDK_ERROR       (NRF_FAULT_ID_SDK_RANGE_START + 1) /**< An error stemming from a call to @ref APP_ERROR_CHECK or @ref APP_ERROR_CHECK_BOOL. The info parameter is a pointer to an @ref error_info_t variable. */

  • Yes, that is correct. If you test the debug build you should see a sensible message in the log, and if there is problems with the logging you can inspect the info struct yourself. I think you will find An introduction to error handling in nRF5 projects useful.

  • Ok I'll have a detailed look through. But, I've stepped through the code when the error is thrown and I can not identify why it occurs. It goes from this:


    to this:

    app_error_fault_handler(NRF_FAULT_ID_SDK_ERROR, 0, (uint32_t)(&error_info));

    This then runs to NRF_BREAKPOINT_COND

  • Hi Einar,

    Thanks for the help, I've gotten my solution to work now, Just wanted to thank you for the support it really helped a lot.

Reply Children