direction_finding_connectionless_rx crashes if CONFIG_ASSERT=y

RE: direction_finding_connectionless_rx crashes if CONFIG_ASSERT=y

Simonr — Tue, 14 Sep 2021 12:40:46 GMT

Hi again

Thank you for pointing out that the "Booting Zephyr" message overwrote the ASSERTION FAIL. I missed it because of that. Very sorry about that.

So, after some debugging I found out that the CONFIG_BT_BUF_ACL_RX_COUNT and CONFIG_BT_BUF_ACL_RX_SIZE were too small for the length and caused this ASSERT when CONFIG_ASSERT=y in the connectionless_rx sample project. If you change these to the following values you should be out of harms way. I have also reported this internally, and we'll update the project in a future NCS release to fix this issue. Thank you again for reporting this to us!

CONFIG_BT_BUF_ACL_RX_COUNT=10
CONFIG_BT_BUF_ACL_RX_SIZE=200

Best regards,

Simon

RE: direction_finding_connectionless_rx crashes if CONFIG_ASSERT=y

jakkra — Mon, 13 Sep 2021 12:48:38 GMT

So I picked a new computer, installed nrfconnect, toolchain manager etc. and ncs version 1.6.1. My only modification is adding CONFIG_ASSERT=y in this folder: NrfConnect\v1.6.1\nrf\samples\bluetooth\direction_finding_connectionless_rx

Compiling with:

Transmitter:

west build -p -b nrf52833dk_nrf52833 -- -DOVERLAY_CONFIG=overlay-aoa.conf -DTC_OVERLAY_FILE=boards/nrf52833dk_nrf52833.overlay

west flash

Receiver:

west build -p -b nrf52833dk_nrf52833 -- -DTC_OVERLAY_FILE=boards/nrf52833dk_nrf52833.overlay

west flash

I have uploaded the log from receiver. You can see it crashing over and over again with error:

ASSERTION FAIL [net_buf_simple_tailroom(buf) >= len] @ WEST_TOPDIR/zephyr/subsys/net/buf.c:800

I'm using two nRF52833-DK without any antenna connected (just PCB antenna)

devzone.nordicsemi.com/.../putty.log

RE: direction_finding_connectionless_rx crashes if CONFIG_ASSERT=y

jakkra — Mon, 13 Sep 2021 09:26:23 GMT

I use the sample in \zephyr\samples\bluetooth\direction_finding_connectionless_rx\prj.conf but I tried the one on nrf folder also I think. The last log the output is a bit currupted I think . The ** Booting Zephyr ...." text overwrote the half ASSERT message see below bold text (ASSERTION FAIL [0])

*** Booting Zephyr OS build v2.6.0-rc1-ncs1 ***len] @ WEST_TOPDIR/zephyr/subsys/net/buf.c:800
Starting Connectionless Locator Demo

You can see exactly the git diff in one of my previous comments see here again:

PATH: DF/v1.6.1/zephyr/samples/bluetooth/direction_finding_connectionless_rx ((v2.6.0-rc1-ncs1))
$ git diff
diff --git a/samples/bluetooth/direction_finding_connectionless_rx/prj.conf b/samples/bluetooth/direction_finding_connectionless_rx/prj.conf
index 6de448fa5a..2761c58a9f 100644
--- a/samples/bluetooth/direction_finding_connectionless_rx/prj.conf
+++ b/samples/bluetooth/direction_finding_connectionless_rx/prj.conf
@@ -10,3 +10,4 @@ CONFIG_BT_OBSERVER=y
# Enable Direction Finding Feature including AoA and AoD
CONFIG_BT_DF=y
CONFIG_BT_DF_CONNECTIONLESS_CTE_RX=y
+CONFIG_ASSERT=y
\ No newline at end of file

I'll try the sample on nrf folder also again to make sure same issue there. I'll also reproduce everything once again with a completely clean install.

RE: direction_finding_connectionless_rx crashes if CONFIG_ASSERT=y

Simonr — Mon, 13 Sep 2021 09:13:34 GMT

Hi again

I don't see an assertion fail in the log you posted in your last reply, are you sure this is the complete log? Can you also confirm that you're setting CONFIG_ASSERT=y in the prj.conf file located in ...\NCS v1.x.x\nrf\samples\bluetooth\direction_finding_connectionless_rx\prj.conf?

Best regards,

Simon

RE: direction_finding_connectionless_rx crashes if CONFIG_ASSERT=y

jakkra — Fri, 10 Sep 2021 10:58:14 GMT

Tried in a shielded box still crashes for me. ncs 1.6.1 downloaded from toolchain manager.

RE: direction_finding_connectionless_rx crashes if CONFIG_ASSERT=y

jakkra — Fri, 10 Sep 2021 09:51:05 GMT

I now have both TX and RX (without antenna array) running on two nRF52833-DK and I get the same issue, only modification I made is to add the CONFIG_ASSERT=y in receiver prj.conf

