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

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 Reply
  • 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.

Children
No Data
Related