Date   

Bluetooth Mesh

Vikrant More <vikrant8051@...>
 

I want build Zephyr based lighting system & for testing I have 3 nRF52840-PDK boards.

I've flashed  zephyr/samples/bluetooth/mesh firmware on all three board.
They are advertising themselves as any other GATT peripheral devices.

As per my understanding they are in unprovisioned state. 

Using "NRF connect" Android app I can send data to service (Mesh Provisioning Service) running on it.

I think this service is for provisioning purpose. Am I right ?

How to do provisioning using meshctl utility (BlueZ 5.47) ?

When I execute meshctl on my ubuntu laptop it gives me following error - 

       Local config directory not provided.
   Failed to parse local node configuration file local_node.json

From where I can get this local_node.json which is compatible for nRF52840-PDK ?

I've also posted same Question of Nordic Semi. devzone forum:


Re: I2C is not working for STM-based board

Yannis Damigos
 

Hi Dmitry,

Thanks for catching this. It is a typo.
Could you create a PR on github to fix it?

Yannis

On Tue, Nov 14, 2017 at 9:21 PM, Dmitry Shmidt via Zephyr-devel
<zephyr-devel@lists.zephyrproject.org> wrote:
Hello,

Change for cmake build:

commit 12f8f7616567f224b920512b6f81a65421e30bae
Author: Sebastian Bøe <sebastian.boe@nordicsemi.no>
Date: Fri Oct 27 15:43:34 2017 +0200
Introduce cmake-based rewrite of KBuild

set CONFIG_I2C_STM32_V1x instead of CONFIG_I2C_STM32_V1

Was it intentional or should we use old value like this:

diff --git a/drivers/i2c/CMakeLists.txt b/drivers/i2c/CMakeLists.txt
index 3a544930f..8f8fb67d1 100644
--- a/drivers/i2c/CMakeLists.txt
+++ b/drivers/i2c/CMakeLists.txt
@@ -10,7 +10,7 @@ zephyr_sources_ifdef(CONFIG_I2C_QMSI_SS
i2c_qmsi_ss.c)
zephyr_sources_ifdef(CONFIG_I2C_SAM_TWI i2c_sam_twi.c)
zephyr_sources_ifdef(CONFIG_I2C_SBCON i2c_sbcon.c)

-zephyr_sources_ifdef(CONFIG_I2C_STM32_V1x
+zephyr_sources_ifdef(CONFIG_I2C_STM32_V1
i2c_ll_stm32_v1.c
i2c_ll_stm32.c
)

Thanks,

Dmitry
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


Re: Zephyr flash won't work without usb connection

Michael Rosen
 

Jie,

 

If you flashed your Zephyr application over USB, it should now be in the device’s flash memory and should be loaded and run on every reboot. If you are not seeing the application load when you run the device off external power, that might be a very different issue. But you will not be able to flash it once it has been disconnected.

 

Mike

 

From: Jie Zhou [mailto:zhoujie@...]
Sent: Tuesday, November 14, 2017 5:49 PM
To: Rosen, Michael R <michael.r.rosen@...>; zephyr-devel@...
Subject: Re: [Zephyr-devel] Zephyr flash won't work without usb connection

 

Hi Mike,

I'll investigate on the vin/gnd battery. I also have the flyswatter, but I remember having trouble with flashing with it, so I sticked with the FTDI but will check that out too. Eventually, I would want the board to run the application on power up, so it would require no connection with my computer at all. Zephyr, being a IoT OS, must have this capability. Let me know if anyone else knows how to by pass the need of usb.

Thanks,

Jie 

 

On Tue, Nov 14, 2017 at 1:27 PM, Rosen, Michael R <michael.r.rosen@...> wrote:

Jie,

 

Curie boards generally flash in one of two ways: over JTAG or over USB. In typical uses, they actually flash over the Curie USB interface (using the USB DFU protocol; via dfu-util). That’s why you need USB connected in order to flash the device. Not sure how easy it is to do JTAG flashing on tinyTILE though, it requires a flyswatter2 or similar device for Arduino 101.

 

Not 100% sure of this, but you should be able to connect a battery to the VIN/GND holes of the tinyTILE and leave the USB open for flashing. If you intend to use a USB Battery, then you are somewhat stuck; though there might be ways to do OTA updates using the BLE Radio SoC if you are interested in investigating that…

 

Also note that on boot, there might be a UART flashing mechanism on boot, but I really haven’t done anything with it before and its really an afterthought to the main USB or JTAG mechanisms. It uses the XModem protocol and I think you will likely have to make a script specifically for handling it. But if your needs really merit it, it might be worth the effort. This feature may or may not be there on the default tinyTILE bootloader.

 

Code for the bootloader(s) that run on tinyTILE (or at least a close version to the one on tinyTILE) can be found here: https://github.com/CurieBSP/bootloader

 

Mike

 

 

From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Jie Zhou
Sent: Tuesday, November 14, 2017 3:09 PM
To: zephyr-devel@...
Subject: [Zephyr-devel] Zephyr flash won't work without usb connection

 

Hi all,

I'm flashing my tinyTILE using DFU over FTDI cable. My computer, that has the zephyr applications, is connected to tinyTILE via a FTDI cable as TX & RX and a usb cable as power to the tinyTILE. It flashes fine; however, when I power the board externally so that my computer and tinyTILE is only connected with the FTDI cable, the application will not flash. I was always under the impression that the usb cable only functions as a power source, but it seems to be more than that. Only when the board is connected both by the FTDI and the USB cable will the zephyr application flash to my board. This means I won't be able to flash my zephyr application using battery power which defeats the purpose an IoT OS. I've tried the same with the arduino 101 board and it still does the same thing (wouldn't flash). I must be missing something. Wondering if anyone knows what I'm doing wrong. 

Thanks,

Jie  

 


Re: Zephyr flash won't work without usb connection

Jie Zhou <zhoujie@...>
 

