periodic_sync HardFault with ASSERT: 50, 5233

[GuyYaniv]

Hi,

I'm trying to use the periodic sync sample app using 2 nrf52833DK (one for advertising and one for receiving sync) and been getting this assert message every time a sync advertisement arrives:

▒*** Booting nRF Connect SDK v3.5.99-ncs1-1 *** system
Starting Periodic Advertising Synchronization Demo
Checking LED device...done.
Configuring GPIO pin...done.
[00:00:00.000,671] <inf> bt_sdc_hci_driver: SoftDevice Controller build revision:
                                            36 f0 e5 0e 87 68 48 fb  02 fd 9f 82 cc 32 e5 7b |6....hH. .....2.{
                                            91 b1 5c ed                                      |..\.
[00:00:00.002,441] <inf> bt_hci_core: HW Platform: Nordic Semiconductor (0x0002)
[00:00:00.002,471] <inf> bt_hci_core: HW Variant: nRF52x (0x0002)
[00:00:00.002,502] <inf> bt_hci_core: Firmware: Standard Bluetooth controller (0x00) Version 54.58864 Build 1214809870
[00:00:00.003,234] <inf> bt_hci_core: Identity: C3:99:2C:E5:16:57 (random)
[00:00:00.003,295] <inf> bt_hci_core: HCI: version 5.4 (0x0d) revision 0x118f, manufacturer 0x0059
[00:00:00.003,326] <inf> bt_hci_core: LMP: version 5.4 (0x0d) subver 0x118f
Scan callbacks register...success.
Periodic Advertising callbacks register...Success.
Start scanning...success.
Start blinking LED...
Waiting for periodic advertising...
[00:00:02.015,563] <err> bt_sdc_hci_driver: SoftDevice Controller ASSERT: 50, 5233
[00:00:02.015,563] <err> os: ***** HARD FAULT *****
[00:00:02.015,563] <err> os:   Fault escalation (see below)
[00:00:02.015,594] <err> os: ARCH_EXCEPT with reason 3

[00:00:02.015,594] <err> os: r0/a1:  0x00000003  r1/a2:  0x00000000  r2/a3:  0x00004002
[00:00:02.015,625] <err> os: r3/a4:  0x00000000 r12/ip:  0x200018d8 r14/lr:  0x00000000
[00:00:02.015,625] <err> os:  xpsr:  0x41000011
[00:00:02.015,625] <err> os: Faulting instruction address (r15/pc): 0x00016c44
[00:00:02.015,686] <err> os: >>> ZEPHYR FATAL ERROR 3: Kernel oops on CPU 0
[00:00:02.015,686] <err> os: Fault during interrupt handling

[00:00:02.015,716] <err> os: Current thread: 0x200027b0 (unknown)

I've seen this thread describing something very similar, but it is from a year ago and the recommendation to use later release does not apply since I am using a release later than the one described in the thread.

What might be the cause for this assert?

Is there any tool that can help me understand such messages?

Thanks,

Guy.

[Einar Thorsrud]

Hi Guy,

The assert is in the scanner implementation of the SoftDevice controller. Which exact SDK version are you using?

[GuyYaniv]

v2.6.1

[Einar Thorsrud]

Hi Guy,

Thank you. I am checking internally to understand more about the assert and will get back to you regarding that.

Can you share instructions on how to reproduce the issue (changes to the sampel and anything else needed to trigger it)?

[GuyYaniv]

Thanks Einar,

Here's the patch for main.c:

diff --git a/samples/bluetooth/periodic_sync/src/main.c b/samples/bluetooth/periodic_sync/src/main.c
index aaaa141e7..11e143418 100644
--- a/samples/bluetooth/periodic_sync/src/main.c
+++ b/samples/bluetooth/periodic_sync/src/main.c
@@ -8,6 +8,7 @@
 #include <zephyr/devicetree.h>
 #include <zephyr/drivers/gpio.h>
 #include <zephyr/bluetooth/bluetooth.h>
+#include <zephyr/drivers/rtc.h>
 
 #define TIMEOUT_SYNC_CREATE K_SECONDS(10)
 #define NAME_LEN            30
@@ -78,18 +79,18 @@ static void scan_recv(const struct bt_le_scan_recv_info *info,
 
 	bt_data_parse(buf, data_cb, name);
 
-	bt_addr_le_to_str(info->addr, le_addr, sizeof(le_addr));
-	printk("[DEVICE]: %s, AD evt type %u, Tx Pwr: %i, RSSI %i %s "
-	       "C:%u S:%u D:%u SR:%u E:%u Prim: %s, Secn: %s, "
-	       "Interval: 0x%04x (%u ms), SID: %u\n",
-	       le_addr, info->adv_type, info->tx_power, info->rssi, name,
-	       (info->adv_props & BT_GAP_ADV_PROP_CONNECTABLE) != 0,
-	       (info->adv_props & BT_GAP_ADV_PROP_SCANNABLE) != 0,
-	       (info->adv_props & BT_GAP_ADV_PROP_DIRECTED) != 0,
-	       (info->adv_props & BT_GAP_ADV_PROP_SCAN_RESPONSE) != 0,
-	       (info->adv_props & BT_GAP_ADV_PROP_EXT_ADV) != 0,
-	       phy2str(info->primary_phy), phy2str(info->secondary_phy),
-	       info->interval, info->interval * 5 / 4, info->sid);
+	// bt_addr_le_to_str(info->addr, le_addr, sizeof(le_addr));
+	// printk("[DEVICE]: %s, AD evt type %u, Tx Pwr: %i, RSSI %i %s "
+	//        "C:%u S:%u D:%u SR:%u E:%u Prim: %s, Secn: %s, "
+	//        "Interval: 0x%04x (%u ms), SID: %u\n",
+	//        le_addr, info->adv_type, info->tx_power, info->rssi, name,
+	//        (info->adv_props & BT_GAP_ADV_PROP_CONNECTABLE) != 0,
+	//        (info->adv_props & BT_GAP_ADV_PROP_SCANNABLE) != 0,
+	//        (info->adv_props & BT_GAP_ADV_PROP_DIRECTED) != 0,
+	//        (info->adv_props & BT_GAP_ADV_PROP_SCAN_RESPONSE) != 0,
+	//        (info->adv_props & BT_GAP_ADV_PROP_EXT_ADV) != 0,
+	//        phy2str(info->primary_phy), phy2str(info->secondary_phy),
+	//        info->interval, info->interval * 5 / 4, info->sid);
 
 	if (!per_adv_found && info->interval) {
 		per_adv_found = true;
@@ -139,14 +140,39 @@ static void recv_cb(struct bt_le_per_adv_sync *sync,
 {
 	char le_addr[BT_ADDR_LE_STR_LEN];
 	char data_str[129];
+	static const struct device *rtc;
+	struct rtc_time datetime_get;
+	int drift = datetime_get.tm_nsec - buf->data[2];
+	int ret;
+
+    rtc = DEVICE_DT_GET(DT_NODELABEL(rtc0));
+    if (rtc==NULL) {
+        printk("Cannot find RTC device %s!\n",DT_NODE_FULL_NAME(DT_NODELABEL(rtc0)));
+        return 0;
+    }
 
 	bt_addr_le_to_str(info->addr, le_addr, sizeof(le_addr));
-	bin2hex(buf->data, buf->len, data_str, sizeof(data_str));
+	// bin2hex(buf->data, buf->len, data_str, sizeof(data_str));
+	int nsecs = buf->data[2];
+
+	if ((ret = rtc_get_time(rtc, &datetime_get)) != 0) {
+		if (ret == -ENODATA)
+		{
+			printk("Error fetching time\n");
+			return;
+		}
+	} else {
+		datetime_get.tm_nsec = buf->data[2];
+		if (!rtc_set_time(rtc, &datetime_get)) {
+			printk("Error setting time\n");
+			return;
+		}
+	}
 
 	printk("PER_ADV_SYNC[%u]: [DEVICE]: %s, tx_power %i, "
-	       "RSSI %i, CTE %u, data length %u, data: %s\n",
+	       "RSSI %i, CTE %u, drift: %d\n",
 	       bt_le_per_adv_sync_get_index(sync), le_addr, info->tx_power,
-	       info->rssi, info->cte_type, buf->len, data_str);
+	       info->rssi, info->cte_type, drift);
 }
 
 static struct bt_le_per_adv_sync_cb sync_callbacks = {

[Einar Thorsrud]

Hi,

Thank you. I will attempt to reproduce on my end and get back to you within one or two days.

[Einar Thorsrud]

Hi,

I am not able to reproduce the issue with the umodified sample. Regardign your changes I assume you have made some devicetree changes as well (without just these changes it does not build). That said, I expect this to fail as you use RTC0. This is reserved for the MPSL, which is used by the SoftDevice Controller (see MPSL integration notes for details).

RTC2 is normally available, so unless you plan to use that for something else, that could be an option. Or simply use Zephyr timer API's (Zephyr internally use RTC1 on the Nordic devices).

[GuyYaniv]

Thanks Einar,

I already figured it out. BTW the link you attached says the document doesn't exist.

Thanks,

Guy.

[Einar Thorsrud]

Hi Guy,

That is good to hear. Thanks for letting me know!

(PS: I updated the link in my previous reply so that it now points where it should)