Unable to receive full data over BLE

RE: Unable to receive full data over BLE

Bjørn Kvaale — Fri, 24 Nov 2017 11:33:53 GMT

I agree with endnode that you definitely should not use malloc/realloc & instead use a global static buffer. @jj Also, have you tried to use a sniffer yet like Torsten suggests below? Do you know how many packets your nrf52 receives?

RE: Unable to receive full data over BLE

Bjørn Kvaale — Wed, 22 Nov 2017 12:40:05 GMT

Would you mind sending me your code in a private message?

RE: Unable to receive full data over BLE

jj — Fri, 17 Nov 2017 01:46:47 GMT

Hi, it is still not working. Any suggestions?

RE: Unable to receive full data over BLE

Bjørn Kvaale — Wed, 15 Nov 2017 12:12:31 GMT

Hi jj, what is the status of this issue? Have you figured it out or is it still not working?

RE: Unable to receive full data over BLE

jj — Fri, 10 Nov 2017 01:07:30 GMT

I changed the data to transmit over, which now consist of 536 characters. Currently, up till total_len of 480, Nordic is able to receive all of the data at buf and print out at SEGGER_RTT. But once it receives the next round of data (total_len of 500), printing buf will only contain the data up till 429th character. Subsequently, buf will always print out 0-429th character only. This is really strange, as it did managed to receive more than 429 previously and stored in buf, but all of a sudden those data disappear and only 0-429th characters remain. This happens for both static and dynamic buffer allocation.

RE: Unable to receive full data over BLE

endnode — Thu, 09 Nov 2017 10:07:42 GMT

Oh then I'm sorry that I've promised quick fix, it looks like some deeper bug completely unrelated to the way how you store/handle bytes in this part of your code. Are you sure that if you perform single connection and single transfer that the issue persists and it's exactly at the 430th character regardless of buffer allocation method (static or dynamic)? This would be very very strange.

RE: Unable to receive full data over BLE

jj — Thu, 09 Nov 2017 09:46:41 GMT

Thank you for the help. I tried what you suggested and is still encountering the same error. I made another strall buffer as I intend to manipulate the data received from BLE, and I am afraid there may be new data coming in when I am dealing with the original packet (resulting in strall to be the new data instead of the original one). As for the condition 123, the sending party put that as the indication of the end of the packet, hence in Nordic I am checking for it to know whether it receives the whole data. I changed size_t to uint32_t as well.

RE: Unable to receive full data over BLE

endnode — Thu, 09 Nov 2017 07:15:49 GMT

Yes, I mean static uint8_t buf[1000] at the beginning of your main.c file instead of uint8_t *buf = NULL;. You can set it by memset once after the boot. Also your strall buffer would need similar treatment, but to be honest I don't know why you just don't cast and use reference to buf instead of making another large buffer. Finally I don't see how you get the data to the buffer and why there is this magic condition with 123 but I trust you know what to do there. Oh and one more: why you use size_t and not some reasonable integer like uint32_t for indexes and lengths? Maybe cosmetics, maybe not (depending on how size_t gets recognized during linking after pre-processing all the macros and defines...)

Maybe I will sound snobbish now but ARM Cortex-M isn't windows machine with x64 core and unlimited resources, coding it like C++ on Win isn't the best idea.

RE: Unable to receive full data over BLE

jj — Thu, 09 Nov 2017 01:50:42 GMT

May i know what you mean by global static 1kb buffer? I tried changing declaration to 'uint8_t buf[1000]' but it is still not working even after I removed all malloc/realloc.

RE: Unable to receive full data over BLE

Torsten Robitzki — Wed, 08 Nov 2017 14:36:54 GMT

Yes, that would be long read/writes then. But you would have to write them in parts too and in addition, you would have an addional parameter (the position in the characteristic) that would reduce the usable length to 18.

RE: Unable to receive full data over BLE

endnode — Wed, 08 Nov 2017 14:29:01 GMT

And to complete: ATT_MTU is maximum for Notifications and Indications but as far as I understand GATT Value can be longer (up to 512B) and independent on ATT_MTU size. You should be then able to use Read and/or Write methods to work with them in parts.

RE: Unable to receive full data over BLE

Torsten Robitzki — Wed, 08 Nov 2017 14:24:17 GMT

Are you sure, that, whatever you use on the GATT client side, does not swallow writes? Have you used a sniffer?

BTW: 20 is just the minimum (MTU-3). Right after a connection is established, client and server negotiate a value that might be larger.

RE: Unable to receive full data over BLE

Torsten Robitzki — Wed, 08 Nov 2017 14:19:37 GMT

At least add a check for the result of realloc() and malloc() to be sure that this is not a heap fragmentation problem.

RE: Unable to receive full data over BLE

endnode — Wed, 08 Nov 2017 11:22:55 GMT

Stop using malloc/realloc and similar crap and just create global static 1kB buffer. Your problem will be most probably (magically) solved;)