Hi Mike,

I'll investigate on the vin/gnd battery. I also have the flyswatter, but I remember having trouble with flashing with it, so I sticked with the FTDI but will check that out too. Eventually, I would want the board to run the application on power up, so it would require no connection with my computer at all. Zephyr, being a IoT OS, must have this capability. Let me know if anyone else knows how to by pass the need of usb.

Thanks,
Jie 

On Tue, Nov 14, 2017 at 1:27 PM, Rosen, Michael R <michael.r.rosen@...> wrote:

Jie,

 

Curie boards generally flash in one of two ways: over JTAG or over USB. In typical uses, they actually flash over the Curie USB interface (using the USB DFU protocol; via dfu-util). That’s why you need USB connected in order to flash the device. Not sure how easy it is to do JTAG flashing on tinyTILE though, it requires a flyswatter2 or similar device for Arduino 101.

 

Not 100% sure of this, but you should be able to connect a battery to the VIN/GND holes of the tinyTILE and leave the USB open for flashing. If you intend to use a USB Battery, then you are somewhat stuck; though there might be ways to do OTA updates using the BLE Radio SoC if you are interested in investigating that…

 

Also note that on boot, there might be a UART flashing mechanism on boot, but I really haven’t done anything with it before and its really an afterthought to the main USB or JTAG mechanisms. It uses the XModem protocol and I think you will likely have to make a script specifically for handling it. But if your needs really merit it, it might be worth the effort. This feature may or may not be there on the default tinyTILE bootloader.

 

Code for the bootloader(s) that run on tinyTILE (or at least a close version to the one on tinyTILE) can be found here: https://github.com/CurieBSP/bootloader

 

Mike

 

 

From: zephyr-devel-bounces@lists.zephyrproject.org [mailto:zephyr-devel-bounces@lists.zephyrproject.org] On Behalf Of Jie Zhou
Sent: Tuesday, November 14, 2017 3:09 PM
To: zephyr-devel@lists.zephyrproject.org
Subject: [Zephyr-devel] Zephyr flash won't work without usb connection

 

Hi all,

I'm flashing my tinyTILE using DFU over FTDI cable. My computer, that has the zephyr applications, is connected to tinyTILE via a FTDI cable as TX & RX and a usb cable as power to the tinyTILE. It flashes fine; however, when I power the board externally so that my computer and tinyTILE is only connected with the FTDI cable, the application will not flash. I was always under the impression that the usb cable only functions as a power source, but it seems to be more than that. Only when the board is connected both by the FTDI and the USB cable will the zephyr application flash to my board. This means I won't be able to flash my zephyr application using battery power which defeats the purpose an IoT OS. I've tried the same with the arduino 101 board and it still does the same thing (wouldn't flash). I must be missing something. Wondering if anyone knows what I'm doing wrong. 

Thanks,

Jie  



Re: Zephyr flash won't work without usb connection

Michael Rosen
 

Jie,

 

Curie boards generally flash in one of two ways: over JTAG or over USB. In typical uses, they actually flash over the Curie USB interface (using the USB DFU protocol; via dfu-util). That’s why you need USB connected in order to flash the device. Not sure how easy it is to do JTAG flashing on tinyTILE though, it requires a flyswatter2 or similar device for Arduino 101.

 

Not 100% sure of this, but you should be able to connect a battery to the VIN/GND holes of the tinyTILE and leave the USB open for flashing. If you intend to use a USB Battery, then you are somewhat stuck; though there might be ways to do OTA updates using the BLE Radio SoC if you are interested in investigating that…

 

Also note that on boot, there might be a UART flashing mechanism on boot, but I really haven’t done anything with it before and its really an afterthought to the main USB or JTAG mechanisms. It uses the XModem protocol and I think you will likely have to make a script specifically for handling it. But if your needs really merit it, it might be worth the effort. This feature may or may not be there on the default tinyTILE bootloader.

 

Code for the bootloader(s) that run on tinyTILE (or at least a close version to the one on tinyTILE) can be found here: https://github.com/CurieBSP/bootloader

 

Mike

 

 

From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Jie Zhou
Sent: Tuesday, November 14, 2017 3:09 PM
To: zephyr-devel@...
Subject: [Zephyr-devel] Zephyr flash won't work without usb connection

 

Hi all,

I'm flashing my tinyTILE using DFU over FTDI cable. My computer, that has the zephyr applications, is connected to tinyTILE via a FTDI cable as TX & RX and a usb cable as power to the tinyTILE. It flashes fine; however, when I power the board externally so that my computer and tinyTILE is only connected with the FTDI cable, the application will not flash. I was always under the impression that the usb cable only functions as a power source, but it seems to be more than that. Only when the board is connected both by the FTDI and the USB cable will the zephyr application flash to my board. This means I won't be able to flash my zephyr application using battery power which defeats the purpose an IoT OS. I've tried the same with the arduino 101 board and it still does the same thing (wouldn't flash). I must be missing something. Wondering if anyone knows what I'm doing wrong. 

Thanks,

Jie  


Zephyr flash won't work without usb connection

Jie Zhou <zhoujie@...>
 

Hi all,

I'm flashing my tinyTILE using DFU over FTDI cable. My computer, that has the zephyr applications, is connected to tinyTILE via a FTDI cable as TX & RX and a usb cable as power to the tinyTILE. It flashes fine; however, when I power the board externally so that my computer and tinyTILE is only connected with the FTDI cable, the application will not flash. I was always under the impression that the usb cable only functions as a power source, but it seems to be more than that. Only when the board is connected both by the FTDI and the USB cable will the zephyr application flash to my board. This means I won't be able to flash my zephyr application using battery power which defeats the purpose an IoT OS. I've tried the same with the arduino 101 board and it still does the same thing (wouldn't flash). I must be missing something. Wondering if anyone knows what I'm doing wrong. 

Thanks,
Jie  


