Hi Steve,

On Tue, Oct 17, 2017, Johan Hedberg wrote:

On Tue, Oct 17, 2017, Steve Brown wrote:

The samples/bluetooth/mesh fails on my nrf52840_pca10056

Below is the debug output of both the failing and non-failing cases.

I bisected down to:
first bad commit: [aaeff3c165051c15dfa025f1aad82f333395b6d0] 
Bluetooth: Add basic host-side support for HCI vendor extension

Somewhere CONFIG_BT_HCI_VS_EXT defaults to "y". If I set it to "n" in prj.conf, all is well.

I went through the patch in question, and found a leak of a net_buf
object. I wonder if the available buffer count has been so well
fine-tuned that loosing just one causes this issue. Anyway, could you
please try the attached patch (while keeping CONFIG_BT_HCI_VS_EXT=y).
Thanks.

Here's version 2. The first attempt didn't take the account the jump to
a label in the success case. So ignore the earlier and test this one,
please.

Johan

Hi John,

On Tue, 2017-10-17 at 21:08 +0300, Johan Hedberg wrote:

Hi Steve,

On Tue, Oct 17, 2017, Steve Brown wrote:

The samples/bluetooth/mesh fails on my nrf52840_pca10056

Below is the debug output of both the failing and non-failing
cases.

I bisected down to:
first bad commit: [aaeff3c165051c15dfa025f1aad82f333395b6d0] 
Bluetooth: Add basic host-side support for HCI vendor extension

Somewhere CONFIG_BT_HCI_VS_EXT defaults to "y". If I set it to "n"
in prj.conf, all is well.

I went through the patch in question, and found a leak of a net_buf
object. I wonder if the available buffer count has been so well
fine-tuned that loosing just one causes this issue. Anyway, could you
please try the attached patch (while keeping CONFIG_BT_HCI_VS_EXT=y).
Thanks.

Johan

Didn't fix it. Identical log.

Steve

Hi Steve,

On Tue, Oct 17, 2017, Steve Brown wrote:

The samples/bluetooth/mesh fails on my nrf52840_pca10056

Below is the debug output of both the failing and non-failing cases.

I bisected down to:
first bad commit: [aaeff3c165051c15dfa025f1aad82f333395b6d0] 
Bluetooth: Add basic host-side support for HCI vendor extension

Somewhere CONFIG_BT_HCI_VS_EXT defaults to "y". If I set it to "n" in prj.conf, all is well.

I went through the patch in question, and found a leak of a net_buf
object. I wonder if the available buffer count has been so well
fine-tuned that loosing just one causes this issue. Anyway, could you
please try the attached patch (while keeping CONFIG_BT_HCI_VS_EXT=y).
Thanks.

Johan

On 10/17/2017 08:03 PM, Pushpal Sidhu wrote:

Hi All,

I'm trying to convince my company to switch to Zephyr, but the lack of
an actual IDE with a nice graphical debugger startles them (these are
old-school type firmware people who have gotten used to IDEs).

Is there anything people are doing? The biggest stopper is probably
the graphical debugging ability that they may lose e.g. IAR.

Hi,

I am using the eclipse CDT standalone debugger without any issues.

Yannis

On 17.10.2017 19:03, Pushpal Sidhu wrote:

I'm trying to convince my company to switch to Zephyr, but the lack of
an actual IDE with a nice graphical debugger startles them (these are
old-school type firmware people who have gotten used to IDEs).

Is there anything people are doing? The biggest stopper is probably
the graphical debugging ability that they may lose e.g. IAR.

I've been using Eclipse <https://www.eclipse.org/> + "C/C++ Hardware
Debugging" plug-in for a while. It works flawlessly and is reasonably
easy to setup. If you are developing on ARM there is also "GNU MCU
Eclipse <https://gnu-mcu-eclipse.github.io/>" plug-in. I know I'm not
the only one as there is some - limited - support for using Eclipse with
Zephyr.

-- Piotr

The samples/bluetooth/mesh fails on my nrf52840_pca10056

Below is the debug output of both the failing and non-failing cases.

I bisected down to:
first bad commit: [aaeff3c165051c15dfa025f1aad82f333395b6d0] 
Bluetooth: Add basic host-side support for HCI vendor extension

