BT_LE_ADV_OPT_EXT_ADV causes bt_le_adv_start to return -22

jaredwolff commented 4 years ago

Describe the bug BLE advertising failed to start on a nRF52840 when enabling BT_LE_ADV_OPT_EXT_ADV.

[00:00:00.002,960] <inf> ble_m: BLE Stack Ready!
[00:00:00.002,960] <inf> ble_peripheral: Bluetooth initialized
[00:00:00.002,960] <err> ble_peripheral: Advertising failed to start (err -22)

To Reproduce

Choose any BLE example
Use a compatible board like nrf52840dk_nrf52840
Add CONFIG_BT_EXT_ADV=y to your prj.conf
When initializing struct bt_le_adv_param *adv_param = add these two flags BT_LE_ADV_OPT_CODED | BT_LE_ADV_OPT_EXT_ADV

Looks like this:

    struct bt_le_adv_param *adv_param =
        BT_LE_ADV_PARAM(BT_LE_ADV_OPT_CONNECTABLE |
                BT_LE_ADV_OPT_ONE_TIME | BT_LE_ADV_OPT_CODED |
                BT_LE_ADV_OPT_EXT_ADV,
                BT_GAP_ADV_FAST_INT_MIN_2,
                BT_GAP_ADV_FAST_INT_MAX_2,
                NULL);

Even with the two params removed, advertising still returns -5 when CONFIG_BT_EXT_ADV is set.

Expected behavior Start advertising with PHY CODED.

Impact I know CODED PHY is still experimental. I figure since it's potentially unfinished that's why the way the code is the way it is!

Screenshots or console output

Here's some output when that first blocker check is removed from hci_core.c

Slave role. Starting advertising
W: opcode 0x2036 status 0x01
Failed to start advertiser (-5)

Environment (please complete the following information):

OS: MacOS
Toolchain gcc-arm-none-eabi-8-2019-q3-update
Commit 1.2.99

Additional context

in hci_core.c the valid_adv_param function checks if param->options has BT_LE_ADV_OPT_EXT_ADV set.