I2C is not working for STM-based board

Dmitry Shmidt
 

Hello,

Change for cmake build:

commit 12f8f7616567f224b920512b6f81a65421e30bae
Author: Sebastian Bøe <sebastian.boe@nordicsemi.no>
Date: Fri Oct 27 15:43:34 2017 +0200
Introduce cmake-based rewrite of KBuild

set CONFIG_I2C_STM32_V1x instead of CONFIG_I2C_STM32_V1

Was it intentional or should we use old value like this:

diff --git a/drivers/i2c/CMakeLists.txt b/drivers/i2c/CMakeLists.txt
index 3a544930f..8f8fb67d1 100644
--- a/drivers/i2c/CMakeLists.txt
+++ b/drivers/i2c/CMakeLists.txt
@@ -10,7 +10,7 @@ zephyr_sources_ifdef(CONFIG_I2C_QMSI_SS
i2c_qmsi_ss.c)
zephyr_sources_ifdef(CONFIG_I2C_SAM_TWI i2c_sam_twi.c)
zephyr_sources_ifdef(CONFIG_I2C_SBCON i2c_sbcon.c)

-zephyr_sources_ifdef(CONFIG_I2C_STM32_V1x
+zephyr_sources_ifdef(CONFIG_I2C_STM32_V1
i2c_ll_stm32_v1.c
i2c_ll_stm32.c
)

Thanks,

Dmitry


Re: custom script for debug/flash

Raj Gundi
 

Thanks Marti. Will get back to you if I have any more questions.

 

Regards,

Raj

 

From: Marti Bolivar [mailto:marti@...]
Sent: Tuesday, November 14, 2017 8:02 PM
To: Gundi, Rajavardhan <rajavardhan.gundi@...>
Cc: zephyr-devel@...
Subject: Re: custom script for debug/flash

 

Hi Raj,

 

On Tue, Nov 14, 2017 at 1:32 AM, Gundi, Rajavardhan <rajavardhan.gundi@...> wrote:

Hi Marti,

 

I see that you have modified the “debug”, “debugserver” and “flash” scripts to make it OS agnostic. I am working on an xtensa board and I have a dedicated script for this board which is different from the regular xtensa.py that you have created. I have the below questions in order to port my script to the new method.

 

Sure thing, happy to help. 

1)    How is xtensa.py being invoked? In other words if my new script is called myxtensa.py, what I should do to ensure this gets called?

Currently, by creating a subclass of ZephyrBinaryRunner that provides a create_for_shell_script() method which claims compatibility with 'xt-gdb.sh'. (See link to documentation below and the source code for zephyr_flash_debug.py ).

 

The use of this method is a temporary transition so that the rest of the build system wouldn't have to change much to invoke the Python scripts as opposed to the old shell scripts.  The Makefile / Makefile.inc changes in this patch hopefully make it more clear what happened:

 

 

Now that the build system has switched to CMake, it's less clear what's going on. My next goal is to change the interface to zephyr_flash_debug.py so it doesn't rely on environment variables and just takes command line arguments instead. This will allow removing the create_for_shell_script() method.

 

One important gotcha is that your module currently must be imported so the ZephyrBinaryRunner subclass is found. See scripts/support/runner/__init__.py for an example.

 

2)    Is there documentation on how to write the script? I looked at what’s there in the comments, but is that enough? If yes, I’ll go over them again.

Well, I hope so, but if there's anything Zephyr-specific that's missing I hope you'll let me know, and I'll try to improve it.

 

Here is the main documentation for ZephyrBinaryRunner, which is the most important class:

 

 

I'll try to make time to add some of this information to Zephyr's Sphinx documentation as well.

 

3)    My script is heavily making use of Linux shell scripting. It makes use of kill, sleep, Ctrl+C etc. Any pointers on how to achieve these now?

 

Luckily, Python has good cross-platform support for dealing with operating system facilities like sleeping and signals. Since Zephyr is moving to Python 3 over shell scripts, some research on your part will be needed. I suggest taking a look at the Python documentation and searching around on things like StackOverflow, and looking at the existing implementations for examples.

 

Thanks,

Marti

 

Regards,

Raj

 


Re: custom script for debug/flash

Marti Bolivar
 

Hi Raj,

On Tue, Nov 14, 2017 at 1:32 AM, Gundi, Rajavardhan <rajavardhan.gundi@...> wrote:

Hi Marti,

 

I see that you have modified the “debug”, “debugserver” and “flash” scripts to make it OS agnostic. I am working on an xtensa board and I have a dedicated script for this board which is different from the regular xtensa.py that you have created. I have the below questions in order to port my script to the new method.


Sure thing, happy to help. 

1)    How is xtensa.py being invoked? In other words if my new script is called myxtensa.py, what I should do to ensure this gets called?

Currently, by creating a subclass of ZephyrBinaryRunner that provides a create_for_shell_script() method which claims compatibility with 'xt-gdb.sh'. (See link to documentation below and the source code for zephyr_flash_debug.py ).

The use of this method is a temporary transition so that the rest of the build system wouldn't have to change much to invoke the Python scripts as opposed to the old shell scripts.  The Makefile / Makefile.inc changes in this patch hopefully make it more clear what happened:


Now that the build system has switched to CMake, it's less clear what's going on. My next goal is to change the interface to zephyr_flash_debug.py so it doesn't rely on environment variables and just takes command line arguments instead. This will allow removing the create_for_shell_script() method.

One important gotcha is that your module currently must be imported so the ZephyrBinaryRunner subclass is found. See scripts/support/runner/__init__.py for an example.

2)    Is there documentation on how to write the script? I looked at what’s there in the comments, but is that enough? If yes, I’ll go over them again.

Well, I hope so, but if there's anything Zephyr-specific that's missing I hope you'll let me know, and I'll try to improve it.

Here is the main documentation for ZephyrBinaryRunner, which is the most important class:


