Forced disconnections when i try to send 50 bytes per second on UART example

[sotillo2409]

Hi everyone,

Explaning my project: an external device transmit via UART to nordik nrf52840DK device with UART peripheal firmware, this is connected to another nrf52840DK via BLE with UART central firmware.

So the peripheal is only working as bridge.

It simply works when i send less than 10 bytes per second, but when I increase the amount of data to more than 30bytes per second i get disconnexions of my peripheal when passed 20-40 seconds. 

I tink that it could be an overload of the UART or an overload of BLE, here my conn_params:

Here the error of disconnection: Disconnected: <log_strdup alloc failed> (reason 8)

Really the objective of the project is send 50-100 bytes every 100msec.

What point i need to check or reconfigure to achieve it??

Thank you,

regards.

[Einar Thorsrud]

Hi,

Disconnect reason -8 is timeout, so it would be interesting to know what happened on the other device, as it seemingly stopped maintaining the connection. Can you try to debug on the nRF that did not get the -8 disconnect, and see what happened there? Perhaps you did not properly handle full buffers, and that lead to a APP_ERROR_CHECK being hit, or similar?

[sotillo2409]

Hi, looking it better the Disconnect reason -8 is coming of the central Device, so i will try to debug peripheal to see which is the reasson of it disconnection

[sotillo2409]

Okay, i debug it and the peripheal is rebooting unexpectedly on random times, don't have a patron fixed, maybe peripheal have sended 20 messages or maybe 2 before of reboot. When i send an array of data of 5 bytes to peripheal UART every second this reboot isn't happend, with more of 20 bytes start to reboot. I think the issue is due to UART data flow.

Einar Thorsrud said:

Perhaps you did not properly handle full buffers, and that lead to a APP_ERROR_CHECK being hit

Where and what i can do??

Thank you, regards.

[sotillo2409]

I get the next error output due to reboots of peripheals:

ASSERTION FAIL [chunk_used(h, c)] @ WEST_TOPDIR/zephyr/lib/os/heap.c:154

unexpected heap state (double-free?) for memory at 0x200033d4

*** Booting Zephyr OS build v2.6.0-rc1-ncs1 ***

[Einar Thorsrud]

Hi,

That is a good indication of the issue. Can you check wat is located at 0x200033d4 in order to get closer? Using addr2line with the .elf file should do this.

(Regarding the APP_ERROR_CHECK that was under the assumption that you were using nRF5 SDK, which was not the case. I was hipping to get much of the same information you got from the assert you shown in your last post)

[sotillo2409]

Hi,

yes i am using nRF Connect SDK 1.6.1 and nRF Connect 3.7.1 with Toolchain Manager 0.9.3.

The last output error is getted via UART on the peripheal. The next output error appears on Segger Studio Debug at the same time:

[00:00:18.517,486] [1;31m<err> os: r0/a1: 0x00000004 r1/a2: 0x0000009a r2/a3: 0x00000001[0m
[00:00:18.517,517] [1;31m<err> os: r3/a4: 0x0001832d r12/ip: 0x00000000 r14/lr: 0x00015c97[0m
[00:00:18.517,517] [1;31m<err> os: xpsr: 0x41000000[0m
[00:00:18.517,517] [1;31m<err> os: Faulting instruction address (r15/pc): 0x0002c618[0m
[00:00:18.517,547] [1;31m<err> os: >>> ZEPHYR FATAL ERROR 4: Kernel panic on CPU 0[0m
[00:00:18.517,547] [1;31m<err> os: Current thread: 0x20001b88 (unknown)[0m
[00:00:18.696,929] [1;31m<err> fatal_error: Resetting system[0m

[Einar Thorsrud]

Can you check what is at 0x0002c618? That would be using something like:

arm-none-eabi-addr2line -e build-folder/zephyr/zephyr.elf 0x0002c618

[sotillo2409]

I will try right now, the last error on Segger is combined with this, 

So the rebooting is duoe two differents reasons.