nRF5340 broadcast sink does not get BIG/PA loss callbacks when broadcast source reboots; only "Unhandled vendor-specific event 0x01"

RE: nRF5340 broadcast sink does not get BIG/PA loss callbacks when broadcast source reboots; only "Unhandled vendor-specific event 0x01"

GlennEngel — Fri, 20 Mar 2026 18:53:15 GMT

In testing I get the error on the receiver even if I just 'hard reset' the sender. In any case the receiver shouldn't hang up so there is some issue there. I'll try to replicate on the demo app next week to see what might be different in your testing vs my experience.

RE: nRF5340 broadcast sink does not get BIG/PA loss callbacks when broadcast source reboots; only "Unhandled vendor-specific event 0x01"

Maria Gilje — Thu, 19 Mar 2026 12:51:14 GMT

Hello,

I see. In that case it could be necessary to also perform more cleanup for the broadcast source before the device goes to sleep. For comparison, when stopping the broadcast in the BAP Broadcast Audio Source sample, the source is also deleted and periodic and extended advertising is stopped (and deleted). See the process from line 683 in bap_broadcast_source/src/main.c.

Best regards,

Maria

RE: nRF5340 broadcast sink does not get BIG/PA loss callbacks when broadcast source reboots; only "Unhandled vendor-specific event 0x01"

GlennEngel — Wed, 18 Mar 2026 20:59:12 GMT

Perhaps one significant item is that my broadcast source is doing a controlled reboot where it is going to sleep and waiting for a wakeup event so it's not a hard reset pin action. Before going to sleep it makes a call to bt_bap_broadcast_source_stop

    err = bt_bap_broadcast_source_stop(broadcast_source);
	if (err != 0 && err != -EALREADY) {
		printk("Failed to stop broadcast source: %d\n", err);
		return err;
	}
	
	// snip - shut down other stuff
	
	LOG_PANIC();
	k_sleep(K_MSEC(120));
	sys_poweroff();

RE: nRF5340 broadcast sink does not get BIG/PA loss callbacks when broadcast source reboots; only "Unhandled vendor-specific event 0x01"

Maria Gilje — Wed, 18 Mar 2026 15:05:58 GMT

Hello,

With the default broadcast source and sink configurations for the Audio application, this issue is not reproducible. I know that you have modified your application, so I need to know some more details about what these modifications are to be able to diagnose this properly.

Are you using a broadcast name as the match critera for the broadcast sink? If yes: Does the broadcast source have a set broadcast name which is consistent across boots?

[quote user=""]4. Is this a known issue on nRF5340/NCS 3.2.0 for LE Audio broadcast sink teardown when the source disappears abruptly?[/quote]

This is not a known issue. Our implementation of the broadcast sink handles abrupt reboots of the broadcast source properly.

When rebooting the broadcast source I get these logs on the broadcast sink:

HL [00:02:11.224,304] <inf> broadcast_sink: Stream sync lost
HL [00:02:11.224,365] <inf> broadcast_sink: Stream index 0 stopped. Reason: 8
HL [00:02:11.225,372] <inf> main: Sync lost
HL [00:02:11.226,013] <inf> main: PA sync lost, reason: 22

Do you get any similar logs for your application when the broadcast source reboots?

I'll adress your other questions when I know a bit more about your application and configuration.

Best regards,

Maria