• State Verified Answer
  • Locked Locked
  • Replies 11 replies
  • Subscribers 73 subscribers
  • Views 6063 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 117354
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

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.

Parents
  • 0

    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.

Reply
  • 0

    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.

Children
Related
Terms of service