Somewhere CONFIG_BT_HCI_VS_EXT defaults to "y". If I set it to "n" in prj.conf, all is well.

Steve

====== failing log ============
Initializing...
[bt] [INF] hci_vs_init: HW Platform: Nordic Semiconductor (0x0002)
[bt] [INF] hci_vs_init: HW Variant: nRF52x (0x0002)
[bt] [INF] hci_vs_init: Firmware: Standard Bluetooth controller (0x00) Version 1.9 Build 99
[bt] [INF] show_dev_info: Identity: cf:f1:b8:81:59:d0 (random)
[bt] [INF] show_dev_info: HCI: version 5.0 (0x09) revision 0x0000, manufacturer 0xffff
[bt] [INF] show_dev_info: LMP: version 5.0 (0x09) subver 0xffff
Bluetooth initialized
[bt] [INF] bt_mesh_prov_init: Device UUID: 00000000-0000-0000-0000-cff1b88159d0
[bt] [DBG] bt_mesh_scan_enable: (0x20001bb8)
[bt] [DBG] adv_thread: (0x200007f8) started
[bt] [DBG] bt_mesh_proxy_adv_start: (0x200007f8)
[bt] [DBG] adv_thread: (0x200007f8) Proxy Advertising up to 60000 ms
[bt] [DBG] bt_mesh_proxy_prov_enable: (0x20001bb8)
Mesh initialized
[bt] [DBG] beacon_send: (0x20001bb8)
[bt] [DBG] unprovisioned_beacon_send: (0x20001bb8)
[bt] [DBG] bt_mesh_adv_send: (0x20001bb8) type 0x02 len 23: 00d05981b8f1cf00000000000000000000000000000000
[bt] [DBG] bt_mesh_proxy_adv_stop: (0x200007f8) adv_enabled 1
[bt] [DBG] adv_send: (0x200007f8) type 2 len 23: 00d05981b8f1cf00000000000000000000000000000000
[bt] [DBG] adv_send: (0x200007f8) count 3 interval 20ms duration 90ms
[bt] [DBG] pub_key_ready: (0x20000370) Local public key ready
ecc stack (real size 1324): unused 448 usage 876 / 1324 (66 %)
[bt] [DBG] beacon_send: (0x20001bb8)
[bt] [DBG] unprovisioned_beacon_send: (0x20001bb8)
[bt] [DBG] bt_mesh_adv_send: (0x20001bb8) type 0x02 len 23: 00d05981b8f1cf00000000000000000000000000000000
[bt] [DBG] beacon_send: (0x20001bb8)
[bt] [DBG] unprovisioned_beacon_send: (0x20001bb8)
[bt] [DBG] bt_mesh_adv_send: (0x20001bb8) type 0x02 len 23: 00d05981b8f1cf00000000000000000000000000000000
[bt] [DBG] beacon_send: (0x20001bb8)
[bt] [DBG] unprovisioned_beacon_send: (0x20001bb8)
[bt] [DBG] bt_mesh_adv_send: (0x20001bb8) type 0x02 len 23: 00d05981b8f1cf00000000000000000000000000000000
[bt] [DBG] beacon_send: (0x20001bb8)
[bt] [DBG] unprovisioned_beacon_send: (0x20001bb8)
[bt] [DBG] bt_mesh_adv_send: (0x20001bb8) type 0x02 len 23: 00d05981b8f1cf00000000000000000000000000000000
[bt] [DBG] beacon_send: (0x20001bb8)
[bt] [DBG] unprovisioned_beacon_send: (0x20001bb8)
[bt] [DBG] bt_mesh_adv_send: (0x20001bb8) type 0x02 len 23: 00d05981b8f1cf00000000000000000000000000000000
[bt] [DBG] beacon_send: (0x20001bb8)
[bt] [DBG] unprovisioned_beacon_send: (0x20001bb8)
[bt] [DBG] bt_mesh_adv_send: (0x20001bb8) type 0x02 len 23: 00d05981b8f1cf00000000000000000000000000000000
[bt] [DBG] beacon_send: (0x20001bb8)
[bt] [DBG] unprovisioned_beacon_send: (0x20001bb8)
[bt] [DBG] bt_mesh_adv_send: (0x20001bb8) type 0x02 len 23: 00d05981b8f1cf00000000000000000000000000000000
[bt] [DBG] beacon_send: (0x20001bb8)
[bt] [DBG] unprovisioned_beacon_send: (0x20001bb8)
[bt] [DBG] bt_mesh_adv_send: (0x20001bb8) type 0x02 len 23: 00d05981b8f1cf00000000000000000000000000000000
[bt] [DBG] beacon_send: (0x20001bb8)
[bt] [DBG] unprovisioned_beacon_send: (0x20001bb8)
[bt] [DBG] bt_mesh_adv_send: (0x20001bb8) type 0x02 len 23: 00d05981b8f1cf00000000000000000000000000000000
[bt] [DBG] beacon_send: (0x20001bb8)
[bt] [DBG] unprovisioned_beacon_send: (0x20001bb8)
[bt] [DBG] bt_mesh_adv_send: (0x20001bb8) type 0x02 len 23: 00d05981b8f1cf00000000000000000000000000000000
[bt] [DBG] beacon_send: (0x20001bb8)
[bt] [DBG] unprovisioned_beacon_send: (0x20001bb8)
[bt] [DBG] bt_mesh_adv_send: (0x20001bb8) type 0x02 len 23: 00d05981b8f1cf00000000000000000000000000000000
[bt] [DBG] beacon_send: (0x20001bb8)
[bt] [DBG] unprovisioned_beacon_send: (0x20001bb8)
[bt] [DBG] bt_mesh_adv_send: (0x20001bb8) type 0x02 len 23: 00d05981b8f1cf00000000000000000000000000000000
[bt] [DBG] beacon_send: (0x20001bb8)
[bt] [DBG] unprovisioned_beacon_send: (0x20001bb8)
[bt] [DBG] bt_mesh_adv_send: (0x20001bb8) type 0x02 len 23: 00d05981b8f1cf00000000000000000000000000000000
[bt] [DBG] beacon_send: (0x20001bb8)
[bt] [DBG] unprovisioned_beacon_send: (0x20001bb8)
[bt] [DBG] bt_mesh_adv_send: (0x20001bb8) type 0x02 len 23: 00d05981b8f1cf00000000000000000000000000000000
[bt] [DBG] beacon_send: (0x20001bb8)
[bt] [DBG] unprovisioned_beacon_send: (0x20001bb8)
[bt] [DBG] bt_mesh_adv_send: (0x20001bb8) type 0x02 len 23: 00d05981b8f1cf00000000000000000000000000000000
[bt] [DBG] beacon_send: (0x20001bb8)
[bt] [DBG] unprovisioned_beacon_send: (0x20001bb8)
[bt] [DBG] bt_mesh_adv_send: (0x20001bb8) type 0x02 len 23: 00d05981b8f1cf00000000000000000000000000000000
[bt] [DBG] beacon_send: (0x20001bb8)
[bt] [DBG] unprovisioned_beacon_send: (0x20001bb8)
[bt] [DBG] bt_mesh_adv_send: (0x20001bb8) type 0x02 len 23: 00d05981b8f1cf00000000000000000000000000000000
[bt] [DBG] beacon_send: (0x20001bb8)
[bt] [DBG] unprovisioned_beacon_send: (0x20001bb8)
[bt] [DBG] bt_mesh_adv_send: (0x20001bb8) type 0x02 len 23: 00d05981b8f1cf00000000000000000000000000000000
[bt] [DBG] beacon_send: (0x20001bb8)
[bt] [DBG] unprovisioned_beacon_send: (0x20001bb8)
[bt] [DBG] bt_mesh_adv_send: (0x20001bb8) type 0x02 len 23: 00d05981b8f1cf00000000000000000000000000000000
[bt] [DBG] beacon_send: (0x20001bb8)
[bt] [DBG] unprovisioned_beacon_send: (0x20001bb8)
[bt] [ERR] unprovisioned_beacon_send: Unable to allocate beacon buffer

