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

Gap::addDeviceToPeriodicAdvertiserList always return BLE_ERROR_INVALID_PARAM #11574

Closed
anton-veretenenko opened this issue Sep 26, 2019 · 5 comments

Comments

@anton-veretenenko
Copy link

anton-veretenenko commented Sep 26, 2019

Description

Trying to sync to several peers who use periodic advertising. Sync to single peer works.
Then I try to use Gap::addDeviceToPeriodicAdvertiserList and Gap::createSync to the list.
But Gap::addDeviceToPeriodicAdvertiserList always return BLE_ERROR_INVALID_PARAM after checking peerAddressType even if I provide proper peer address type.
I took a look in the code and found this:

if (peerAddressType != PeerAddressType_t::PUBLIC || peerAddressType != PeerAddressType_t::RANDOM ) { return BLE_ERROR_INVALID_PARAM; }
at /features/FEATURE_BLE/source/generic/GenericGap.tpp
This will always return BLE_ERROR_INVALID_PARAM even if you provide proper PUBLIC or RANDOM peer address type.

After fixing this if statement, sync to the list does not work, after createSync called there are no events at all, no timeouts, nothing.

Target is NRF52840 custom board. Mbed 5.13.

Issue request type

[ ] Question
[ ] Enhancement
[ x] Bug
@0xc0170
Copy link
Contributor

0xc0170 commented Nov 6, 2019

cc @ARMmbed/mbed-os-pan

@ciarmcom
Copy link
Member

ciarmcom commented Oct 2, 2020

Thank you for raising this detailed GitHub issue. I am now notifying our internal issue triagers.
Internal Jira reference: https://jira.arm.com/browse/IOTOSM-2301

@paul-szczepanek-arm
Copy link
Member

paul-szczepanek-arm commented Oct 28, 2020

Parameter check fixed in #13822 but further issues remain with creating syncs based on the list. This is tracked internally and will be addressed asap.

@paul-szczepanek-arm
Copy link
Member

Turned out to be quite hard to track down, PR is up:
#13988

@paul-szczepanek-arm
Copy link
Member

This is now fixed on master.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants