app_uart_get more than 1 byte

[Caner Celiktas]

Hi,

I'm using app_uart for communication between different mcu. I can send more than 1 byte like "0x3917015623"  through  changing tx_buffer[0] to tx_buffer[5]. Unfortunately i couldn't recieve the slave devicess message "0x2917013607". I can only get the first byte "0x07". My configuration are the same as uart example. How can i recieve all the message ?. I tried to use serial library but i couldn't initialize. (It gave ERROR 6 NRF_ERROR_NOT_SUPPORTED).

Slave device is sending me a message every second. And i'm calling app_uart_get function every 500 miliseconds.

Here is my uart init;

void uart_error_handle(app_uart_evt_t * p_event)
{
    if (p_event->evt_type == APP_UART_COMMUNICATION_ERROR)
    {
        APP_ERROR_HANDLER(p_event->data.error_communication);
    }
    else if (p_event->evt_type == APP_UART_FIFO_ERROR)
    {
        APP_ERROR_HANDLER(p_event->data.error_code);
    }    
}

void uart_init(void)
{
    uint32_t err_code;
    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 (UART_PRESENT)
            NRF_UART_BAUDRATE_115200
  #else
            NRF_UARTE_BAUDRATE_9600
  #endif
        };
//    const app_uart_buffers_t m_buffers =
//      {
//        &rx_buffer_s,
//        sizeof(rx_buffer_s),
//        &tx_buffer_s,
//        sizeof(tx_buffer_s)
//      }
      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);
//      err_code = app_uart_init(&comm_params, &m_buffers, uart_error_handle, APP_IRQ_PRIORITY_LOW);
//      APP_ERROR_CHECK(err_code);
  
}

Regards,

[bjorn-spockeli]

I tried to use serial library but i couldn't initialize. (It gave ERROR 6 NRF_ERROR_NOT_SUPPORTED).

 Which function returned NRF_ERROR_NOT_SUPPORTED?

[Caner Celiktas]

nrf_serial_init function was returning NRF_ERROR_NOT_SUPPORTED. I fixed that error yesterday. I did a lot of things. I couldn't remember exactly but i remember that i changed some code in nrf_serial.c . Now, i can send 5 byte data on TX_PIN  but i received wrong data from slave. Also i am using MAX485 IC for communication. I need to set RTS_PIN before sending operation and clear it before receive operation. But nrf_gpio_pin_set or nrf_gpio_pin_clear command doesn't effect the RTS_PIN. When i deactive UART module then these command are starting to work. When UART module enabled, RTS_PIN goes high at wrong time and out of my control. Time between sending operation and RTS_PIN high is about 95 ms. It should be at the same time. So how can i control RTS pin while UART Module enabled.(I can control other gpio when uart enabled.)

here is my serial init code:

NRF_SERIAL_DRV_UART_CONFIG_DEF(m_uart0_drv_config,
                      RX_PIN_NUMBER, TX_PIN_NUMBER,
                      RTS_PIN_NUMBER, CTS_PIN_NUMBER,
                      NRF_UART_HWFC_ENABLED, NRF_UART_PARITY_EXCLUDED,
                      NRF_UART_BAUDRATE_9600,
                      UART_DEFAULT_CONFIG_IRQ_PRIORITY);

#define SERIAL_FIFO_TX_SIZE 32
#define SERIAL_FIFO_RX_SIZE 32

NRF_SERIAL_QUEUES_DEF(serial_queues, SERIAL_FIFO_TX_SIZE, SERIAL_FIFO_RX_SIZE);

#define SERIAL_BUFF_TX_SIZE 5
#define SERIAL_BUFF_RX_SIZE 5

NRF_SERIAL_BUFFERS_DEF(serial_buffs, SERIAL_BUFF_TX_SIZE, SERIAL_BUFF_RX_SIZE);

NRF_SERIAL_CONFIG_DEF(serial_config, NRF_SERIAL_MODE_IRQ,
                      &serial_queues, &serial_buffs, NULL, NULL);


NRF_SERIAL_UART_DEF(serial_uart, 0);

    ret_code_t ret;
//    ret = nrf_drv_clock_init();
//    APP_ERROR_CHECK(ret);
//    ret = nrf_drv_power_init(NULL);
//    APP_ERROR_CHECK(ret);

    nrf_drv_clock_lfclk_request(NULL);
    ret = app_timer_init();
    APP_ERROR_CHECK(ret);
    
    ret = nrf_serial_init(&serial_uart, &m_uart0_drv_config, &serial_config);
    APP_ERROR_CHECK(ret);