======== successful log =============
adv stack (real size 812): unused 384 usage 428 / 812 (52 %)
Kernel stacks:
main (real size 512): unused 272 usage 240 / 512 (46 %)
idle (real size 320): unused 272 usage 48 / 320 (15 %)
interrupt (real size 2048): unused 1616 usage 432 / 2048 (21 %)
workqueue (real size 2048): unused 1704 usage 344 / 2048 (16 %)
[bt] [DBG] bt_mesh_proxy_adv_start: (0x200007f8)
[bt] [DBG] gatt_proxy_advertise: (0x200007f8)
[bt] [DBG] net_id_adv: (0x200007f8)
[bt] [DBG] net_id_adv: (0x200007f8) Advertising with NetId d47679433fdb104a
[bt] [ERR] net_id_adv: Failed to advertise using Network ID (err -5)
[bt] [DBG] adv_thread: (0x200007f8) Proxy Advertising up to -1 ms
[bt] [DBG] beacon_send: (0x20001bb8)
[bt] [DBG] secure_beacon_send: (0x20001bb8)
[bt] [DBG] bt_mesh_beacon_create: (0x20001bb8) net_idx 0x0000 flags 0x00 NetID d47679433fdb104a
[bt] [DBG] bt_mesh_beacon_create: (0x20001bb8) IV Index 0x00000005 Auth f40a41fab0af320b
[bt] [DBG] bt_mesh_adv_send: (0x20001bb8) type 0x02 len 22: 0100d47679433fdb104a00000005f40a41fab0af320b
[bt] [DBG] bt_mesh_proxy_adv_stop: (0x200007f8) adv_enabled 0
[bt] [DBG] adv_send: (0x200007f8) type 2 len 22: 0100d47679433fdb104a00000005f40a41fab0af320b
[bt] [DBG] adv_send: (0x200007f8) count 1 interval 20ms duration 30ms
[bt] [DBG] beacon_complete: (0x200007f8) err 0
[bt] [DBG] adv_send: (0x200007f8) Advertising started. Sleeping 30 ms
[bt] [DBG] adv_send: (0x200007f8) Advertising stopped
adv stack (real size 812): unused 384 usage 428 / 812 (52 %)
Kernel stacks:
main (real size 512): unused 272 usage 240 / 512 (46 %)
idle (real size 320): unused 272 usage 48 / 320 (15 %)
interrupt (real size 2048): unused 1616 usage 432 / 2048 (21 %)
workqueue (real size 2048): unused 1704 usage 344 / 2048 (16 %)
[bt] [DBG] bt_mesh_proxy_adv_start: (0x200007f8)
[bt] [DBG] gatt_proxy_advertise: (0x200007f8)
[bt] [DBG] net_id_adv: (0x200007f8)
[bt] [DBG] net_id_adv: (0x200007f8) Advertising with NetId d47679433fdb104a
[bt] [ERR] net_id_adv: Failed to advertise using Network ID (err -5)
[bt] [DBG] adv_thread: (0x200007f8) Proxy Advertising up to -1 ms
[bt] [DBG] beacon_send: (0x20001bb8)
[bt] [DBG] secure_beacon_send: (0x20001bb8)
[bt] [DBG] bt_mesh_beacon_create: (0x20001bb8) net_idx 0x0000 flags 0x00 NetID d47679433fdb104a
[bt] [DBG] bt_mesh_beacon_create: (0x20001bb8) IV Index 0x00000005 Auth f40a41fab0af320b
[bt] [DBG] bt_mesh_adv_send: (0x20001bb8) type 0x02 len 22: 0100d47679433fdb104a00000005f40a41fab0af320b
[bt] [DBG] bt_mesh_proxy_adv_stop: (0x200007f8) adv_enabled 0