Here is a full log on RX side. Could it be the issue is that there are many devices around here which causes the problem. I can give it a try in a shielded box to verify that as that could explain why you are not able to reproduce.

*** Booting Zephyr OS build v2.6.0-rc1-ncs1 ***len]
Starting Connectionless Locator Demo
Bluetooth initialization...success
Scan callbacks register...success.
Periodic Advertising callbacks register...success.
Start scanning...success
Waiting for periodic advertising...[DEVICE]: 14:05:3F:9F:6C:94 (random), AD evt type 3, Tx Pwr: 127, RSSI -81 C:0 S:0 D:0 SR:0 E:0 Prim: LE 1M, Secn: No packets, Interval: 0x0000 (0 ms), SID: 255
[DEVICE]: 22:D9:15:03:CB:94 (random), AD evt type 3, Tx Pwr: 127, RSSI -82 C:0 S:0 D:0 SR:0 E:0 Prim: LE 1M, Secn: No packets, Interval: 0x0000 (0 ms), SID: 255
[DEVICE]: 5B:A3:06:23:12:4A (random), AD evt type 0, Tx Pwr: 127, RSSI -88 C:1 S:1 D:0 SR:0 E:0 Prim: LE 1M, Secn: No packets, Interval: 0x0000 (0 ms), SID: 255
[DEVICE]: 5D:DD:54:53:92:DC (random), AD evt type 0, Tx Pwr: 127, RSSI -87 C:1 S:1 D:0 SR:0 E:0 Prim: LE 1M, Secn: No packets, Interval: 0x0000 (0 ms), SID: 255
[DEVICE]: 03:EA:66:FD:62:F6 (random), AD evt type 5, Tx Pwr: 127, RSSI -63 DF Connectionless Beacon App C:0 S:0 D:0 SR:0 E:1 Prim: LE 1M, Secn: LE 2M, Interval: 0x0780 (2400 ms), SID: 0
success. Found periodic advertising.
Creating Periodic Advertising Sync...success.
Waiting for periodic sync...
[DEVICE]: 00:12:F3:43:44:41 (public), AD evt type 0, Tx Pwr: 127, RSSI -71 C:1 S:1 D:0 SR:0 E:0 Prim: LE 1M, Secn: No packets, Interval: 0x0000 (0 ms), SID: 255
[DEVICE]: 00:12:F3:43:44:41 (public), AD evt type 4, Tx Pwr: 127, RSSI -70 NINA-B3-434441 C:1 S:1 D:0 SR:1 E:0 Prim: LE 1M, Secn: No packets, Interval: 0x0000 (0 ms), SID: 255
[DEVICE]: CF:98:95:2E:71:5A (random), AD evt type 3, Tx Pwr: 127, RSSI -85 C:0 S:0 D:0 SR:0 E:0 Prim: LE 1M, Secn: No packets, Interval: 0x0000 (0 ms), SID: 255
[DEVICE]: F1:EE:A5:62:86:31 (random), AD evt type 3, Tx Pwr: 127, RSSI -80 C:0 S:0 D:0 SR:0 E:0 Prim: LE 1M, Secn: No packets, Interval: 0x0000 (0 ms), SID: 255
[DEVICE]: 00:12:F3:00:00:39 (public), AD evt type 0, Tx Pwr: 127, RSSI -53 C:1 S:1 D:0 SR:0 E:0 Prim: LE 1M, Secn: No packets, Interval: 0x0000 (0 ms), SID: 255
[DEVICE]: 00:12:F3:00:00:39 (public), AD evt type 4, Tx Pwr: 127, RSSI -52 NINA-B3-000039 C:1 S:1 D:0 SR:1 E:0 Prim: LE 1M, Secn: No packets, Interval: 0x0000 (0 ms), SID: 255
[DEVICE]: 00:12:F3:58:61:26 (public), AD evt type 0, Tx Pwr: 127, RSSI -88 C:1 S:1 D:0 SR:0 E:0 Prim: LE 1M, Secn: No packets, Interval: 0x0000 (0 ms), SID: 255
[DEVICE]: D5:1F:F2:64:CA:90 (random), AD evt type 3, Tx Pwr: 127, RSSI -82 C:0 S:0 D:0 SR:0 E:0 Prim: LE 1M, Secn: No packets, Interval: 0x0000 (0 ms), SID: 255
[DEVICE]: 3C:6F:67:30:FD:B6 (random), AD evt type 3, Tx Pwr: 127, RSSI -73 C:0 S:0 D:0 SR:0 E:0 Prim: LE 1M, Secn: No packets, Interval: 0x0000 (0 ms), SID: 255
[DEVICE]: 00:12:F3:00:00:49 (public), AD evt type 0, Tx Pwr: 127, RSSI -47 C:1 S:1 D:0 SR:0 E:0 Prim: LE 1M, Secn: No packets, Interval: 0x0000 (0 ms), SID: 255
[DEVICE]: 00:12:F3:00:00:49 (public), AD evt type 4, Tx Pwr: 127, RSSI -46 NINA-B3-000049 C:1 S:1 D:0 SR:1 E:0 Prim: LE 1M, Secn: No packets, Interval: 0x0000 (0 ms), SID: 255
[DEVICE]: 00:12:F3:01:19:33 (public), AD evt type 0, Tx Pwr: 127, RSSI -78 C:1 S:1 D:0 SR:0 E:0 Prim: LE 1M, Secn: No packets, Interval: 0x0000 (0 ms), SID: 255
[DEVICE]: 00:12:F3:01:19:33 (public), AD evt type 4, Tx Pwr: 127, RSSI -78 NINA-B1-011933 C:1 S:1 D:0 SR:1 E:0 Prim: LE 1M, Secn: No packets, Interval: 0x0000 (0 ms), SID: 255
[DEVICE]: 7F:79:EF:92:9B:67 (random), AD evt type 0, Tx Pwr: 127, RSSI -87 C:1 S:1 D:0 SR:0 E:0 Prim: LE 1M, Secn: No packets, Interval: 0x0000 (0 ms), SID: 255
[DEVICE]: 69:CC:4E:EA:8A:1D (random), AD evt type 3, Tx Pwr: 127, RSSI -61 C:0 S:0 D:0 SR:0 E:0 Prim: LE 1M, Secn: No packets, Interval: 0x0000 (0 ms), SID: 255
[DEVICE]: 01:C8:56:46:29:80 (random), AD evt type 3, Tx Pwr: 127, RSSI -51 C:0 S:0 D:0 SR:0 E:0 Prim: LE 1M, Secn: No packets, Interval: 0x0000 (0 ms), SID: 255
[DEVICE]: 00:12:F3:01:33:79 (public), AD evt type 0, Tx Pwr: 127, RSSI -69 C:1 S:1 D:0 SR:0 E:0 Prim: LE 1M, Secn: No packets, Interval: 0x0000 (0 ms), SID: 255
[DEVICE]: 00:12:F3:01:33:79 (public), AD evt type 4, Tx Pwr: 127, RSSI -69 ANNA-B1-013379 C:1 S:1 D:0 SR:1 E:0 Prim: LE 1M, Secn: No packets, Interval: 0x0000 (0 ms), SID: 255
PER_ADV_SYNC[0]: [DEVICE]: 03:EA:66:FD:62:F6 (random) synced, Interval 0x0780 (2400 ms), PHY LE 2M
success. Periodic sync established.
Enable receiving of CTE...
success. CTE receive enabled.
Scan disable...Success.
Waiting for periodic sync lost...
PER_ADV_SYNC[0]: [DEVICE]: 03:EA:66:FD:62:F6 (random), tx_power 127, RSSI -55, CTE AOA, data length 0, data:
*** Booting Zephyr OS build v2.6.0-rc1-ncs1 ***len] @ WEST_TOPDIR/zephyr/subsys/net/buf.c:800
Starting Connectionless Locator Demo