[Caner Celiktas]

I am using nrf52810. I disabled HWFC and now i can send and recieve the message. But i got some mistakes on receiving part. The message i should take is "0xAAAA011729"

Message is 5 bytes, "AAAA" is changing always.

What i received :

<info> app: Received data : 1172978

<info> app: Received data : 17297748

<info> app: Received data : 29764901

<info> app: Received data : 754A0117

<info> app: Received data : 4B011729

<info> app: Received data : 1172974

<info> app: Received data : 1729734C

<info> app: Received data : 17724D01

The message is true but not in same order. I am using uint32_t variable for recieve operation. I used uint64_t but nothing changed it still got wrong order. I think i must clear rx_buffer after receiving.

[bjorn-spockeli]

Do you have the possibility to capture the data on the UART lines using a logic analyzer? That would help us identify if the data is sent correctly on the data lines but received incorrectly by the nRF52810.

[Caner Celiktas]

I solved the message order problem. It should be  an array with 5 elements, Now i have another problem. I can communicate between two nrf board correctly there is no problem for now. There is a problem with receiving data from other mcu. I can send data to PIC16f1788 but i can't receive correct data. There is no problem between nrf to nrf  or pic to pic and also nrf to pic. But when nrf is receiver and pic is transmitter, nrf is not taking correct data. The signal must be same on Rx and Tx.

Here is the signals on PIC16F1788 Tx pin :

Here is the nrf Rx pin :

[bjorn-spockeli]

This is without HWFC right? The waveforms look completly identical, except the TX line being initially low on the first capture, but high on the second. If this is measured at the TX pin of the PIC and the RX pin of the NRF, then the captures should be identical as you say. You do not get any UART events on the nRF side when the PIC is transmitting?

[Caner Celiktas]

Hi, Bjorn !

bjorn-spockeli said:

This is without HWFC right?

Yes, HWFC is disabled. I am not in the office until Monday but last time when i tested code, i set a breakpoint on nrf_serial_read function. It returns error code 13. I think it means Timed out error. I couldn't find solution for that. And secondly, 2 leds connected to rx and tx pin on nrf. These 2 leds are turned off when no transmitting status. When message comes on tx or rx pins, related led blinks a short time. Communication between nrf to nrf works fine, leds are blinking while transmitting. When i unplug the transmitter nrf (slave) and plug the other slave (PIC16F1788), the led on receiver line stays turned on. I can give more information on Monday.

[bjorn-spockeli]

Yes, error code 13( decimal ) is NRF_ERROR_TIMEOUT. 

Ok, will wait for the update from you. 

Best regards

Bjørn

[Caner Celiktas]

I pretty solved the rx pin problem. I started to use the SN65HVD72 IC instead of MAX485.  I can receive the message but NRF_ERROR_TIMEOUT error very offen happens. I changed nrf_serial_read function's time out parameters but didn't helped. My transmitter send a byte 0 to 255. Here is the outputs of receiver side  (I print first return code in decimal, secondly received data):

<info> app: Recieved error : 0

<info> app: Recieved data : 54

<info> app: Recieved error : 0

<info> app: Recieved data : 55

<info> app: Recieved error : 0

<info> app: Recieved data : 56

<info> app: Recieved error : 0

<info> app: Recieved data : 57

<info> app: Recieved error : 13

<info> app: Recieved data : 253

<info> app: Recieved error : 0

<info> app: Recieved data : 60

<info> app: Recieved error : 13

<info> app: Recieved data : 253

<info> app: Recieved error : 13

<info> app: Recieved data : 253

<info> app: Recieved error : 13

<info> app: Recieved data : 253

<info> app: Recieved error : 13

<info> app: Recieved data : 253

<info> app: Recieved error : 13

<info> app: Recieved data : 253

<info> app: Recieved error : 0

<info> app: Recieved data : 66

<info> app: Recieved error : 13

<info> app: Recieved data : 253

<info> app: Recieved error : 13

<info> app: Recieved data : 253

<info> app: Recieved error : 13

<info> app: Recieved data : 253

<info> app: Recieved error : 0

<info> app: Recieved data : 70

<info> app: Recieved error : 0

<info> app: Recieved data : 71

<info> app: Recieved error : 13

