nRF5_3.2.0 examples ble_app_uart & ble_app_uart_c data size limitation

[Nicholas P.]

I am experimenting with ble_app_uart & ble_app_uart_c using two terminal windows, and I am sending a string of 1000 chars from the central to the device.

Although they are functioning for small strings, they both get stuck on an 1000 char string.

I increased the RT/TX UART buffer sizes on both sides to 4096 (they do not even run if I try more), but still both crash on the first attempt.

Is there an explanation for this?

Is there a solution?

[Einar Thorsrud]

Hi,

Can you double check with SDK version you are using? The first version that got production support for nRF52840 was nRF5 SDK 15.0.0. Could it be that you are using an SDK for BLE mesh or similar? If so, is that intentional or by accident? Generally I would recommend using the latest SDK 17.1 if using nRF5 SDK, and for any new project you should consider the nRF Connect SDK.

That said, when you write getting stuck, can you elaborate on what that means? How do you test and wha have you learned by debugging? What do you see from the log?

[Nicholas P.]

Thank you for responding....

1. SDK: I searched the whole SDK for any 'SDK' occurrence, and there was not anything. The name of the directory is nRF5_SDK_3.2.0. I have been warned not to try and use anything else, because it will be incompatible with the project.

2. Mesh. I am sure it has nothing to do with the mesh. There examples are one device, one central, both with a UART terminal interface. So when I open to terminal windows, any ascii string I type into one, appears into the other and vise-versa. And the message travels via BLE. Once I manage to send files of up to 10k from the central to the terminal, I shall apply the changes of the terminal into my nRF52840 application, and use the central example as a utility.

3. So I have two terminals open, connected to two Leard DVK-BL654-1.0 boards. One for Central, and one for Device. I can type small strings in either terminal, and they appear in the other. When I compose some text of about 1000 chars, consisting of 20 strings followed by CR/LF, then the Device crashes before after receiving part of it, and the central also reboots.

4. Both projects have RX/TX buffers == 256 bytes each. I redefined them to 4096. The performance did not change.

5. The library: Bellow is the path withing the library, where I found them.

nRF52840\nRF5_SDK_3.2.0\examples\ble_peripheral\ble_app_uart

nRF52840\nRF5_SDK_3.2.0\examples\ble_central\ble_app_uart_c

I hope the above are familiar. Let me know what you think.

The general question is: If I need to send a file of 10k from the central to the peripheral in one go, is this possible, or does it have to be done in small chanks?

If it can be sent in one chank, I need to find out where I need to intervene, in order to make it possible. Some pointers would help.

[Einar Thorsrud]

Hi,

Can you upload an unmodified file from the SDK (preferably a fairly large C file) so that I can use that to try to establish roughly which SDK version you have?

Secondly, can you let me know more about what happens when you write "they both get stuck"? What debugging have you done, and what have you learned from that? Where is it "stuck" and what state are the devices in?

[Nicholas P.]

The above shows what happens when I send a long string. The terminal on the left is on the central. The terminal on the right is on the device. In the left, The central, after apparently transmitting the block of strings, it rebooted. On the right, the device displays the four strings it received. After this, the device became unresponsive, i.e. i.e. it was not possible either to receive, or send short strings.

Above is an example where both devices send and receive short strings to each other, in any order. Again, the central terminal is on the right, and the device on the left.

Question: Should BLE be able to send a continuous block of data, or does it have to be managed in small packets?

4375.ble_app_uart.zip

The above is the complete BLE device example..

Regards,

    Nicholas

[Nicholas P.]

I have instrumented the code with printfs on both sides, and it is becoming a bit clearer. As seen on the left side, the central transmits 5 lines, and then hangs. On the right, the device receives 5 lines, and then reports that the connection was disconnected. So far, it looks like the problem is in the central.

[Nicholas P.]

Enabled UART flow control, and it look good! Seems to work. Will do further testing.

[Nicholas P.]

I tried sending an ascii file of 1024 lines, each line with a 32 bin decimal ascii number terminated by CR,LF and it worked. Will do further testing.

[Nicholas P.]

I consider this ticket closed.