I'll try to make time to add some of this information to Zephyr's Sphinx documentation as well.

3)    My script is heavily making use of Linux shell scripting. It makes use of kill, sleep, Ctrl+C etc. Any pointers on how to achieve these now?


Luckily, Python has good cross-platform support for dealing with operating system facilities like sleeping and signals. Since Zephyr is moving to Python 3 over shell scripts, some research on your part will be needed. I suggest taking a look at the Python documentation and searching around on things like StackOverflow, and looking at the existing implementations for examples.

Thanks,
Marti
 

Regards,

Raj



custom script for debug/flash

Raj Gundi
 

Hi Marti,

 

I see that you have modified the “debug”, “debugserver” and “flash” scripts to make it OS agnostic. I am working on an xtensa board and I have a dedicated script for this board which is different from the regular xtensa.py that you have created. I have the below questions in order to port my script to the new method.

1)    How is xtensa.py being invoked? In other words if my new script is called myxtensa.py, what I should do to ensure this gets called?

2)    Is there documentation on how to write the script? I looked at what’s there in the comments, but is that enough? If yes, I’ll go over them again.

3)    My script is heavily making use of Linux shell scripting. It makes use of kill, sleep, Ctrl+C etc. Any pointers on how to achieve these now?

Regards,

Raj


mcuboot serial recovery feature for zephyr targets - PR is open

Puzdrowski, Andrzej
 

Hi.

 

I’ve ported boot serial recovery feature which had been originally provided for mynewt targets.

Tools needed for create the image and transfer it to the FWU target are the same as for mynewt target.

 

PR: https://github.com/runtimeco/mcuboot/pull/152

 

For achieving this following changes were applied:

  • added tinycbor and cborattr library for zephyr. Tinycbor lib from mynewt is imported because it is already modified for support boot-serial module.
  • added serial adapter module for support serial communication for zephyr
  • Modified boot_serial module for using, zephyr-os modules
    (crc driver, mbedtls-base64 library) and the zephyr serial adapter module
    introduced recently.
  • Added service of boot serial recovery mode to main.
  • Adapted the input parser to using static buffers.
  • Added defines for map to memory allocation API of zephyr.
  • Added Kconfig for zephyr-mcuboot project for configuring it in easy way.

remarks:

  • For using serial recovery feature flash region for bootloader must be extended which is introduced in zephyr PR zephyrproject-rtos/zephyr#4765
  • console driver can't use uart along with serial recovery. It’s because the serial adapter module use uart resources. It is possible to use segger RTT instead. This remarks mostly should applies to these devices with one uart supported (as nRF5x) – for devices with multiple uart supported there is maybe possible to configure it different, but I didn’t test this because of lack of hardware on my desk.

 


So far I have tested patch on nrf52_pca10040 and nrf52840_pca10056 targets.

 

How to build mcuboot: Just source the zephyr enviromet repo as usual (source ./zephyr-env.sh), then go to mcuboot root directory and build it normally using make BOARD=…. Please check and correct the configuration using menuconfig prior the final build.

Compile an application project with following settings:

-          CONFIG_TEXT_SECTION_OFFSET=0x200 //shift vector table form the image begin, this could be diferent for other targets

-          add board.dts overlay file:
Put into the project's top makefile the path to the overlays directory:

-          DTC_OVERLAY_DIR := $(CURDIR)/<a-board_overlay_directory>
...
export DTC_OVERLAY_DIR

-          add the file <a-board.overlay> with payload:

/ {

            chosen {

zephyr,code-partition = &slot0_partition;

            };

};

