UART priority

[jfDEVmoto]

Hello, I am facing many communication error with code 1 when using the UART. Everything is working fine until my client reads long characteristics (in my case it is about 110 bytes long) from the server. The read is fine on the Soft device side but on the server side that is streaming on the uart, I get those com errors. If I understand correctly, this error code means that I don't consume the bytes fast enough. As I use a quite long FIFO of 512 and my UART frames are 102 bytes, I guess, the error code comes from the hardware block so the fifo implementation is useless. (I use the app_uart_fifo.c code) I tried to use higher interrupt priority in the APP_UART_FIFO_INIT but this completely prevents the soft device to operate correctly (this is strange because the priority levels that are defined seem to allow SD coexistence).

What I alos notice is that the APP_UART_TX_EMPTY is fired twice each time I use the dus_data_handler to send my 102 bytes : for (i = 0; i < length; i++) { while(app_uart_put(p_data[i]) != NRF_SUCCESS); }

Is it normal to get those 2 events ? Is it normal to have issues when serving long charactersitics on the BLE ? Is there a way to monitor such reads so that I can handle it in my state machine. Is it normal that other IRQ priorities than LOW prevent correct operation ?

I use 57600 bauds, soft device 130 2.0.0 in SDK11 with nRF51422

Thanks for your help.

[jfDEVmoto]

It seems that SDK 11 contains the bug explained herein as a response to another issue. This may explain the two APP_UART_TX_EMPTY ? Was this bug confirmed ? devzone.nordicsemi.com/.../

I tested the fix and as a matter of fact the second notif is no more received. I will test further whether overall stability is improved or not, but for sure I still do have priority issues with COM error 1 when serving long reads on BLE side.

[Petter Myhre]

Where do you get the error? On the nRF51? From what function? So you have a peripheral with a server, you are sending 102 bytes frames over UART to it, this normally works, but not when the central/client does a long read on it? Are you using flow control? What happens when you use higher interrupt priority?

[jfDEVmoto]

I get com error on the NRF51 side in the uat receive handler : (here is a simplified version) I am not using flow control because my UART device does not support it. When I use a higher interrupt, my application simply won't start.

void uart_event_handle(app_uart_evt_t * p_event)
{
        switch (p_event->evt_type)
      {
        case APP_UART_DATA_READY:
            //the normal byte receive path
               break;
case APP_UART_COMMUNICATION_ERROR:
            //evt_type 2 /**< An communication error has occured during reception. The error is 
            //stored     in app_uart_evt_t.data.error_communication field. */
            
            LOG_UART_COM_ERROR(p_event->data.error_communication);
            
            //mostly log code 1
            //the error_communication code 1 seems to be due to slow byte flush , they mostly occur 
           //when serving long reads on BLE);      
            break;
        case APP_UART_TX_EMPTY:
            //evt_type 3    /**< An event indicating that UART has completed transmission of all 
           //available    data in the TX FIFO.
break;
default:
break;
}
}

[jfDEVmoto]

more precisely , if I use priority highest, the application would hiccup upon startup. If I use high, it would crash after a few exchanges (don't know where exactly, I am not good for embedded code debugging, strugglin with RTT...)

[Petter Myhre]

I think you have understood the error code correctly. You cannot use _PRIO_SD_HIGH (0), but _PRIO_APP_HIGH (1) might work, it crashes? Or do you get a reset? See this for more info. Can you decrease the baud rate? Do you have any control over the device on the other side of the UART? Or is is just sending data whenever? Is it critical not to loose any data?