UART priority

RE: UART priority

Petter Myhre — Tue, 01 Nov 2016 12:02:27 GMT

Great that you found a workaround. I agree. This was actually fixed in the SDK 12.0.0.

RE: UART priority

jfDEVmoto — Mon, 31 Oct 2016 15:26:54 GMT

I finally tested the higher UART priority and I got rid of those com errors.

So of course, I have to change my application architecture to send my notifs out of my uart handler, which may include some latency in my system but this might not be highly critical to manage. I am not using any SDK scheduler so maybe I will take this into consideration.

If I may, in the file app_util_platform.h, the IRQ levels definitions are quite confusing

#ifdef SOFTDEVICE_PRESENT
    APP_IRQ_PRIORITY_HIGHEST = _PRIO_SD_HIGH,
#else
    APP_IRQ_PRIORITY_HIGHEST = _PRIO_APP_HIGH,
#endif
    APP_IRQ_PRIORITY_HIGH    = _PRIO_APP_HIGH,

one may think that when soft device is present, the highest prio level to be used without damage would be _PRIO_SD_HIGH and _PRIO_APP_HIGH when no sot device is present. Looking t the values, shows that this is not the case. If no soft device is present, the priority level 0 would then never be used. why ? Correct me if I am wrong, but here, HIGHEST must not be used at all when SD is present. Which is quite confusing. I understand there might be good reasons for this and collaterals would not allow to change it easily, but my logic would have written those defs as follows. Don't you agree ?

#ifdef SOFTDEVICE_PRESENT
    APP_IRQ_PRIORITY_HIGHEST = _PRIO_APP_HIGH, 
#else
    APP_IRQ_PRIORITY_HIGHEST = _PRIO_SD_HIGH, 
#endif
    APP_IRQ_PRIORITY_HIGH    = _PRIO_APP_HIGH,

Whatever, thanks a lot for the support.

RE: UART priority

jfDEVmoto — Mon, 31 Oct 2016 12:46:38 GMT

OK, thanks, this is what I suspected. Then If I want to test UART with higherpriority I will have to review some stuff in my architecture. Do you think it is worth ? would I then get rid of my uart errors ? can you confirm the performance gap comes from SD long reads ? By the way, the issue might not be baudrate related but time between bytes related, so I suspect it to be different between device PC based emulator and real device...not tested yet.

RE: UART priority

Petter Myhre — Mon, 31 Oct 2016 11:36:03 GMT

You cannot call sd_* functions from interrupt context 1. See this.

RE: UART priority

jfDEVmoto — Sun, 30 Oct 2016 15:45:54 GMT

about the Uart priority, I can check that when using _PRIO_APP_HIGH, then the function sd_ble_gatts_hvx would never return. I call this function from my UART receive handler, usually when the last expected byte was received and no other transfert is ongoing. I will try to send my notifications from another handler.

RE: UART priority

jfDEVmoto — Sat, 29 Oct 2016 19:05:06 GMT

I will check deeper the priority thing, thanks for the link. I have no control over the other device and baudrate choice. I can afford loosing data as far as my state machine flags it, but of course, this may affect my overall system performance. However, I have not flagged in my handler that I do some bytewise treatment, not much heavy but with a few function jumps to my state machine. I have to check whether this is a problem or not while this handler has low priority regarding soft device. On the SD side, I also have some memcopies to the characteristic, and maybe the lack of performance comes from here rather than on the long read. In any case, if I can overcome this issue, and when I have checked that my code path are not too heavy, this is not a good sign for the performance of my system that should support more traffic in the future. I must say I also have TWI, with another device, so I am afraid I will get such problems as well.

RE: UART priority

Petter Myhre — Fri, 28 Oct 2016 12:46:27 GMT

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?

RE: UART priority

jfDEVmoto — Thu, 27 Oct 2016 11:45:17 GMT

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...)

RE: UART priority

jfDEVmoto — Thu, 27 Oct 2016 10:45:48 GMT

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;
}
}

RE: UART priority

Petter Myhre — Thu, 27 Oct 2016 08:54:41 GMT

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?

RE: UART priority

jfDEVmoto — Wed, 26 Oct 2016 17:16:17 GMT

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.