<info> app: Recieved data : 253

<info> app: Recieved error : 0

<info> app: Recieved data : 74

<info> app: Recieved error : 13

<info> app: Recieved data : 253

<info> app: Recieved error : 13

<info> app: Recieved data : 253

<info> app: Recieved error : 13

<info> app: Recieved data : 253

<info> app: Recieved error : 0

<info> app: Recieved data : 78

<info> app: Recieved error : 0

<info> app: Recieved data : 79

<info> app: Recieved error : 0

<info> app: Recieved data : 80

<info> app: Recieved error : 13

<info> app: Recieved data : 253

<info> app: Recieved error : 13

<info> app: Recieved data : 253

<info> app: Recieved error : 13

<info> app: Recieved data : 253

<info> app: Recieved error : 13

<info> app: Recieved data : 253

<info> app: Recieved error : 13

<info> app: Recieved data : 253

<info> app: Recieved error : 0

<info> app: Recieved data : 86

<info> app: Recieved error : 0

<info> app: Recieved data : 87

<info> app: Recieved error : 0

<info> app: Recieved data : 88

<info> app: Recieved error : 0

<info> app: Recieved data : 89

<info> app: Recieved error : 0

<info> app: Recieved data : 90

<info> app: Recieved error : 0

<info> app: Recieved data : 91

<info> app: Recieved error : 13

<info> app: Recieved data : 253

<info> app: Recieved error : 13

<info> app: Recieved data : 253

<info> app: Recieved error : 13

<info> app: Recieved data : 253

<info> app: Recieved error : 13

<info> app: Recieved data : 253

<info> app: Recieved error : 0

<info> app: Recieved data : 97

<info> app: Recieved error : 0

<info> app: Recieved data : 98

<info> app: Recieved error : 0

<info> app: Recieved data : 99

<info> app: Recieved error : 13

<info> app: Recieved data : 253

<info> app: Recieved error : 13

<info> app: Recieved data : 253

<info> app: Recieved error : 0

<info> app: Recieved data : 102

<info> app: Recieved error : 13

<info> app: Recieved data : 253

<info> app: Recieved error : 0

<info> app: Recieved data : 104

<info> app: Recieved error : 0

<info> app: Recieved data : 105

[bjorn-spockeli]

What are you passing as the timeout_ms value when you call nrf_serial_read?

/**
 * @brief Function for reading from a serial port.
 *
 * @param p_serial   Serial port instance.
 * @param p_data     Receive buffer pointer.
 * @param size       Receive buffer size.
 * @param p_read     Amount of data actually read from the serial port.
 *                   NULL pointer can be passed.
 * @param timeout_ms Operation timeout, in milliseconds. Pass 0 to operate in
 *                   non blocking mode.
 *
 * @return Standard error code.
 * */
ret_code_t nrf_serial_read(nrf_serial_t const * p_serial,
                           void * p_data,
                           size_t size,
                           size_t * p_read,
                           uint32_t timeout_ms);

[Caner Celiktas]

uint32_t err_code;

err_code = nrf_serial_read(&serial_uart, &rx_message, sizeof(rx_message), NULL, 10);
NRF_LOG_INFO("Recieved error : %d \n",err_code);
if(err_code == 13)
{
  ret = nrf_serial_uninit(&serial_uart);
  APP_ERROR_CHECK(ret);
  nrf_delay_ms(10);
  ret = nrf_serial_init(&serial_uart, &m_uart0_drv_config, &serial_config);
  APP_ERROR_CHECK(ret);

}
(void)nrf_serial_flush(&serial_uart, 0);
if(rx_message[3]>0)
    NRF_LOG_INFO("Recieved data : %d \n", rx_message[3]);
    
rx_message[3] = rx_data;
our_rx_characteristic_update(&m_our_service, &rx_data);
err_code = 0;

I call this function each second. When i connected the Board via BLE, frequency of errors is increasing.

[bjorn-spockeli]

Hi Mehmet, 

the SoftDevice( i.e. BLE protocol stack) has the highest priority so whenever there is a BLE event, then the SoftDevice will preempt any application code, see Interrupt priority levels in the SoftDevice Specification. 

So the fact that you see timeouts when there is BLE activity is to be expected as the SoftDevice will get priority over the application UART code. It is possible to schedule application code around the BLE events using the Timeslot API, see Concurrent multiprotocol implementation using the Radio Timeslot API

Best regards

Bjørn