peripheral_uart crashes using fifo's for ble transmission in nrf connect sdk 1.8.0

[shiva74638]

hi, i am using ncs 1.8.0 for an application where i need to send some data every 10 ms. directly sending data over NUS with bt_nus_send() from the main thread works fine. but when i try to send data through exiting ble_write_thread by putting data into fifo_uart_rx_data results in these warnings in the log and skips a lot of data to be sent to the receiver.

[00:00:43.284,240] <wrn> bt_att: No ATT channel for MTU 16520
[00:00:43.284,240] <wrn> bt_gatt: No buffer available to send notification
[00:00:43.284,271] <wrn> peripheral_uart: Failed to send data over BLE connection
[00:00:43.294,250] <wrn> bt_att: No ATT channel for MTU 16520
[00:00:43.294,250] <wrn> bt_gatt: No buffer available to send notification
[00:00:43.294,281] <wrn> peripheral_uart: Failed to send data over BLE connection
[00:00:43.314,270] <wrn> bt_att: No ATT channel for MTU 16520
[00:00:43.314,270] <wrn> bt_gatt: No buffer available to send notification
[00:00:43.314,300] <wrn> peripheral_uart: Failed to send data over BLE connection

using ble_write_thread also works fine for larger intervals of time. only problem is when i set the interval to 10 ms it crashes likes this.

i have incresed the mtu size and heap size also but it did not show any considerable change.

these are the changes i made in prj.conf

#incresing the mtu size
CONFIG_BT_L2CAP_TX_MTU=240
CONFIG_BT_BUF_ACL_RX_SIZE=240

#thread naming
CONFIG_THREAD_NAME=y
#increasing the heap size
CONFIG_HEAP_MEM_POOL_SIZE=4096

any advice on how to get this correct.

thanks in advance.

[shiva74638]

i am sorry. it is my code causing the error. i was not checking whether the memory is allocated or not before pushing to the fifo. and the data and length given to bt_nus_send() being a garbage values resulted in this behaviour.
after setting a while loop to repeat allocating until the memory is allocated the code works fine. but i am not sure this is the way to go here. any advice is appreciated. 
i have incresed the stacksize of the concerned data sending thread but doesn't seem to be doing anything much. am i missing anything here?

[Simonr]

Hi

Glad to hear you figured out the reason for the initial crash! I think you should make sure the memory is "ready" before the application starts transmitting data, I think it would be best to wait for a READY EVENT of some kind, which it kind of sounds like you already do.

Best regards,

Simon

[shiva74638]

Hi Simon,
thanks for your reply. After some testing the problem boiled down to one thing. If I allocate some memory and call bt_nus_send() in the same thread it doesn't run out of memory and works without a glitch at any rate of transmission. But if I allocate memory in one thread and pass it through FIFO's (which according zephyr documentation doesn't add any delay) and call bt_nus_send() from another thread, then the memory doesn't get freed in time and new memory allocation becomes difficult. (i have also tested the application with different priority levels for allocating and sending threads).

Can you explain why it is happening like this.

Is it correct to conclude that FIFO's might have some delay while passing data. If so what method do you suggest to pass data faster between different threads?

[Simonr]

Hi

Looking at the documentation of FIFO, it doesn't seem to mention specifically "no added delay": https://docs.zephyrproject.org/latest/reference/kernel/data_passing/fifos.html 

"A data item may be added to a FIFO by a thread or an ISR. The item is given directly to a waiting thread, if one exists; otherwise the item is added to the FIFO’s queue. There is no limit to the number of items that may be queued.

A data item may be removed from a FIFO by a thread. If the FIFO’s queue is empty a thread may choose to wait for a data item to be given. Any number of threads may wait on an empty FIFO simultaneously. When a data item is added, it is given to the highest priority thread that has waited longest."

One thing could be unaligned memory access, as FIFO data items must be aligned on a word boundary, as the kernel reserves the first word of an item for use as a pointer to the next data item in the queue.

Best regards,

Simon