Receiving data from UART via a peripheral device

Hi

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.

1,1183,1,1169
1,1183,1,1169
1,1183,1,1169
1,1183,1,1169
1,1183,1,1169
1,1183,1,1169

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;

    bsp_board_init(BSP_INIT_LEDS);

    const app_uart_comm_params_t comm_params =
      {
          RX_PIN_NUMBER,
          TX_PIN_NUMBER,
          RTS_PIN_NUMBER,
          CTS_PIN_NUMBER,
          UART_HWFC,
          false,
#if defined (UARTE_PRESENT)
          NRF_UARTE_BAUDRATE_115200
#else
          NRF_UARTE_BAUDRATE_115200
#endif
/*
#if defined (UART_PRESENT)
          NRF_UART_BAUDRATE_115200
#else
          NRF_UARTE_BAUDRATE_115200
#endif
*/
      };

    APP_UART_FIFO_INIT(&comm_params,
                         UART_RX_BUF_SIZE,
                         UART_TX_BUF_SIZE,
                         uart_error_handle,
                         APP_IRQ_PRIORITY_HIGH,
                         //APP_IRQ_PRIORITY_LOWEST,
                         err_code);

    APP_ERROR_CHECK(err_code);

#ifndef ENABLE_LOOPBACK_TEST
    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.
            }
        }
    }
#else

    // This part of the example is just for testing the loopback .
    while (true)
    {
        uart_loopback_test();
    }
#endif
}