static bool valid_adv_param(const struct bt_le_adv_param *param)
{
    if (param->options & BT_LE_ADV_OPT_EXT_ADV) {
        // return false;
    }

So in any case, this will cause this function to return false. It's a dependency for BT_LE_ADV_OPT_CODED though. Later on in valid_adv_ext_param it's checked again most importantly here

        if (!(param->options & BT_LE_ADV_OPT_EXT_ADV) &&
            param->options & (BT_LE_ADV_OPT_EXT_ADV |
                      BT_LE_ADV_OPT_NO_2M |
                      BT_LE_ADV_OPT_CODED |
                      BT_LE_ADV_OPT_ANONYMOUS |
                      BT_LE_ADV_OPT_USE_TX_POWER)) {
            /* Extended options require extended advertising. */
            return false;
        }

So basically the first function is returning even if it's a "valid" extended advertising configuration.

As I mentioned earlier, it's probably on purpose until full support is available..

joerchan commented 4 years ago

The reason why valid_adv_param is returning false for those options is because you need to switch to the new Advertising API to use the extended advertising options.


struct bt_le_ext_adv *adv;
struct bt_le_adv_param *adv_param =
        BT_LE_ADV_PARAM(BT_LE_ADV_OPT_CONNECTABLE |
                BT_LE_ADV_OPT_ONE_TIME | BT_LE_ADV_OPT_CODED |
                BT_LE_ADV_OPT_EXT_ADV,
                BT_GAP_ADV_FAST_INT_MIN_2,
                BT_GAP_ADV_FAST_INT_MAX_2,
                NULL);
int err;

err = bt_le_ext_adv_create(param, NULL, &adv);
err = bt_le_ext_adv_start(adv, NULL);

W: opcode 0x2036 status 0x01 Failed to start advertiser (-5) This is telling you status 0x01 on the HCI command, which means that the controller you are trying to use do not support the extended advertising HCI commands.

If you are using the zephyr controller then extended advertising is not yet supported.

carlescufi commented 4 years ago

@jaredwolff to summarize what @joerchan said: the current BLE controller implementation in Zephyr does not support connectable advertising using advertising extensions, so this is not really a bug but rather a feature that is not implemented.

jaredwolff commented 4 years ago

Got it! That was the same conclusion I came to from what @joerchan said. Seems to be working without error with these guys enabled:

CONFIG_BT_LL_NRFXLIB_VS_INCLUDE=y
CONFIG_BT_LL_NRFXLIB_DEFAULT=y

jaredwolff commented 4 years ago

Also to confirm with what you guys said, this means that if CODED PHY is desired, first connect using a supported PHY, then transition to CODED PHY? With the Nordic controller, I'm definitely seeing advertisements but as mentioned their not connectable.

joerchan commented 4 years ago

@jaredwolff The advertiser parameters determines the initial connection PHY, so when using BT_LE_ADV_OPT_CODED then the connection will be established on LE Coded PHY. https://github.com/zephyrproject-rtos/zephyr/blob/master/include/bluetooth/bluetooth.h#L430

jaredwolff commented 4 years ago

Ahh so it's completely not possible to connect with CODED PHY as @carlescufi had alluded to about connectable advertising using advertising extensions? I'm seeing those advertisements coming over as non-connectable. Or is there something else I have to do to make that happen? (Other than wait 🤓)

(Btw, I'm using some nRF52840s for this process. I opened up a Devzone case here)

carlescufi commented 4 years ago

Ahh so it's completely not possible to connect with CODED PHY as @carlescufi had alluded to about connectable advertising using advertising extensions? I'm seeing those advertisements coming over as non-connectable. Or is there something else I have to do to make that happen? (Other than wait 🤓)

(Btw, I'm using some nRF52840s for this process. I opened up a Devzone case here)

You can choose to wait until AE is fully implemented in the open source controller or you can use the nrfxlib controller in the nRF Connect SDK

jaredwolff commented 4 years ago

Thanks @carlescufi!

As far as I can tell, I'm able to see advertisements but they're not connectable (using the Nordic controller AFAIK).

Since I'm coming from the original SDK, I'm used to defining (very explicitly) what soft device. Is the LE controller chosen by board def? Anything else I need to do besides define these guys?

# Mine
CONFIG_BT_LL_NRFXLIB_VS_INCLUDE=y
CONFIG_BT_LL_NRFXLIB_DEFAULT=y
CONFIG_BT_MAX_CONN=2

I also assume its still the same top level Zephyr Bluetooth API?

_By the way, I am running one node off off a nRF9160 using the hci_uart sample running on a nRF52840._

carlescufi commented 4 years ago

I also assume its still the same top level Zephyr Bluetooth API?

Yes, same API.

As far as I can tell, I'm able to see advertisements but they're not connectable (using the Nordic controller AFAIK).

Can you try using tests/bluetooth/shell first and seeing if you can generate connectable advertising events on coded phy there? It should work.

jaredwolff commented 4 years ago

Alright let me give it a whirl. There shouldn't be a difference between it being loaded directly or controlling via HCI_UART correct? I've modified the HCI_UART example with the above flags as well. (Not on the nRF9160 side though)

jaredwolff commented 4 years ago

Alright, disregard the earlier message. I wasn't using the old API. I did get farther but not much:

bt init
bt adv-create conn-nscan ext-adv coded
bt adv-select 0
bt adv-start

To which I got a

Advertiser[0] 0x20003944 set started
uart:~$ ASSERTION FAIL [!arch_is_in_isr()] @ ../../../../kernel/include/ksched.h:267

Building with this:

west build -b nrf52840dk_nrf52840

joerchan commented 4 years ago

@jaredwolff I'm not able to see the problem you are seeing, could you include more information about your setup? Commit, which sample/application is flashed to where. When calling the command bt adv-create conn-scan ext-adv coded I get an (expected) error, because extended advertising cannot be both connectable and scannable. Using bt adv-create conn-nscan ext-adv coded it starts fine.

jaredwolff commented 4 years ago

NCS dir: commit 4c0d3be2ed4ade4dc3e614e95e6f8e4330d663b4 (HEAD, tag: v1.3.0, origin/v1.3-branch, manifest-rev) Zephyr dir: commit bbd71e23a2d56f05cefc9dca7bef609c22c1966c (HEAD, tag: v2.3.0-rc1-ncs1-rc3, tag: v2.3.0-rc1-ncs1, manifest-rev)

I'm flashing ncs/zephyr/tests/bluetooth/shell using:

west build -b nrf52840dk_nrf52840
west flash -r nrfjprog

This is to a nRF52840 Preview DK I had from a while back. So there could be an issue there as the silicon is older.

Here's the diff on prj.conf

diff --git a/tests/bluetooth/shell/prj.conf b/tests/bluetooth/shell/prj.conf
index bfe30cd7e6..d7a8741712 100644
--- a/tests/bluetooth/shell/prj.conf
+++ b/tests/bluetooth/shell/prj.conf
@@ -41,3 +41,8 @@ CONFIG_BT_AUTO_DATA_LEN_UPDATE=y

 CONFIG_BT_USER_PHY_UPDATE=y
 CONFIG_BT_AUTO_PHY_UPDATE=y
+
+# Mine
+CONFIG_BT_LL_NRFXLIB_VS_INCLUDE=y
+CONFIG_BT_LL_NRFXLIB_DEFAULT=y
+CONFIG_BT_MAX_CONN=2

Those are the only modifications for this example.

I'm compiling with gcc-arm-none-eabi-8-2019-q3-update I just tried everything again from fresh this morning with the same issue.

jaredwolff commented 4 years ago

Updated my toolchain to the recommended gcc-arm-none-eabi-9-2019-q4-major and still no dice.

joerchan commented 4 years ago

@jaredwolff Thanks, The preview DK for the nrf52840 has a problem with LE Coded PHY, which might be what you are running into. I found one of my old Preview-DKs to see if I get the same problem as you, but I didn't. But for m I know it will crash once i go in a connection with LE Coded PHY. Maybe we have different revisions of the Preview-DK.

jaredwolff commented 4 years ago

Ahhh! Let me see if I can get it running on something I know is newer. I'll also order a fresh nRF52840 and replace the ones I have here for good measure.

Side note Originally when I posted, I was running things on a Particle Xenon. I only switched to the nRF52840 DK since it was easier to determine where things went wrong.

jaredwolff commented 4 years ago

Alright, with a fresh chip I get no errors. I'm also able to see the Particle Xenon here that's advertising:

[DEVICE]: 49:41:f1:56:d6:99 (random), AD evt type 5, RSSI -90 Pyrinas C:1 S:0 D:0 SR:0 E:1 Prim: LE Coded, Secn: LE Coded
[DEVICE]: 49:41:f1:56:d6:99 (random), AD evt type 5, RSSI -85 Pyrinas C:1 S:0 D:0 SR:0 E:1 Prim: LE Coded, Secn: LE Coded
[DEVICE]: 49:41:f1:56:d6:99 (random), AD evt type 5, RSSI -89 Pyrinas C:1 S:0 D:0 SR:0 E:1 Prim: LE Coded, Secn: LE Coded

Looks like it is connectable here.

bt scan stop
bt connect 49:41:f1:56:d6:99 random coded no-1m
Connection pending
Failed to connect to 49:41:f1:56:d6:99 (random) (0x02)

I don't see any output on the other side. I'll get back this in the morning.

jaredwolff commented 4 years ago

@joerchan were you able to obtain a full connection between two nRF52840 DKs using PHY coded? As mentioned before, I'm able to scan but the connection fails.

If you'd did, is it possible for you to provide the command sequences for each device? Thanks!

jaredwolff commented 4 years ago

@joerchan I'll have to put this project on hold. Fortunately, I was using the original SDK to do the same thing. As much as I'd love to use Zephyr, it seems to be not ready yet. I'd be happy to test if and when it is. Thanks again for all your help!

joerchan commented 4 years ago

@jaredwolff Using NCS 1.3.0 and two nrf52840 DKs.

west build ../zephyr/tests/bluetooth/shell -- -DCONFIG_BT_LL_NRFXLIB=y -DCONFIG_BT_MAX_CONN=2 -DCONFIG_BT_AUTO_PHY_UPDATE=n

Peripheral:

uart:~$ bt init
Bluetooth initialized
[00:00:02.680,816] <inf> fs_nvs: 8 Sectors of 4096 bytes
[00:00:02.680,847] <inf> fs_nvs: alloc wra: 0, fc0
[00:00:02.680,847] <inf> fs_nvs: data wra: 0, 2c
[00:00:02.681,060] <inf> bt_ctlr_hci_driver: BLE controller build revision: 
76 fc 20 98 0a 2b 94 88  2b 73 12 87 a2 33 84 82 |v. ..+.. +s...3..
c0 62 2d 90                                      |.b-.             
[00:00:02.685,668] <inf> bt_hci_core: HW Platform: Nordic Semiconductor (0x0002)
[00:00:02.685,668] <inf> bt_hci_core: HW Variant: nRF52x (0x0002)
[00:00:02.685,668] <inf> bt_hci_core: Firmware: Standard Bluetooth controller (0x00) Version 118.8444 Build 2485848728
[00:00:02.686,279] <inf> bt_hci_core: No ID address. App must call settings_load()
[00:00:02.689,544] <inf> bt_hci_core: Identity: e2:94:c2:37:bf:f3 (random)
[00:00:02.689,575] <inf> bt_hci_core: HCI: version 5.2 (0x0b) revision 0xfffe, manufacturer 0x0059
[00:00:02.689,605] <inf> bt_hci_core: LMP: version 5.2 (0x0b) subver 0xfffe
uart:~$ bt adv-create conn-nscan ext-adv coded
Created adv id: 0, adv: 0x20003944
uart:~$ bt adv-start 
Advertiser[0] 0x20003944 set started
uart:~$ bt adv-oob
OOB data:
addr                          random                           confirm                         
   54:d7:60:85:24:f0 (random) 58365f0e553a9531c9fd726d9249f37f 4d0d386703b78945c1a7ba062fc5a407
Connected: 63:ae:d3:5c:fa:cb (random)
Advertiser[0] 0x20003944 connected by 63:ae:d3:5c:fa:cb (random)
LE conn param updated: int 0x0028 lat 0 to 42

Central:

uart:~$ bt init
Bluetooth initialized
[00:00:37.397,003] <inf> fs_nvs: 8 Sectors of 4096 bytes
[00:00:37.397,033] <inf> fs_nvs: alloc wra: 0, fc0
[00:00:37.397,033] <inf> fs_nvs: data wra: 0, 2c
[00:00:37.397,247] <inf> bt_ctlr_hci_driver: BLE controller build revision: 
76 fc 20 98 0a 2b 94 88  2b 73 12 87 a2 33 84 82 |v. ..+.. +s...3..
c0 62 2d 90                                      |.b-.             
[00:00:37.401,794] <inf> bt_hci_core: HW Platform: Nordic Semiconductor (0x0002)
[00:00:37.401,794] <inf> bt_hci_core: HW Variant: nRF52x (0x0002)
[00:00:37.401,794] <inf> bt_hci_core: Firmware: Standard Bluetooth controller (0x00) Version 118.8444 Build 2485848728
[00:00:37.402,374] <inf> bt_hci_core: No ID address. App must call settings_load()
[00:00:37.405,639] <inf> bt_hci_core: Identity: f9:dc:cf:9c:89:87 (random)
[00:00:37.405,670] <inf> bt_hci_core: HCI: version 5.2 (0x0b) revision 0xfffe, manufacturer 0x0059
[00:00:37.405,700] <inf> bt_hci_core: LMP: version 5.2 (0x0b) subver 0xfffe
uart:~$ bt connect 54:d7:60:85:24:f0 (random) coded no-1m
Connection pending
Connected: 54:d7:60:85:24:f0 (random)
Remote LMP version unknown (0x0b) subversion 0xfffe manufacturer 0x0059
LE Features: 0x0000000000004925 
LE conn  param req: int (0x0018, 0x0028) lat 0 to 42
LE conn param updated: int 0x0028 lat 0 to 42

jaredwolff commented 4 years ago

Ahh ok, looks like there are some differences in my config versus yours. It's very hard to tell what's necessary vs what's not. First I had set CONFIG_BT_LL_NRFXLIB_VS_INCLUDE and CONFIG_BT_LL_NRFXLIB_DEFAULT vs your CONFIG_BT_LL_NRFXLIB. Also I left CONFIG_BT_AUTO_PHY_UPDATE enabled which is maybe why things aren't working?

It still looks like we're running on a different build though. My startup looks different:

uart:~$ bt init
Bluetooth initialized
[00:00:06.230,560] <inf> fs_nvs: 8 Sectors of 4096 bytes
[00:00:06.230,560] <inf> fs_nvs: alloc wra: 0, fc0
[00:00:06.230,560] <inf> fs_nvs: data wra: 0, 29
[00:00:06.230,804] <inf> bt_ctlr_hci_driver: BLE controller build revision:
76 fc 20 98 0a 2b 94 88  2b 73 12 87 a2 33 84 82 |v. ..+.. +s...3..
c0 62 2d 90                                      |.b-.
[00:00:06.235,504] <inf> bt_hci_core: HW Platform: Nordic Semiconductor (0x0002)
[00:00:06.235,504] <inf> bt_hci_core: HW Variant: nRF52x (0x0002)
[00:00:06.235,534] <inf> bt_hci_core: Firmware: Standard Bluetooth controller (0x00) Version 118.8444 Build 2485848728
[00:00:06.236,114] <inf> bt_hci_core: No ID address. App must call settings_load()
[00:00:06.239,410] <inf> bt_hci_core: Identity: f5:8f:aa:41:a7:6f (random)
[00:00:06.239,440] <inf> bt_hci_core: HCI: version 5.2 (0x0b) revision 0xfffe, manufacturer 0x0059
[00:00:06.239,471] <inf> bt_hci_core: LMP: version 5.2 (0x0b) subver 0xfffe

I built it pristine:

cd zephyr/tests/bluetooth/shell
west build -b nrf52840dk_nrf52840 -p -- -DCONFIG_BT_LL_NRFXLIB=y -DCONFIG_BT_MAX_CONN=2 -DCONFIG_BT_AUTO_PHY_UPDATE=n

Then programmed each with

west flash

uart:~$ bt init
Bluetooth initialized
[00:00:08.633,911] <inf> fs_nvs: 8 Sectors of 4096 bytes
[00:00:08.633,941] <inf> fs_nvs: alloc wra: 0, fb8
[00:00:08.633,941] <inf> fs_nvs: data wra: 0, 33
[00:00:08.634,185] <inf> bt_ctlr_hci_driver: BLE controller build revision: 
76 fc 20 98 0a 2b 94 88  2b 73 12 87 a2 33 84 82 |v. ..+.. +s...3..
c0 62 2d 90                                      |.b-.             
[00:00:08.638,854] <inf> bt_hci_core: HW Platform: Nordic Semiconductor (0x0002)
[00:00:08.638,885] <inf> bt_hci_core: HW Variant: nRF52x (0x0002)
[00:00:08.638,885] <inf> bt_hci_core: Firmware: Standard Bluetooth controller (0x00) Version 118.8444 Build 2485848728
[00:00:08.639,495] <inf> bt_hci_core: No ID address. App must call settings_load()
[00:00:08.642,608] <inf> bt_hci_core: Identity: e7:60:41:d9:f2:72 (random)
[00:00:08.642,608] <inf> bt_hci_core: HCI: version 5.2 (0x0b) revision 0xfffe, manufacturer 0x0059
[00:00:08.642,639] <inf> bt_hci_core: LMP: version 5.2 (0x0b) subver 0xfffe
uart:~$ bt adv-create conn-nscan ext-adv coded
Created adv id: 0, adv: 0x20003944
uart:~$ bt adv-start
Advertiser[0] 0x20003944 set started
uart:~$ bt adv-oob
OOB data:
addr                          random                           confirm                         
   51:5f:d2:2e:0f:7b (random) 686df982a803906ce29111c03fbe2eeb 4d71486896662442092b50f9327d2c3c

uart:~$ bt init
Bluetooth initialized
[00:00:05.886,627] <inf> fs_nvs: 8 Sectors of 4096 bytes
[00:00:05.886,657] <inf> fs_nvs: alloc wra: 0, fc0
[00:00:05.886,657] <inf> fs_nvs: data wra: 0, 29
[00:00:05.886,871] <inf> bt_ctlr_hci_driver: BLE controller build revision: 
76 fc 20 98 0a 2b 94 88  2b 73 12 87 a2 33 84 82 |v. ..+.. +s...3..
c0 62 2d 90                                      |.b-.             
[00:00:05.891,571] <inf> bt_hci_core: HW Platform: Nordic Semiconductor (0x0002)
[00:00:05.891,571] <inf> bt_hci_core: HW Variant: nRF52x (0x0002)
[00:00:05.891,601] <inf> bt_hci_core: Firmware: Standard Bluetooth controller (0x00) Version 118.8444 Build 2485848728
[00:00:05.892,211] <inf> bt_hci_core: No ID address. App must call settings_load()
[00:00:05.895,507] <inf> bt_hci_core: Identity: f5:8f:aa:41:a7:6f (random)
[00:00:05.895,538] <inf> bt_hci_core: HCI: version 5.2 (0x0b) revision 0xfffe, manufacturer 0x0059
[00:00:05.895,568] <inf> bt_hci_core: LMP: version 5.2 (0x0b) subver 0xfffe
uart:~$ bt connect 51:5f:d2:2e:0f:7b (random) coded no-1m
Connection pending
Failed to connect to 51:5f:d2:2e:0f:7b (random) (0x02)

By the way here's the contents of my west list

west list
manifest     pyrinas                      HEAD                                     N/A
nrf          nrf                          v1.3.0                                   https://github.com/nrfconnect/nrf
nanopb       pyrinas/ext/nanopb           0.3.9                                    https://github.com/nanopb/nanopb
zephyr       zephyr                       v2.3.0-rc1-ncs1                          https://github.com/nrfconnect/sdk-zephyr
mcuboot      bootloader/mcuboot           v1.6.0-rc2-ncs1                          https://github.com/nrfconnect/sdk-mcuboot
mcumgr       modules/lib/mcumgr           v0.0.1-ncs2                              https://github.com/nrfconnect/sdk-mcumgr
nrfxlib      nrfxlib                      v1.3.0                                   https://github.com/nrfconnect/sdk-nrfxlib
cmock        test/cmock                   c243b9a7a7b3c471023193992b46cf1bd1910450 https://github.com/ThrowTheSwitch/cmock
unity        test/cmock/vendor/unity      031f3bbe45f8adf504ca3d13e6f093869920b091 https://github.com/ThrowTheSwitch/unity
mbedtls-nrf  mbedtls                      mbedtls-2.16.6                           https://github.com/ARMmbed/mbedtls
cmsis        modules/hal/cmsis            542b2296e6d515b265e25c6b7208e8fea3014f90 https://github.com/zephyrproject-rtos/cmsis
canopennode  modules/lib/canopennode      5c6b0566d56264efd4bf23ed58bc7cb8b32fe063 https://github.com/zephyrproject-rtos/canopennode
ci-tools     tools/ci-tools               da9a2df574094f52d87a03f6393928bdc7dce17c https://github.com/zephyrproject-rtos/ci-tools
civetweb     modules/lib/civetweb         99129c5efc907ea613c4b73ccff07581feb58a7a https://github.com/zephyrproject-rtos/civetweb
fatfs        modules/fs/fatfs             9ee6b9b9511151d0d64a74d532d39c6f2bbd4f16 https://github.com/zephyrproject-rtos/fatfs
hal_nordic   modules/hal/nordic           c84263d8ecc7767b25d9abab9502c9e748d045e9 https://github.com/zephyrproject-rtos/hal_nordic
hal_st       modules/hal/st               5b3ec3e182d4310e8943cc34c6c70ae57d9711da https://github.com/zephyrproject-rtos/hal_st
libmetal     modules/hal/libmetal         3c3c9ec83bbb99390e34f8f2ba273ec86cf2b67c https://github.com/zephyrproject-rtos/libmetal
lvgl         modules/lib/gui/lvgl         74fc2e753a997bd71cefa34dd9c56dcb954b42e2 https://github.com/zephyrproject-rtos/lvgl
mbedtls      modules/crypto/mbedtls       821154171b246f64eaeef3ccc267f58d8274739a https://github.com/zephyrproject-rtos/mbedtls
net-tools    tools/net-tools              1c4fdba512b268033a4cf926bddd323866c3261a https://github.com/zephyrproject-rtos/net-tools
open-amp     modules/lib/open-amp         724f7e2a4519d7e1d40ef330042682dea950c991 https://github.com/zephyrproject-rtos/open-amp
loramac-node modules/lib/loramac-node     29e516ec585b1a909af2b5f1c60d83e7d4d563e3 https://github.com/zephyrproject-rtos/loramac-node
openthread   modules/lib/openthread       a83d18cf18bc8cd431ad6704ad0bf0e6d08c99d7 https://github.com/zephyrproject-rtos/openthread
segger       modules/debug/segger         6fcf61606d6012d2c44129edc033f59331e268bc https://github.com/zephyrproject-rtos/segger
tinycbor     modules/lib/tinycbor         40daca97b478989884bffb5226e9ab73ca54b8c4 https://github.com/zephyrproject-rtos/tinycbor
tinycrypt    modules/crypto/tinycrypt     3e9a49d2672ec01435ffbf0d788db6d95ef28de0 https://github.com/zephyrproject-rtos/tinycrypt
littlefs     modules/fs/littlefs          0aefdda69d236cb01f932117c1f32e9da09c0ec3 https://github.com/zephyrproject-rtos/littlefs
mipi-sys-t   modules/debug/mipi-sys-t     957d46bc3ce0d5f628f0d525196bb4db207672ee https://github.com/zephyrproject-rtos/mipi-sys-t
nrf_hw_models modules/bsim_hw_models/nrf_hw_models fec69703cb1ca06fcdab6d5fde01274f0fc5c759 https://github.com/zephyrproject-rtos/nrf_hw_models
edtt         tools/edtt                   c39888ff74acf421eeff9a7514fa9b172c3373f7 https://github.com/zephyrproject-rtos/edtt

Both PCA100056 have D0 silicon. (replaced the old ones with what I could get through distribution)

Thank you so much for following up.

joerchan commented 4 years ago

@jaredwolff I had omitted some of the output, I have updated to include everything. It looks like we are on the exact same setup.

The only thing I do differently than you is that i flash with west flash --erase. If that doesn't work then I'm out of ideas as to what is wrong.

Also I left CONFIG_BT_AUTO_PHY_UPDATE enabled which is maybe why things aren't working?

It's not why it wouldn't work. but this option automatically switches over to 2M, which I guess is not what you want.

CONFIG_BT_LL_NRFXLIB vs DCONFIG_BT_LL_NRFXLIB_DEFAULT, this is setting the same thing, but the last one is better, since it supports some additional build configurations (no effect in this case though).

CONFIG_BT_LL_NRFXLIB_VS_INCLUDE This includes the vendor specific HCI support. if you wish to use those.

jaredwolff commented 4 years ago

Hmm I must be doing something silly. I'll give it one more full shot. Such a mystery! Thanks again @joerchan

jaredwolff commented 4 years ago

@joerchan I took another look at this today. Turns out there's some slight hardware differences between the PDK and DK. The one that was the killer was the DEC4 connection to C10:

uart:~$ bt connect 6f:09:d6:aa:cf:d7 (random) coded no-1m
Connection pending
Connected: 6f:09:d6:aa:cf:d7 (random)
Remote LMP version unknown (0x0b) subversion 0x10c7 manufacturer 0x0059
LE Features: 0x0000000000004925 
LE conn  param req: int (0x0018, 0x0028) lat 0 to 42
LE conn param updated: int 0x0028 lat 0 to 42
uart:~$

Not 100% silly, but up there. 😬

Thanks again for all your help on this issue.

zephyrproject-rtos / zephyr

BT_LE_ADV_OPT_EXT_ADV causes bt_le_adv_start to return -22 #26200