...

RE: direction_finding_connectionless_rx crashes if CONFIG_ASSERT=y

jakkra — Fri, 10 Sep 2021 07:58:07 GMT

Hi thanks for input, at first I useed our custom board with our antenna, however after your reply I also tried rebuilding and re-flashing the RX code on a nRF52833 DK without antenna array, so nRF52833 DK using only single PCB antenna and I get the same crash. I verified that I have no diff in the sdk except:

...DF/v1.6.1/zephyr/samples/bluetooth/direction_finding_connectionless_rx ((v2.6.0-rc1-ncs1))
$ git diff
diff --git a/samples/bluetooth/direction_finding_connectionless_rx/prj.conf b/samples/bluetooth/direction_finding_connectionless_rx/prj.conf
index 6de448fa5a..2761c58a9f 100644
--- a/samples/bluetooth/direction_finding_connectionless_rx/prj.conf
+++ b/samples/bluetooth/direction_finding_connectionless_rx/prj.conf
@@ -10,3 +10,4 @@ CONFIG_BT_OBSERVER=y
# Enable Direction Finding Feature including AoA and AoD
CONFIG_BT_DF=y
CONFIG_BT_DF_CONNECTIONLESS_CTE_RX=y
+CONFIG_ASSERT=y
\ No newline at end of file

I'll try to find another nRF52833 DK so that I can flash the transmitter code on that and not use our custom board for TX also if that makes a difference.

RE: direction_finding_connectionless_rx crashes if CONFIG_ASSERT=y

Simonr — Fri, 10 Sep 2021 07:30:48 GMT

I tried this on my end and did not run into an assertion fail like this. Are you running the RX and TX examle projects on nRF52833 DKs or custom boards? Is the RX device connected to an antenna array or is it just using a single antenna?

Best regards,

Simon