Parents
  • 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?

  • I've tried your code an unfortunately I can not get it to work.

    //Pin definitions for the UART board
    #define RX_PIN_NUMBER  NRF_GPIO_PIN_MAP(0,26)//8
    #define TX_PIN_NUMBER  NRF_GPIO_PIN_MAP(0,27)//6
    #define CTS_PIN_NUMBER NRF_GPIO_PIN_MAP(0,28)//7
    #define RTS_PIN_NUMBER NRF_GPIO_PIN_MAP(0,29)//5

    Once again it gets to the app_uart_get line and does not go through the while loop.

    Here is an image of my hardware setup.

    Also I read in the documentation that for high data rates high drive might be needed. Could this be the issue?

    Also don't know if it will help but, here is my CPU current context:

  • Hi,

    That's strange. I cannot see if the individual pins are correct from the photo, but the pin configuration is the same as I used with the code from my previous post. Can you try to set breakpoints at both line 129 and line 130 and see? Does it still not move between them?

  • The pinouts are : RX 26, TX 27, Cts 28 and Rts 29. 

    Also no it does not move between lines 129 and 130. It breaks at 129, then when i let the breakpoint go nothing happens.

  • What is the data coming out of your UART device and going into the nordic board, is it a similar format to my data (shown above ASCII data). As my data is received with \r\n at the end not sure if that is an issue. Also what are your specific pin outs? Just to remove as much variance as possible. Also what configuration settings do I need in my sdk_config.h I've not changed anything but, want to double check.

    Also did you use the NRF52840 for you test?

  • Hi,

    I tested on the nRF52840 DK with an unmodified sdk_config.h from the example and a slightly modified pca10056.h (see the diff below).

    diff --git a/components/boards/pca10056.h b/components/boards/pca10056.h
    index 8689dc0..ec9ec2f 100644
    --- a/components/boards/pca10056.h
    +++ b/components/boards/pca10056.h
    @@ -84,10 +84,10 @@ extern "C" {
     #define BSP_BUTTON_2   BUTTON_3
     #define BSP_BUTTON_3   BUTTON_4
    
    -#define RX_PIN_NUMBER  8
    -#define TX_PIN_NUMBER  6
    -#define CTS_PIN_NUMBER 7
    -#define RTS_PIN_NUMBER 5
    +#define RX_PIN_NUMBER  26
    +#define TX_PIN_NUMBER  27
    +#define CTS_PIN_NUMBER 28
    +#define RTS_PIN_NUMBER 29
     #define HWFC           true
    
     #define BSP_QSPI_SCK_PIN   19

    The data I tested was just a counter character followed by \r\n, so three bytes all in all. But it should not matter that much, other than this simple example does not handle what happens when the buffer overflows. It is just intended as a simple example to be tested with a debugger using breakpoints.

    Since the SW should be good, there are just two things left that I can think of as potential problems:

    • Is the voltage of the UART signal sensible? It should ideally be VDD for 1, and 0 V for 0 (though you have some slack, as specified under GPIO Electrical Specification.
    • Could it be that you have mixed the signals and swapped the Rx and Tx wires by a mistake?
Reply
  • Hi,

    I tested on the nRF52840 DK with an unmodified sdk_config.h from the example and a slightly modified pca10056.h (see the diff below).

    diff --git a/components/boards/pca10056.h b/components/boards/pca10056.h
    index 8689dc0..ec9ec2f 100644
    --- a/components/boards/pca10056.h
    +++ b/components/boards/pca10056.h
    @@ -84,10 +84,10 @@ extern "C" {
     #define BSP_BUTTON_2   BUTTON_3
     #define BSP_BUTTON_3   BUTTON_4
    
    -#define RX_PIN_NUMBER  8
    -#define TX_PIN_NUMBER  6
    -#define CTS_PIN_NUMBER 7
    -#define RTS_PIN_NUMBER 5
    +#define RX_PIN_NUMBER  26
    +#define TX_PIN_NUMBER  27
    +#define CTS_PIN_NUMBER 28
    +#define RTS_PIN_NUMBER 29
     #define HWFC           true
    
     #define BSP_QSPI_SCK_PIN   19

    The data I tested was just a counter character followed by \r\n, so three bytes all in all. But it should not matter that much, other than this simple example does not handle what happens when the buffer overflows. It is just intended as a simple example to be tested with a debugger using breakpoints.

    Since the SW should be good, there are just two things left that I can think of as potential problems:

    • Is the voltage of the UART signal sensible? It should ideally be VDD for 1, and 0 V for 0 (though you have some slack, as specified under GPIO Electrical Specification.
    • Could it be that you have mixed the signals and swapped the Rx and Tx wires by a mistake?
Children
  • H Einar,

    For some reason today when I run it I get an error NRF_BREAKPOINT_COND.

    The following comment is the system can only recover with a reset.

    I've tried checked the wiring of the device today and it seems correct.

    It may have been an issue wiring yestarday as when i remove the uart wires it loops on the app_uart_get.

    Before it stops working it goes into app_error_handler

    void app_error_handler(ret_code_t error_code, uint32_t line_num, const uint8_t * p_file_name)
    {
        __ASM volatile(
    

  • The error I receive is APP_UART_COMMUNICATION_ERROR error code: 0x2003fe84

  • Happens from:

    APP_UART_FIFO_INIT(&comm_params,
                             UART_RX_BUF_SIZE,
                             UART_TX_BUF_SIZE,
                             uart_error_handle,
                             APP_IRQ_PRIORITY_LOWEST,
                             err_code);
    
        APP_ERROR_CHECK(err_code);

  • Also the code only crashes when I debug with the RX pin connected. (RX in the code). Otherwise it just enters the while statement and never leaves.

  • That is odd.

    The error APP_UART_COMMUNICATION_ERROR is only set in a few places, so I am guessing it comes from line 111 in components\libraries\uart\app_uart_fifo.c. What is app_uart_event.data.error_communication set to? That holds the ERRORSRC register, and should tell you what happened. (APP_UART_FIFO_INIT() sets up buffers and call app_uart_init(), so you can also set a breakpoint in app_uart_init() in components\libraries\uart\app_uart_fifo.c and stepping from there.)

    If the error is FRAMING, then it could be worth-while starting the HF crystal oscillator. If you send long sequences of UART data with a high baud rate, then this is usually needed. Note that this should not be related to the original problem though (where you neither get any data nor any error). In this simple example that does not use the SoftDevice you can do that by simply calling this code at the beginning of main:

    NRF_CLOCK->EVENTS_HFCLKSTARTED = 0;
    NRF_CLOCK->TASKS_HFCLKSTART    = 1;
    
    /* Wait for the external oscillator to start up */
    while (NRF_CLOCK->EVENTS_HFCLKSTARTED == 0)
    {
        // Do nothing.
    }

Related