Hi Pushpal,

We are in the process of switching from Make/Kbuild to CMake. Once this transition is complete it should be possible to generate IDE projects from CMake itself, although the focus initially is on being able to compile from the command-line with CMake first.

As someone mentioned before, Segger Embedded Studio (SES) is a good option and hopefully we’ll get closer to integrating with it and others as the CMake transition ends and we can focus on that area.

Regards,

Carles

Thanks for the suggestion Justin.

Haha, by old school, I meant they are very far removed from CLI
debugging through gdb (which is what I'm used to) as they've been
using tools like IAR for a while. So maybe not old school, but maybe
cli-adverse.

- Pushpal

Hi All,

I'm trying to convince my company to switch to Zephyr, but the lack of
an actual IDE with a nice graphical debugger startles them (these are
old-school type firmware people who have gotten used to IDEs).

Is there anything people are doing? The biggest stopper is probably
the graphical debugging ability that they may lose e.g. IAR.
Preferably something on Windows (so no ddd unless WSL quickly gets to
a better place with USB support).

- Pushpal

Hi all,

I plan to rework GPIO API to fix the issue #2529
https://github.com/zephyrproject-rtos/zephyr/issues/2529. But first I
would like to clean it up a bit.

One thing which is confusing and feels inconsistent are GPIO_PIN_ENABLE,
GPIO_PIN_DISABLE configuration constants.

/*
 * GPIO_PIN_(EN-/DIS-)ABLE are for pin enable / disable.
 *
 * Individual pins can be enabled or disabled
 * if the controller supports this operation.
 */

According to the existing implementation - but not necessarily
description - they are meant to give control over the pin to the GPIO
module or let the pin be controlled by a peripheral. However, this
overlaps functionality provided by the pinmux driver.

Especially GPIO_PIN_DISABLE seems a dangerous option to have since it
gives back control over the pin to a peripheral however gives no way to
choose which peripheral it should be. Pin could become an input or an
output. Pinmux driver handles this in a clean way.

It may be the case that the original meaning of the two constant was
different and they were simply incorrectly implemented. E.g.
GPIO_PIN_DISABLE could mean disconnect pin from the pad. I believe some
SoC support this. If this is the case such option still should go to the
pinmux driver not GPIO one.

In any case the both constants are almost universally ignored by the
existing GPIO device drivers. Out of 17 drivers only 2 take
GPIO_PIN_ENABLE option into account. So in the majority case running
gpio_*_configure function always sets the pin in GPIO mode.

To remove current inconsistencies I propose to deprecate
GPIO_PIN_ENABLE, GPIO_PIN_DISABLE configuration constants. I have
prepared a relevant PR:

https://github.com/zephyrproject-rtos/zephyr/pull/4379

I'm posting this to the list as this is about API and I would like the
topic to have a bit more visibility.

Comments are most welcome.

Regards,
Piotr

Hi Tamra,

On Tue, Oct 17, 2017, Johan Hedberg wrote:

I might be wrong, but I don't think a public address is what you're
looking for, since that address space is formally managed by companies.
Instead, I think you're looking to get a persistent address that stays
the same over reboots. A static random address is also an Identity
Address, so that would fit the bill.

The Nordic controllers come with a pre-programmed static address in
their FICR register, but there's no standard way of reading it from
there through HCI. Luckily, we've now got our own HCI vendor extensions
available which have a command for this. If you build your controller
image out of the latest master branch you will get vendor extensions
support included there. For the host side, I've just pushed a pull
request which adds what's needed:

https://github.com/zephyrproject-rtos/zephyr/pull/4371

This PR is merged now, so simply rebuilding and flashing your nRF51 &
Quark SE Zephyr images from the upstream master branch should yield a
solution where the Bluetooth address remains the same.

Johan

Hi Johan,

Setting CONFIG_BT_MESH_ADV_BUF_COUNT to 7 solved the issue.

Thanks,

Jehudi

2017-10-17 12:26 GMT+02:00 Johan Hedberg <johan.hedberg@...>:

Hi Jehudi,

On Tue, Oct 17, 2017, Laczen JMS wrote:

Thanks for the response. I couldn't find CONFIG_BT_MESH_TX_SEG_COUNT
as configuration option, but I tried changing
CONFIG_BT_MESH_TX_SEG_MSG_COUNT which defaults to 1. I changed it to
10 but I am still getting the Not enough tailroom message. I am using
both 16k and 32k nrf51822, at the moment I am testing with the 32k
version.

Sorry, there's an internal define called BT_MESH_TX_SEG_COUNT, but it
actually gets its value from a different Kconfig variable. From the
transport.h header file:

#define BT_MESH_TX_SEG_COUNT (CONFIG_BT_MESH_ADV_BUF_COUNT - 3)
#define BT_MESH_TX_SDU_MAX (BT_MESH_TX_SEG_COUNT * 12)

So you'll want to increase CONFIG_BT_MESH_ADV_BUF_COUNT by 1 most
likely.

Johan

Hi Johan,

Thanks for the response. I couldn't find CONFIG_BT_MESH_TX_SEG_COUNT
as configuration option, but I tried changing
CONFIG_BT_MESH_TX_SEG_MSG_COUNT which defaults to 1. I changed it to
10 but I am still getting the Not enough tailroom message. I am using
both 16k and 32k nrf51822, at the moment I am testing with the 32k
version.

Kind regards,

Jehudi

2017-10-17 11:41 GMT+02:00 Johan Hedberg <johan.hedberg@...>:

Hi Tamara,

On Sun, Oct 15, 2017, Tamra Oyama wrote:

Does anyone know how to make a device ID public instead of random?

I ran the bluetooth sample, scan_adv, provided by zephyr. Below is what
happens when I run it.

Starting Scanner/Advertiser Demo
[bt] [WRN] set_static_addr: Using temporary static random address
[bt] [INF] show_dev_info: Identity: e3:d8:c2:29:0a:04 (random)
[bt] [INF] show_dev_info: HCI: version 5.0 (0x09) revision 0x0000,
manufacturerf
[bt] [INF] show_dev_info: LMP: version 5.0 (0x09) subver 0xffff
Bluetooth initialized

In the part where it says (random), does anyone know how to make this a
public address or assign an address to the device (tinyTILE in this case)?

Also, would it be possible to instead of using a temporary static random
address, assign an address to the device?

I might be wrong, but I don't think a public address is what you're
looking for, since that address space is formally managed by companies.
Instead, I think you're looking to get a persistent address that stays
the same over reboots. A static random address is also an Identity
Address, so that would fit the bill.

The Nordic controllers come with a pre-programmed static address in
their FICR register, but there's no standard way of reading it from
there through HCI. Luckily, we've now got our own HCI vendor extensions
available which have a command for this. If you build your controller
image out of the latest master branch you will get vendor extensions
support included there. For the host side, I've just pushed a pull
request which adds what's needed:

https://github.com/zephyrproject-rtos/zephyr/pull/4371

Johan

Hi Jehudi,

On Tue, Oct 17, 2017, Laczen JMS wrote:

I am trying to make a bluetooth mesh zephyr node with 2 elements.
After provisioning (which assigns 2 node adresses) meshctl ask for the
composition data. This fails with Not enough tailroom for TransMIC:

[bt] [DBG] dev_comp_data_get: (0x20001950) net_idx 0x0000 app_idx 0xfffe src 0x0
[bt] [ERR] bt_mesh_model_send: Not enough tailroom for TransMIC

What configuration option do I need to change (I am working on nrf51822) ?

I think you need to change CONFIG_BT_MESH_TX_SEG_COUNT. IIRC it defaults
to 3, and with your two elements you've created a composition data that
doesn't fit in three segments anymore. Increasing the SEG_COUNT to 4
will probably fix the issue. Note that this will also increase the
runtime memory consumption, so hopefully that doesn't go over your
limits (IIRC you had 16k?).

Johan

Hi,

I am trying to make a bluetooth mesh zephyr node with 2 elements.
After provisioning (which assigns 2 node adresses) meshctl ask for the
composition data. This fails with Not enough tailroom for TransMIC:

[bt] [DBG] dev_comp_data_get: (0x20001950) net_idx 0x0000 app_idx 0xfffe src 0x0
[bt] [ERR] bt_mesh_model_send: Not enough tailroom for TransMIC

What configuration option do I need to change (I am working on nrf51822) ?

Kind regards,

Jehudi

Hi Steve,

On Sun, Oct 15, 2017, Steve Brown wrote:

The code to conditionally set the gatt_proxy feature bit seems to be
missing in these two functions.

You're right. It's an oversight that needs fixing.

It looks like friend is also missing from comp_get_page_0.

Friend support is not yet complete (there's just a very basic and
incomplete skeleton for it), so this is less of an issue. Something
worth fixing as well though.

Can somebody familiar with the code tell me if this a problem.

I've submitted a PR to fix this:

https://github.com/zephyrproject-rtos/zephyr/pull/4345

That said, you seem to be starting to have a fairly good grasp of the
code, so I welcome you to try to submit fixes/improvements yourself as
well. Even if the fix isn't 100% correct at first we'll sort that out in
the code review phase.

Johan