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]

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.

[jfDEVmoto]

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.

[Petter Myhre]

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

[jfDEVmoto]

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.

[jfDEVmoto]

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.