(example here: https://github.com/linaro-technologies/zephyr-fota-samples/blob/ltd-17.07/dm-hawkbit-mqtt/boards/nrf52840_pca10056.overlay)

Apart from that compile app normally.

Image creating:

For prepare the image use imgtool form mcuboot dirtectory, example of cmd: ./scripts/imgtool.py sign -k ./root-rsa-2048.pem -H 0x200 --included-header --version 3.0 --align 8 ../zephyr/samples/basic/blinky/outdir/nrf52_pca10040/zephyr.bin zephyr_img_nrf52.bin

-H parameters value must be the same as CONFIG_TEXT_SECTION_OFFSET value

Image download:

For testing the upload it is need to compile newtmgr application form master (unless released one doesn't expose -e option for image upload subcommand. Expected command is: <executable_dir>/newtmgr image upload -e <signed_image-path> -c <your_serial_profile_name>

 

Andrzej Puzdrowski

 

 


Re: bluetooth: mesh: sample won't provision

Johan Hedberg
 

Hi Steve,

On Sun, Nov 12, 2017, Steve Brown wrote:
It looks like set_param.filter_policy isn't initialized in
hci_core.c:bt_le_adv_start.

With the mesh sample, it has 0x02 in it, which is "connectable only
from whitelist".

If I initialize it to 0x00, "connect from any", all is well.

I guess previously when the buffer was dynamically allocated, it must
have got cleared.
That's a good catch. Thanks for investigating this. It seems also the
scan parameters suffer of the same issue. I've uploaded a pull request
that should fix both cases:

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

Johan


Re: bluetooth: mesh: sample won't provision

Steve Brown
 

Hi All,

It looks like set_param.filter_policy isn't initialized in
hci_core.c:bt_le_adv_start.

With the mesh sample, it has 0x02 in it, which is "connectable only
from whitelist".

If I initialize it to 0x00, "connect from any", all is well.

I guess previously when the buffer was dynamically allocated, it must
have got cleared.

Steve

On Sat, 2017-11-11 at 20:12 +0100, Arthur Mühlbeier wrote:
Hello Vinayak,
I set CONFIG_BT_CTLR_RX_BUFFERS=6. Does the order play a role?
Because I just appended
CONFIG_BT_DEBUG_HCI_DRIVER=y
CONFIG_BT_DEBUG_HCI_CORE=y
CONFIG_BT_HCI_CMD_COUNT=4
CONFIG_BT_CTLR_RX_BUFFERS=6
to prj.conf. I still got the error.

Arthur

On 11.11.2017 19:26, Vinayak Kariappa wrote:
Hi Steve,

Could you increase the controller rx buffer counts from 1 (if that
is what the default you use) to something high, like say 6.

Connection failed could be that the controller did not have free rx
buffer, may be due to HCI not releasing back buffers to controller
(controller shares buffer from single pool for all upstream
messages, scan state, master and slave roles etc.).

nRF51 is slower MCU and you might have uncovered some race
conditions in nRF52, which is faster MCU

Regards,
Vinayak

Sent from my iPhone

On 11 Nov 2017, at 17:51, Arthur Mühlbeier <arthur.muehlbeier@fh-
dortmund.de> wrote:

Hello Johan and Steve,

I set CONFIG_BT_HCI_CMD_COUNT=4 and set
CONFIG_BT_DEBUG_HCI_DRIVER=y and CONFIG_BT_DEBUG_HCI_CORE=y.
bluetoothctl shows when I try to Provision:
[CHG] Controller 4C:34:88:11:DB:B2 Discovering: no
[CHG] Device C0:68:94:2E:82:2E RSSI is nil
[CHG] Device C0:68:94:2E:82:2E Connected: yes
[CHG] Device C0:68:94:2E:82:2E Connected: no

The UART Log is empty in that time. I start scanning, find the
device, I start the UART-Log, start Provisioning, see the error
in meshctl and stop the log asap. And it is empty.
If I wait 1 second I see this log https://pastebin.com/gQ62Cndb

Arthur


On 11.11.2017 17:12, Johan Hedberg wrote:
Hi Steve,

On Sat, Nov 11, 2017, Steve Brown wrote:
It looks like it's specific to the Nordic nrf52, as Arthur
says his
nrf51 works fine.

I only have a bunch of nrf52's and they don't.

I suspect the commit has uncovered a bug in some nrf52-
specific low
level code.
Ah, I missed this detail in Arthur's mail. Unfortunately all my
nRF52
boards are at the office, so I'll only be able to attempt
reproducing
this on Monday. Meanwhile, what would help is to enable debug
logs of
the controller (CONFIG_BT_DEBUG_HCI_DRIVER=y) and hci_core.c
(CONFIG_BT_DEBUG_HCI_CORE=y). It would also be helpful if you
manage to
get HCI logs of what's happening. Since the commit you found
relates to
HCI command buffers, it'd also be interesting to see if
changing the
command buffer count (default is 2) to something else (e.g. 3
or 4). The
Kconfig option for this is CONFIG_BT_HCI_CMD_COUNT.

Johan
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


Re: bluetooth: mesh: sample won't provision

Chettimada, Vinayak Kariappa
 

Hi Arthur,

Order does not matter in prj.conf.

Problem is not in controller then, as Steve in another e-mail mentions a peripheral sample accepts connections.

Regards,
Vinayak

On 11 Nov 2017, at 20:12, Arthur Mühlbeier <arthur.muehlbeier@...> wrote:

Hello Vinayak,

I set CONFIG_BT_CTLR_RX_BUFFERS=6. Does the order play a role? Because I just appended
    CONFIG_BT_DEBUG_HCI_DRIVER=y
    CONFIG_BT_DEBUG_HCI_CORE=y
    CONFIG_BT_HCI_CMD_COUNT=4
    CONFIG_BT_CTLR_RX_BUFFERS=6
to prj.conf. I still got the error.

Arthur

On 11.11.2017 19:26, Vinayak Kariappa wrote:
Hi Steve,

Could you increase the controller rx buffer counts from 1 (if that is what the default you use) to something high, like say 6.

Connection failed could be that the controller did not have free rx buffer, may be due to HCI not releasing back buffers to controller (controller shares buffer from single pool for all upstream messages, scan state, master and slave roles etc.).

nRF51 is slower MCU and you might have uncovered some race conditions in nRF52, which is faster MCU

Regards,
Vinayak

Sent from my iPhone

On 11 Nov 2017, at 17:51, Arthur Mühlbeier <arthur.muehlbeier@...> wrote:

Hello Johan and Steve,

I set CONFIG_BT_HCI_CMD_COUNT=4 and set CONFIG_BT_DEBUG_HCI_DRIVER=y and CONFIG_BT_DEBUG_HCI_CORE=y.
bluetoothctl shows when I try to Provision:
[CHG] Controller 4C:34:88:11:DB:B2 Discovering: no
[CHG] Device C0:68:94:2E:82:2E RSSI is nil
[CHG] Device C0:68:94:2E:82:2E Connected: yes
[CHG] Device C0:68:94:2E:82:2E Connected: no

The UART Log is empty in that time. I start scanning, find the device, I start the UART-Log, start Provisioning, see the error in meshctl and stop the log asap. And it is empty.
If I wait 1 second I see this log https://pastebin.com/gQ62Cndb

Arthur


On 11.11.2017 17:12, Johan Hedberg wrote:
Hi Steve,

On Sat, Nov 11, 2017, Steve Brown wrote:
It looks like it's specific to the Nordic nrf52, as Arthur says his
nrf51 works fine.

I only have a bunch of nrf52's and they don't.

I suspect the commit has uncovered a bug in some nrf52-specific low
level code.
Ah, I missed this detail in Arthur's mail. Unfortunately all my nRF52
boards are at the office, so I'll only be able to attempt reproducing
this on Monday. Meanwhile, what would help is to enable debug logs of
the controller (CONFIG_BT_DEBUG_HCI_DRIVER=y) and hci_core.c
(CONFIG_BT_DEBUG_HCI_CORE=y). It would also be helpful if you manage to
get HCI logs of what's happening. Since the commit you found relates to
HCI command buffers, it'd also be interesting to see if changing the
command buffer count (default is 2) to something else (e.g. 3 or 4). The
Kconfig option for this is CONFIG_BT_HCI_CMD_COUNT.

Johan
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@...
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel

_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@...
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


Re: bluetooth: mesh: sample won't provision

Steve Brown
 

Hi Vanayak,

On Sat, 2017-11-11 at 19:26 +0100, Vinayak Kariappa wrote:
Hi Steve,

Could you increase the controller rx buffer counts from 1 (if that is
what the default you use) to something high, like say 6.

Connection failed could be that the controller did not have free rx
buffer, may be due to HCI not releasing back buffers to controller
(controller shares buffer from single pool for all upstream messages,
scan state, master and slave roles etc.).

nRF51 is slower MCU and you might have uncovered some race conditions
in nRF52, which is faster MCU

Regards,
Vinayak

Sent from my iPhone

On 11 Nov 2017, at 17:51, Arthur Mühlbeier <arthur.muehlbeier@fh-do
rtmund.de> wrote:

Hello Johan and Steve,

I set CONFIG_BT_HCI_CMD_COUNT=4 and set
CONFIG_BT_DEBUG_HCI_DRIVER=y and CONFIG_BT_DEBUG_HCI_CORE=y.
bluetoothctl shows when I try to Provision:
[CHG] Controller 4C:34:88:11:DB:B2 Discovering: no
[CHG] Device C0:68:94:2E:82:2E RSSI is nil
[CHG] Device C0:68:94:2E:82:2E Connected: yes
[CHG] Device C0:68:94:2E:82:2E Connected: no

The UART Log is empty in that time. I start scanning, find the
device, I start the UART-Log, start Provisioning, see the error in
meshctl and stop the log asap. And it is empty.
If I wait 1 second I see this log https://pastebin.com/gQ62Cndb

Arthur


On 11.11.2017 17:12, Johan Hedberg wrote:
Hi Steve,

On Sat, Nov 11, 2017, Steve Brown wrote:
It looks like it's specific to the Nordic nrf52, as Arthur says
his
nrf51 works fine.

I only have a bunch of nrf52's and they don't.

I suspect the commit has uncovered a bug in some nrf52-specific
low
level code.
Ah, I missed this detail in Arthur's mail. Unfortunately all my
nRF52
boards are at the office, so I'll only be able to attempt
reproducing
this on Monday. Meanwhile, what would help is to enable debug
logs of
the controller (CONFIG_BT_DEBUG_HCI_DRIVER=y) and hci_core.c
(CONFIG_BT_DEBUG_HCI_CORE=y). It would also be helpful if you
manage to
get HCI logs of what's happening. Since the commit you found
relates to
HCI command buffers, it'd also be interesting to see if changing
the
command buffer count (default is 2) to something else (e.g. 3 or
4). The
Kconfig option for this is CONFIG_BT_HCI_CMD_COUNT.

Johan
I set CONFIG_BT_CTLR_RX_BUFFERS=6 with the same result on my PCA10056.

FWIW, samples/bluetooth/peripheral performs as expected. It's only the
mesh sample that won't allow connections.

Steve


Re: bluetooth: mesh: sample won't provision

Arthur Mühlbeier <arthur.muehlbeier@...>
 

Hello Vinayak,

I set CONFIG_BT_CTLR_RX_BUFFERS=6. Does the order play a role? Because I just appended
    CONFIG_BT_DEBUG_HCI_DRIVER=y
    CONFIG_BT_DEBUG_HCI_CORE=y
    CONFIG_BT_HCI_CMD_COUNT=4
    CONFIG_BT_CTLR_RX_BUFFERS=6
to prj.conf. I still got the error.

Arthur

On 11.11.2017 19:26, Vinayak Kariappa wrote:
Hi Steve,

Could you increase the controller rx buffer counts from 1 (if that is what the default you use) to something high, like say 6.

Connection failed could be that the controller did not have free rx buffer, may be due to HCI not releasing back buffers to controller (controller shares buffer from single pool for all upstream messages, scan state, master and slave roles etc.).

nRF51 is slower MCU and you might have uncovered some race conditions in nRF52, which is faster MCU

Regards,
Vinayak

Sent from my iPhone

On 11 Nov 2017, at 17:51, Arthur Mühlbeier <arthur.muehlbeier@...> wrote:

Hello Johan and Steve,

I set CONFIG_BT_HCI_CMD_COUNT=4 and set CONFIG_BT_DEBUG_HCI_DRIVER=y and CONFIG_BT_DEBUG_HCI_CORE=y.
bluetoothctl shows when I try to Provision:
[CHG] Controller 4C:34:88:11:DB:B2 Discovering: no
[CHG] Device C0:68:94:2E:82:2E RSSI is nil
[CHG] Device C0:68:94:2E:82:2E Connected: yes
[CHG] Device C0:68:94:2E:82:2E Connected: no

The UART Log is empty in that time. I start scanning, find the device, I start the UART-Log, start Provisioning, see the error in meshctl and stop the log asap. And it is empty.
If I wait 1 second I see this log https://pastebin.com/gQ62Cndb

Arthur


On 11.11.2017 17:12, Johan Hedberg wrote:
Hi Steve,

On Sat, Nov 11, 2017, Steve Brown wrote:
It looks like it's specific to the Nordic nrf52, as Arthur says his
nrf51 works fine.

I only have a bunch of nrf52's and they don't.

I suspect the commit has uncovered a bug in some nrf52-specific low
level code.
Ah, I missed this detail in Arthur's mail. Unfortunately all my nRF52
boards are at the office, so I'll only be able to attempt reproducing
this on Monday. Meanwhile, what would help is to enable debug logs of
the controller (CONFIG_BT_DEBUG_HCI_DRIVER=y) and hci_core.c
(CONFIG_BT_DEBUG_HCI_CORE=y). It would also be helpful if you manage to
get HCI logs of what's happening. Since the commit you found relates to
HCI command buffers, it'd also be interesting to see if changing the
command buffer count (default is 2) to something else (e.g. 3 or 4). The
Kconfig option for this is CONFIG_BT_HCI_CMD_COUNT.

Johan
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@...
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


Re: bluetooth: mesh: sample won't provision

Vinayak Kariappa <vinayak.kariappa@...>
 

Hi Steve,

Could you increase the controller rx buffer counts from 1 (if that is what the default you use) to something high, like say 6.

Connection failed could be that the controller did not have free rx buffer, may be due to HCI not releasing back buffers to controller (controller shares buffer from single pool for all upstream messages, scan state, master and slave roles etc.).

nRF51 is slower MCU and you might have uncovered some race conditions in nRF52, which is faster MCU

Regards,
Vinayak

On 11 Nov 2017, at 17:51, Arthur Mühlbeier <arthur.muehlbeier@fh-dortmund.de> wrote:

Hello Johan and Steve,

I set CONFIG_BT_HCI_CMD_COUNT=4 and set CONFIG_BT_DEBUG_HCI_DRIVER=y and CONFIG_BT_DEBUG_HCI_CORE=y.
bluetoothctl shows when I try to Provision:
[CHG] Controller 4C:34:88:11:DB:B2 Discovering: no
[CHG] Device C0:68:94:2E:82:2E RSSI is nil
[CHG] Device C0:68:94:2E:82:2E Connected: yes
[CHG] Device C0:68:94:2E:82:2E Connected: no

The UART Log is empty in that time. I start scanning, find the device, I start the UART-Log, start Provisioning, see the error in meshctl and stop the log asap. And it is empty.
If I wait 1 second I see this log https://pastebin.com/gQ62Cndb

Arthur


On 11.11.2017 17:12, Johan Hedberg wrote:
Hi Steve,

On Sat, Nov 11, 2017, Steve Brown wrote:
It looks like it's specific to the Nordic nrf52, as Arthur says his
nrf51 works fine.

I only have a bunch of nrf52's and they don't.

I suspect the commit has uncovered a bug in some nrf52-specific low
level code.
Ah, I missed this detail in Arthur's mail. Unfortunately all my nRF52
boards are at the office, so I'll only be able to attempt reproducing
this on Monday. Meanwhile, what would help is to enable debug logs of
the controller (CONFIG_BT_DEBUG_HCI_DRIVER=y) and hci_core.c
(CONFIG_BT_DEBUG_HCI_CORE=y). It would also be helpful if you manage to
get HCI logs of what's happening. Since the commit you found relates to
HCI command buffers, it'd also be interesting to see if changing the
command buffer count (default is 2) to something else (e.g. 3 or 4). The
Kconfig option for this is CONFIG_BT_HCI_CMD_COUNT.

Johan
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


Re: bluetooth: mesh: sample won't provision

Arthur Mühlbeier <arthur.muehlbeier@...>
 

Hello Johan and Steve,

I set CONFIG_BT_HCI_CMD_COUNT=4 and set CONFIG_BT_DEBUG_HCI_DRIVER=y and CONFIG_BT_DEBUG_HCI_CORE=y.
bluetoothctl shows when I try to Provision:
[CHG] Controller 4C:34:88:11:DB:B2 Discovering: no
[CHG] Device C0:68:94:2E:82:2E RSSI is nil
[CHG] Device C0:68:94:2E:82:2E Connected: yes
[CHG] Device C0:68:94:2E:82:2E Connected: no

The UART Log is empty in that time. I start scanning, find the device, I start the UART-Log, start Provisioning, see the error in meshctl and stop the log asap. And it is empty.
If I wait 1 second I see this log https://pastebin.com/gQ62Cndb

Arthur

On 11.11.2017 17:12, Johan Hedberg wrote:
Hi Steve,

On Sat, Nov 11, 2017, Steve Brown wrote:
It looks like it's specific to the Nordic nrf52, as Arthur says his
nrf51 works fine.

I only have a bunch of nrf52's and they don't.

I suspect the commit has uncovered a bug in some nrf52-specific low
level code.
Ah, I missed this detail in Arthur's mail. Unfortunately all my nRF52
boards are at the office, so I'll only be able to attempt reproducing
this on Monday. Meanwhile, what would help is to enable debug logs of
the controller (CONFIG_BT_DEBUG_HCI_DRIVER=y) and hci_core.c
(CONFIG_BT_DEBUG_HCI_CORE=y). It would also be helpful if you manage to
get HCI logs of what's happening. Since the commit you found relates to
HCI command buffers, it'd also be interesting to see if changing the
command buffer count (default is 2) to something else (e.g. 3 or 4). The
Kconfig option for this is CONFIG_BT_HCI_CMD_COUNT.

Johan


Re: bluetooth: mesh: sample won't provision

Johan Hedberg
 

Hi Steve,

On Sat, Nov 11, 2017, Steve Brown wrote:
It looks like it's specific to the Nordic nrf52, as Arthur says his
nrf51 works fine.

I only have a bunch of nrf52's and they don't.

I suspect the commit has uncovered a bug in some nrf52-specific low
level code.
Ah, I missed this detail in Arthur's mail. Unfortunately all my nRF52
boards are at the office, so I'll only be able to attempt reproducing
this on Monday. Meanwhile, what would help is to enable debug logs of
the controller (CONFIG_BT_DEBUG_HCI_DRIVER=y) and hci_core.c
(CONFIG_BT_DEBUG_HCI_CORE=y). It would also be helpful if you manage to
get HCI logs of what's happening. Since the commit you found relates to
HCI command buffers, it'd also be interesting to see if changing the
command buffer count (default is 2) to something else (e.g. 3 or 4). The
Kconfig option for this is CONFIG_BT_HCI_CMD_COUNT.

Johan


Re: bluetooth: mesh: sample won't provision

Steve Brown
 

A little more info.

On Sat, 2017-11-11 at 17:19 +0200, Johan Hedberg wrote:
Hi Arthur,

It could be related to a combined controller-host build then, since I
only tried with qemu (with Zephyr controller on a separate board).
I'll
look more into this. The commit you've found seems strange, since all
it
does is it relieves pressure on the HCI command pool by not holding
buffers unnecessarily allocated (something that was causing deadlocks
for me when testing Mesh LPN functionality).

Johan

On Sat, Nov 11, 2017, Arthur Mühlbeier wrote:
Hello Johan,

I just tried again. I am on the latest master branch. I compile and
flash
with
$ cmake -DBOARD=nrf51_pca10028 ..
$ make
$ make flash BOARD=nrf51_pca10028
I can provision the node with meshctl.
Exact the same branch, just another outfolder for nrf52 I compile
and flash
with
$ cmake -DBOARD=nrf52_pca10040 ..
$ make
$ make flash BOARD=nrf52_pca10040
I can not provision the device. I tried to provision with Silicon
Labs App
(.output_size = 0 and the other .output_actions and .output_numbers
commented out) and it will not work there.
After I reverted the commit (Bluetooth: Fix deadlock-risky HCI
command
buffer allocation) like Steve said it works.

Arthur


Am 11.11.2017 um 14:15 schrieb Johan Hedberg:
Hi Steve,

On Sat, Nov 11, 2017, Steve Brown wrote:
It's no longer possible to connect to the proxy using meshctl.

I bisected it to commit
68f6b59e2d5ccc4a0e8feba85d69fb8b08f4667c

(Bluetooth: Fix deadlock-risky HCI command buffer allocation)
I just ran GATT provisioning successfully both with the PTS as
well as
with meshctl. Are you sure you're using the latest master branch?
There's been a whole bunch of Mesh fixes that went in yesterday.

Johan
If I connect w/ bluetoothctl, I get a connection, but it is immediately
terminated. Below is a btmon of the exchange.

I'm not sure why some of the events appear to be duplicated.

Anybody see anything fishy?

Steve

< HCI Command: LE Create Connection (0x08|0x000d) plen 25 #27 [hci0] 23.410334
Scan interval: 60.000 msec (0x0060)
Scan window: 60.000 msec (0x0060)
Filter policy: White list is not used (0x00)
Peer address type: Random (0x01)
Peer address: CF:F1:B8:81:59:D0 (Static)
Own address type: Public (0x00)
Min connection interval: 50.00 msec (0x0028)
Max connection interval: 70.00 msec (0x0038)
Connection latency: 0 (0x0000)
Supervision timeout: 420 msec (0x002a)
Min connection length: 0.000 msec (0x0000)
Max connection length: 0.000 msec (0x0000)
HCI Event: Command Status (0x0f) plen 4 #28 [hci0] 23.411132
LE Create Connection (0x08|0x000d) ncmd 1
Status: Success (0x00)
HCI Event: LE Meta Event (0x3e) plen 19 #29 [hci0] 25.394229
LE Connection Complete (0x01)
Status: Success (0x00)
Handle: 64
Role: Master (0x00)
Peer address type: Random (0x01)
Peer address: CF:F1:B8:81:59:D0 (Static)
Connection interval: 67.50 msec (0x0036)
Connection latency: 0 (0x0000)
Supervision timeout: 420 msec (0x002a)
Master clock accuracy: 0x00
@ MGMT Event: Device Connected (0x000b) plen 42 {0x0002} [hci0] 25.394285
LE Address: CF:F1:B8:81:59:D0 (Static)
Flags: 0x00000000
Data length: 29
Flags: 0x06
LE General Discoverable Mode
BR/EDR Not Supported
16-bit Service UUIDs (complete): 1 entry
Mesh Provisioning (0x1827)
Service Data (UUID 0x1827): d05981b8f1cf000000000000000000000000
@ MGMT Event: Device Connected (0x000b) plen 42 {0x0001} [hci0] 25.394285
LE Address: CF:F1:B8:81:59:D0 (Static)
Flags: 0x00000000
Data length: 29
Flags: 0x06
LE General Discoverable Mode
BR/EDR Not Supported
16-bit Service UUIDs (complete): 1 entry
Mesh Provisioning (0x1827)
Service Data (UUID 0x1827): d05981b8f1cf000000000000000000000000
< HCI Command: LE Read Remote Used Features (0x08|0x0016) plen 2 #30 [hci0] 25.394554
Handle: 64
HCI Event: Command Status (0x0f) plen 4 #31 [hci0] 25.395700
LE Read Remote Used Features (0x08|0x0016) ncmd 1
Status: Success (0x00)
HCI Event: LE Meta Event (0x3e) plen 12 #32 [hci0] 25.852989
LE Read Remote Used Features (0x04)
Status: Connection Failed to be Established (0x3e)
Handle: 64
Features: 0x1f 0x00 0x00 0x00 0x00 0x00 0x00 0x00
LE Encryption
Connection Parameter Request Procedure
Extended Reject Indication
Slave-initiated Features Exchange
LE Ping
HCI Event: Disconnect Complete (0x05) plen 4 #33 [hci0] 25.853618
Status: Success (0x00)
Handle: 64
Reason: Connection Failed to be Established (0x3e)
@ MGMT Event: Device Disconnected (0x000c) plen 8 {0x0002} [hci0] 25.883248
LE Address: CF:F1:B8:81:59:D0 (Static)
Reason: Unspecified (0x00)
@ MGMT Event: Device Disconnected (0x000c) plen 8 {0x0001} [hci0] 25.883248
LE Address: CF:F1:B8:81:59:D0 (Static)
Reason: Unspecified (0x00)
@ MGMT Command: Start Discovery (0x0023) plen 1 {0x0001} [hci0] 30.909023
Address type: 0x07
BR/EDR
LE Public
LE Random

4181 - 4200 of 7812