Can't setup ISO Broadcast Demo on nrf53dk

[kaiser-ren]

Describe the bug
I compiled and flashed ./samples/bluetooth/iso_broadcast/ on nrf53dk. After power-on the dk, I found that there was an error when host sent HCI_LE_Set_-Extended_-Advertising_Parameters to controller, the controller return an event with status 0x01.

To Reproduce
Steps to reproduce the behavior:

1. cd ./samples/bluetooth/iso_broadcaster/
2. west build -p auto -b nrf5340dk_nrf5340_cpuapp ./
3. west flash
4. west build -p auto -b nrf5340dk_nrf5340_cpunet ./
5. west flash

Expected behavior
A clear and concise description of what you expected to happen.

Impact
Can't setup BIG/BIS

Logs and console output
```*** Booting Zephyr OS build zephyr-v2.5.0-3928-g86f18a61fa05 ***
Starting ISO Broadcast Demo
Failed to create advertising set (err -5)
[00:00:00.010,437] bt_hci_core: HW Platform: Nordic Semiconductor (0x0002)
[00:00:00.010,437] bt_hci_core: HW Variant: nRF53x (0x0003)
[00:00:00.010,437] bt_hci_core: Firmware: Standard Bluetooth controller (0x00) Version 2.6 Build 0
[00:00:00.011,169] bt_hci_core: Identity: D5:2B:02:90:B0:4F (random)
[00:00:00.011,169] bt_hci_core: HCI: version 5.2 (0x0b) revision 0x0000, manufacturer 0x05f1
[00:00:00.011,169] bt_hci_core: LMP: version 5.2 (0x0b) subver 0xffff
[00:00:00.011,413] bt_hci_core: opcode 0x2036 status 0x01
``\

Environment (please complete the following information):

• Commit SHA or Version used: cd9421a

Additional context
Add any other context about the problem here.

[carlescufi]

ISO is still very much a work in progress, so we've moved this into a discussion.

@cvinayak @Thalley can you add some feedback here please?

[Thalley]

@cvinayak Does the Zephyr controller support sending SDU data when sent over mulitple HCI Packets with the BT_ISO_START, BT_ISO_CONT and BT_ISO_END host->controller segmentation for broadcast?

[ApplicationNinja]

Is there any further update here? Do any of the ISO samples work on nRF5340 non-audio dev kit boards?

[cvinayak]

@cvinayak Does the Zephyr controller support sending SDU data when sent over mulitple HCI Packets with the BT_ISO_START, BT_ISO_CONT and BT_ISO_END host->controller segmentation for broadcast?

ISOAL implementation alongwith CI tests is upstream, but I have not tested it with a sample. Contributions covering segmentation use is welcome.

[cvinayak]

Is there any further update here? Do any of the ISO samples work on nRF5340 non-audio dev kit boards?

ISO support in Controller is work in progress. All work happens upstream, basic features are usable with correct use of Kconfig options, and work in progress can be followed using open GitHub issues and pull requests.
https://github.com/zephyrproject-rtos/zephyr/issues?q=is%3Aopen+is%3Aissue+label%3A%22area%3A+Bluetooth+ISO%22
https://github.com/zephyrproject-rtos/zephyr/pulls?q=is%3Aopen+is%3Apr+label%3A%22area%3A+Bluetooth+ISO%22+

[ApplicationNinja]

Is there any further update here? Do any of the ISO samples work on nRF5340 non-audio dev kit boards?

ISO support in Controller is work in progress. All work happens upstream, basic features are usable with correct use of Kconfig options, and work in progress can be followed using open GitHub issues and pull requests. https://github.com/zephyrproject-rtos/zephyr/issues?q=is%3Aopen+is%3Aissue+label%3A%22area%3A+Bluetooth+ISO%22 https://github.com/zephyrproject-rtos/zephyr/pulls?q=is%3Aopen+is%3Apr+label%3A%22area%3A+Bluetooth+ISO%22+

Thank you for your response...

[kaiser-ren]

If this sample code is not ready to be used, suggest that not put in ./samples folder because people may try to use it, but the result is the same, failed.

[Thalley]

I understand the frustration and/or confusion of this, but at some point it was decided that it was okay to put such features (supported only by the host) in the samples, as those are also useful for the people working on the controller to verify the implementation and behavior (see also #32669 (comment))

Perhaps we need to find a way to let it be clear when something runs on Zephyr (full-stack) or only on Zephyr host. This is actually similar to the PR (#33579) I made for one of your other Github issues (#32669).

[kaiser-ren]

I understand the frustration and/or confusion of this, but at some point it was decided that it was okay to put such features (supported only by the host) in the samples, as those are also useful for the people working on the controller to verify the implementation and behavior (see also #32669 (comment))

Perhaps we need to find a way to let it be clear when something runs on Zephyr (full-stack) or only on Zephyr host. This is actually similar to the PR (#33579) I made for one of your other Github issues (#32669).

That is so kind. I'm sorry that I raised this issue twice.

IMHO, separated full-stack, controller and host will be a great option to make developers select what they want to try in Bluetooth samples, for example, below or above HCI. There are so many boards/platforms/chipsets, and a lot of more are upcoming, different boards/platforms/chipsets have different capabilities.