Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bluetooth: Extended advertising with one advertising set fails after the first time #31254

Closed
StevenGhe opened this issue Jan 12, 2021 · 12 comments · Fixed by #32754
Closed

Bluetooth: Extended advertising with one advertising set fails after the first time #31254

StevenGhe opened this issue Jan 12, 2021 · 12 comments · Fixed by #32754
Assignees
Labels
area: Bluetooth Controller area: Bluetooth bug The issue is a bug, or the PR is fixing a bug priority: low Low impact/importance bug
Milestone

Comments

@StevenGhe
Copy link

StevenGhe commented Jan 12, 2021

Describe the bug
A clear and concise description of what the bug is.
I'm using an extended advertising set with one event (BT_LE_EXT_ADV_START_PARAM(0,1)). However if I call "bt_le_ext_adv_start" again with the same parameters, I get an error: (see picture below)

<err> bt_hci_core: Failed to start advertiser
[INIT] failed bt_le_ext_adv_start (err -5) ( <-my own printk log)

Am I supposed to stop advertising or create a new extended advertising set each event?
The .sent callback in the "bt_le_ext_adv_cb" is called the first time, which makes me believe the advertising has stopped.
Looking at the documentation, I see nothing else I can do?
I use an Adafruit Feather with a Nordic nRF52840 chip.

What have you tried to diagnose or workaround this issue?
Tried a lot of different methods of triggering this single advertising event. Nothing really changed
Multiple devices have the same behaviour

To Reproduce
Steps to reproduce the behavior:
I've supplied a main.c with some configuration files to test the problem in a .zip below.
The output generated on my device(s) is in the picture below.

Expected behavior
A clear and concise description of what you expected to happen.
Advertising should happen each time. Not just the first time.

Impact
What impact does this issue have on your progress (e.g., annoyance, showstopper)
I'm quite sure I could use (BT_LE_EXT_ADV_START_PARAM(0,0) and stop the advertising myself given I stop it before the second event happened. So not too bad, but I think it could be more efficient using the provided function.

Logs and console output
image
snippet.zip

Edit: The main.c file is quite messy, I threw everythign related from my own project into the single file. The most interesting parts are at the bottom (main function and BLE advertising method)
Edit2: changed some things requested by Joakim Andersson on Slack

Environment (please complete the following information):

  • OS: Win10
  • Toolchain: Zephyr
  • Commit SHA or Version used:
    1e61d3e
@StevenGhe StevenGhe added the bug The issue is a bug, or the PR is fixing a bug label Jan 12, 2021
@joerchan
Copy link
Contributor

@cvinayak This seems to be an issue with the controller. The advertiser cannot be restarted after it has been terminated in the controller by a timeout or number of events limit.
The advertising set terminated event has been given to the host.

A simple test in the shell:

uart:~$ bt init
Bluetooth initialized
uart:~$ bt adv-create conn-nscan ext-adv
Created adv id: 0, adv: 0x20002800
uart:~$ bt adv-start
Advertiser[0] 0x20002800 set started
uart:~$ bt adv-stop
Advertiser set stopped
uart:~$ bt adv-start num-events 4
Advertiser[0] 0x20002800 set started
Advertiser[0] 0x20002800 sent 4
uart:~$ bt adv-start
Failed to start advertising set (-5)
[00:00:53.906,311] <wrn> bt_hci_core: opcode 0x2039 status 0x0c
[00:00:53.906,341] <err> bt_hci_core: Failed to start advertiser

@cvinayak
Copy link
Contributor

@joerchan Is the issue with non-connectable non-scannable extended advertising too?

@joerchan
Copy link
Contributor

@cvinayak No, that seems to work:

uart:~$ bt adv-create nconn-nscan ext-adv
Created adv id: 0, adv: 0x20002800
uart:~$ bt adv-start num-events 4
Advertiser[0] 0x20002800 set started
Advertiser[0] 0x20002800 sent 4
uart:~$ bt adv-start
Advertiser[0] 0x20002800 set started

@cvinayak
Copy link
Contributor

@joerchan ok. Thank you. Connectable was added recently, will add a connectable advertising test, investigate and send a PR.

@joerchan joerchan changed the title Extended advertising with one advertising set fails after the first time Bluetooth: Extended advertising with one advertising set fails after the first time Jan 12, 2021
@StevenGhe
Copy link
Author

I'm sorry but I wasn't using connectable advertising? Only Identity and Extended options are set.

@cvinayak
Copy link
Contributor

@joerchan There is already a bsim test that covers starting connectable advertising after the terminate due to max events. (https://github.com/zephyrproject-rtos/zephyr/blob/master/tests/bluetooth/bsim_bt/bsim_test_advx/src/main.c#L236) The test is passing in CI. I also added another start advertising with max events, advertising start without duration/max events and the test still passed for me.

updated test patch file:
0001-tests-Bluetooth-bsim-Added-advertising-start-after-t.zip

There must be something wrong running on target, will continue investigation...

@nashif nashif added the priority: medium Medium impact/importance bug label Jan 12, 2021
@cvinayak
Copy link
Contributor

This is a bug in the controller, the implementation to release auxiliary channel PDU resources is missing when advertising terminates due to max events or duration. Relates to #26338

@carlescufi carlescufi added priority: low Low impact/importance bug and removed priority: medium Medium impact/importance bug labels Jan 14, 2021
@carlescufi
Copy link
Member

Setting priority as low since this is a WIP feature in the controller.

@carlescufi carlescufi added this to the v2.6.0 milestone Jan 21, 2021
@carlescufi
Copy link
Member

@StevenGhe this is caused by the current implementation of Extended Adv missing parts of it, it will be fixed as part of the ongoing Ext Adv work, but not in time for Zephyr 2.5.

@StevenGhe
Copy link
Author

Any ETA? Are we speaking of weeks/months?

My thesis is due +- May so not having such key BLE feature is pretty huge for me.

@joerchan
Copy link
Contributor

@StevenGhe I don't know the ETA, but in the meantime you could use the SoftDevice controller in nRF Connect SDK, which has support for this feature.

@legoabram
Copy link
Collaborator

I have a similar problem which I believe is related. An advertising set will also fail to restart if a connection was made through that set. In that instance, BT_HCI_ERR_MEM_CAPACITY_EXCEEDED is returned instead. The error starts in ull_adv.c at line 978 when calling ll_rx_alloc. It looks like extended advertising sets don't always cleanup after themselves.
prj.zip

cvinayak added a commit to cvinayak/zephyr that referenced this issue Mar 1, 2021
When Extended Advertising terminated due to duration or
maximum number of events, the auxiliary PDU scheduling
is now correctly stopped.

Fixes zephyrproject-rtos#31254.

Signed-off-by: Vinayak Kariappa Chettimada <vich@nordicsemi.no>
nashif pushed a commit that referenced this issue Mar 10, 2021
When Extended Advertising terminated due to duration or
maximum number of events, the auxiliary PDU scheduling
is now correctly stopped.

Fixes #31254.

Signed-off-by: Vinayak Kariappa Chettimada <vich@nordicsemi.no>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: Bluetooth Controller area: Bluetooth bug The issue is a bug, or the PR is fixing a bug priority: low Low impact/importance bug
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants