Date   

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


Re: bluetooth: mesh: sample won't provision

Steve Brown
 

Hi Arthur, Johan,

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
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.

I'll look, but don't expect much.

Steve


Re: bluetooth: mesh: sample won't provision

Johan Hedberg
 

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
_______________________________________________
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,

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
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


Re: bluetooth: mesh: sample won't provision

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


Re: bluetooth: mesh: sample won't provision

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

Hello Steve,

I have also noticed this problem yesterday and posted it on #zephyrproject. I have this problem with the device nrf52_pca10040 but with the device nrf51_pca10028 it still works.
But I could not tell which commit let to the problem.
Thank you for the information.

Arthur


Am 11.11.2017 um 13:28 schrieb Steve Brown:

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)

Steve

[meshctl]# discover-unprovisioned on
set_scan_filter_uuids 00001827-0000-1000-8000-00805f9b34fb
SetDiscoveryFilter success
Discovery started
Adapter property changed
[CHG] Controller B8:27:EB:06:2E:57 Discovering: yes
Mesh Provisioning Service (00001827-0000-1000-8000-00805f9b34fb)
Device UUID: dddd0000000000000000000000000000
OOB: 0000
[NEW] Device CF:F1:B8:81:59:D0 Zephyr
[meshctl]# provision dddd0000000000000000000000000000
Trying to connect Device CF:F1:B8:81:59:D0 Zephyr
Adapter property changed
[CHG] Controller B8:27:EB:06:2E:57 Discovering: no
[Zephyr]# Failed to connect: org.bluez.Error.Failed

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


bluetooth: mesh: sample won't provision

Steve Brown
 

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)

Steve

[meshctl]# discover-unprovisioned on
set_scan_filter_uuids 00001827-0000-1000-8000-00805f9b34fb
SetDiscoveryFilter success
Discovery started
Adapter property changed
[CHG] Controller B8:27:EB:06:2E:57 Discovering: yes
Mesh Provisioning Service (00001827-0000-1000-8000-00805f9b34fb)
Device UUID: dddd0000000000000000000000000000
OOB: 0000
[NEW] Device CF:F1:B8:81:59:D0 Zephyr
[meshctl]# provision dddd0000000000000000000000000000
Trying to connect Device CF:F1:B8:81:59:D0 Zephyr
Adapter property changed
[CHG] Controller B8:27:EB:06:2E:57 Discovering: no
[Zephyr]# Failed to connect: org.bluez.Error.Failed


Re: New HTTP Library Issue

Michael Scott
 



On 11/10/2017 11:37 AM, Paul Sokolovsky wrote:
Hello Michael,


As a quick reply, I always told Jukka that we should have more complete
HTTP support, and ideally, design it from the the simplest to the more
complex things, i.e. starting with HTTP/1.0 and (implied) Connection:
Close. Chunked encoding, presence of Content-Length should be
selectable by user.

See also below.

On Fri, 10 Nov 2017 10:39:39 -0800
Michael Scott <michael@...> wrote:

Hello Jukka / Paul,

We are using the legacy HTTP API's current and include a 
"Content-Length:" header field to denote the amount of data in the
payload.

The new API is completely broken when including the Content-Length 
header field, as the payload is sent in a chunked format which
prepends the byte count to each "chunk".  This means that the user's 
Content-Length value is now invalid.
So, out of my memory, I don't remember (or maybe even know) how the HTTP
standard handles Content-Length in the case of chunked encoding. I'd
think it should be just the same as in the case of non-chunked case,
i.e. the actual length of user data, without Transfer-Encoding
overhead. Is this what you see or don't? Can you please open a ticket
describing step by step what you do and what you see? We then may need
to consult the standard to see how it should be done and change it
accordingly, preferrably, while implement the complete feature matrix
re: Content-Length vs Transfer-Encoding: chunked vs Connection: close.

Per: https://tools.ietf.org/html/rfc7230

"A sender MUST NOT send a Content-Length header field in any
message that contains a Transfer-Encoding header field."

-- Mike


I'm not really sure how to solve this issue in the new API.. I don't 
think we should be changing the payload of the message w/o the user 
opting in or knowing about it.
IMHO, Transfer-Encoding: chunked is an option. There should be a way to
not use it, and IMHO, that way should be the default (i.e. the only
case when Transfer-Encoding: chunked is needed is when user doesn't set
Content-Length yet expressed preference for HTTP1.1-style pipelined
persistent connections.

I can get our code running on the new API if I comment out the
chunked insertion logic and apply the HTTP lib payload patch here: 
https://github.com/zephyrproject-rtos/zephyr/pull/4882
Added comments there, I'd suggest to redo it in a more KISS manner
for now.

- Mike




4201 - 4220 of 7825