Date   

Re: Any plan to support ST BlueNRG chips?

Erwan Gouriou
 

Hi Aaron,

BlueNRG chip are actually already supported (even if deeper testing would be welcome).
To activate it, you could have a look to Disco L475 IoT board configuration.

Cheers
Erwan



Any plan to support ST BlueNRG chips?

Aaron Xu
 

Hi,

I saw zephyr will support ST BlueNRG in 1.8 in a PPT file. 
But looks zephyr still did't support it.

Do you any information about supporting BlueNRG planing?


Regards,
Aaron


Re: Bluetooth mesh_demo crashes

Johan Hedberg
 

On Mon, Oct 09, 2017, Steve Brown wrote:
Yes, it looks indeed like there's a missing initialization of this
queue. I think this is a regression that slipped in at some point in
the recent past, and got uncovered now when the local network
interface is always enabled (instead of being behind a Kconfig
option).

Instead of calling k_fifo_init however, I think it's more efficient
to use a static initializer for this like I've done in the attached
patch. Can you confirm that this also fixes the issue for you? I'll
then create a pull request out of it.
It did fix the problem.
Thanks for testing! The PR is here:

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

Johan


Re: Bluetooth mesh_demo crashes

Steve Brown
 

Johan,

On Mon, 2017-10-09 at 19:22 +0300, Johan Hedberg wrote:
Hi Steve,

On Mon, Oct 09, 2017, Steve Brown wrote:
The sample mesh_demo crashes on my nrf52840_pca10056 during
configuration with a data access violation.

It looks like it's caused by bt_mesh.local_queue not being
initialized.

I added a k_fifo_init to mesh/net.c:bt_mesh_net_init and it seemed
to
correct the problem.

Can somebody familiar with the code confirm this?
Yes, it looks indeed like there's a missing initialization of this
queue. I think this is a regression that slipped in at some point in
the
recent past, and got uncovered now when the local network interface
is
always enabled (instead of being behind a Kconfig option).

Instead of calling k_fifo_init however, I think it's more efficient
to
use a static initializer for this like I've done in the attached
patch.
Can you confirm that this also fixes the issue for you? I'll then
create
a pull request out of it.

Johan
It did fix the problem.

Thanks,

Steve


Re: Bluetooth mesh_demo crashes

Johan Hedberg
 

Hi Steve,

On Mon, Oct 09, 2017, Steve Brown wrote:
The sample mesh_demo crashes on my nrf52840_pca10056 during
configuration with a data access violation.

It looks like it's caused by bt_mesh.local_queue not being initialized.

I added a k_fifo_init to mesh/net.c:bt_mesh_net_init and it seemed to
correct the problem.

Can somebody familiar with the code confirm this?
Yes, it looks indeed like there's a missing initialization of this
queue. I think this is a regression that slipped in at some point in the
recent past, and got uncovered now when the local network interface is
always enabled (instead of being behind a Kconfig option).

Instead of calling k_fifo_init however, I think it's more efficient to
use a static initializer for this like I've done in the attached patch.
Can you confirm that this also fixes the issue for you? I'll then create
a pull request out of it.

Johan


Bluetooth mesh_demo crashes

Steve Brown
 

The sample mesh_demo crashes on my nrf52840_pca10056 during
configuration with a data access violation.

It looks like it's caused by bt_mesh.local_queue not being initialized.

I added a k_fifo_init to mesh/net.c:bt_mesh_net_init and it seemed to
correct the problem.

Can somebody familiar with the code confirm this?

Thanks,

Steve


Re: Is there tutorials for Zephyr ticker/mayfly?

Chettimada, Vinayak Kariappa
 

Hi biwa,

 

There are no tutorial or documentation of ticker or mayfly in the Zephyr repository.

 

Ticker and Mayfly implementation are specific to BLE controller scheduling and they are barebones implementation contributed to Zephyr Project.

We are constantly refactoring the implementation to use Zephyr OS features.

 

Some of the continued issues needing contributions are:

https://github.com/zephyrproject-rtos/zephyr/issues/2244

https://github.com/zephyrproject-rtos/zephyr/issues/2247

https://github.com/zephyrproject-rtos/zephyr/issues/2248

 

To be short, Mayfly schedule functions to be run deferred in another execution context.

Currently the BLE controller uses them to call functions in interrupt contexts.

Zephyr threads or work queues that suffice the controller needs will replace mayfly.

 

If you can be more specific on what you are interested in Ticker/Mayfly, I can provide more details.

 

Regards,

Vinayak

 

 

 

From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Cufi, Carles
Sent: Saturday, October 07, 2017 3:48 PM
To: biwa <sjbiwa@...>; zephyr-devel@...
Subject: Re: [Zephyr-devel] Is there tutorials for Zephyr ticker/mayfly?

 

Hi there,

 

No, unfortunately there are no tutorials or even documentation about the ticker or the mayfly. That said, their author is Vinayak from Nordic, and you can reach him on IRC, he’s usually there. Try the channel #zephyr-bt on freenode.net.

 

Regards,

 

Carles

 

From: <zephyr-devel-bounces@...> on behalf of biwa <sjbiwa@...>
Date: Saturday, 7 October 2017 at 04:00
To: "zephyr-devel@..." <zephyr-devel@...>
Subject: [Zephyr-devel] Is there tutorials for Zephyr ticker/mayfly?

 

I am studying ZephyrOS.

Are there detailed tutorials for studying zephyrOS's ticker/mayfly?


Re: Is there tutorials for Zephyr ticker/mayfly?

Carles Cufi
 

Hi there,

 

No, unfortunately there are no tutorials or even documentation about the ticker or the mayfly. That said, their author is Vinayak from Nordic, and you can reach him on IRC, he’s usually there. Try the channel #zephyr-bt on freenode.net.

 

Regards,

 

Carles

 

From: <zephyr-devel-bounces@...> on behalf of biwa <sjbiwa@...>
Date: Saturday, 7 October 2017 at 04:00
To: "zephyr-devel@..." <zephyr-devel@...>
Subject: [Zephyr-devel] Is there tutorials for Zephyr ticker/mayfly?

 

I am studying ZephyrOS.

Are there detailed tutorials for studying zephyrOS's ticker/mayfly?


Is there tutorials for Zephyr ticker/mayfly?

loquat3
 

I am studying ZephyrOS.

Are there detailed tutorials for studying zephyrOS's ticker/mayfly?


Re: 802.15.4 stack question

David Leach
 

Tomasz,

 

I understand that implementations vary from the IEEE standard. I tend to treat the standard as the reference and try to grep the implementation based on this framework. I guess I need to dig into net_app…

 

On data frames, at least for version 2011 (didn't check later ones), nothing forces AR to be 1, see 5.2.2.2.
Moreover if your protocol handles re-transmission on its own you don't want 15.4 to add-up.
Also, until 2015 version, which is not supported atm, this "re-transmission" mechanism from 15.4 is just plain
crap: ACK frames are unidentified, non-secured, etc...

The observation we had from my 802.11 days is that it was generally better to have retries at the RF level due to the tighter timings then to have the higher layer protocols handle the retries (which they will do anyway if the 802.11 retry mechanism exhausts the retry limit). I don’t have as much experience with the network characteristics of an 802.15.4 setup but I would think that it would also benefit from the tighter retry logic timing of the protocol… but this is a knob to tune when setting up a network I guess.

 

David

 

 

 

From: Tomasz Bursztyka [mailto:tomasz.bursztyka@...]
Sent: Friday, October 06, 2017 2:59 AM
To: David Leach <david.leach@...>; zephyr-devel@...
Subject: Re: [Zephyr-devel] 802.15.4 stack question

 

Hi David,

 To clarify my general question, what I’m trying to understand is how do we generally expect to initialize/configure the 802.15.4 stack within our system or application? The IEEE802.15.4 specification defines several SAPs for MCPS and for MLME which is what I would expect to see on an interface (like 802.11 which I’m more familiar with)


You won't see the exact same interfaces a described in the specs. PHYs don't even follow it either btw.
Actually a good amount of the specs will probably never end up being coded at all (FFD part for instance).


. I can see some of the logical mappings between IEEE802.15.4 MLME operations to the NET_REQUEST_IEEE802154_CMD types we have in Zephyr but not all of them yet (still grepping the code/logic). And I see we have these net_mgmt() functions to set these values. Is it through these net_mgmt() functions that we are expected to setup the values?


Yes, and you probably just want to use net_app lib for it.


 With respect to the AR bit, I don’t understand your response about the AR bit in the frame control. If a frame is being transmitted from an IEEE Std 802 protocol then the AR field should follow the needs of the frame where a broadcast or group address frame has the AR field set to 0 and directed data frames have the AR field set to 1. The other 802.15.4 management frames all each have their own rules on setting or clearing this bit from what I can tell. I don’t get why there is even an API to enable/disable this as the frame type should be driving the needs of this bit.


Looks like forcing AR bit setting to 0 on broadcast type got forgotten, as it used to be always 0.
For MAC command frame it's properly handled.

On data frames, at least for version 2011 (didn't check later ones), nothing forces AR to be 1, see 5.2.2.2.
Moreover if your protocol handles re-transmission on its own you don't want 15.4 to add-up.
Also, until 2015 version, which is not supported atm, this "re-transmission" mechanism from 15.4 is just plain
crap: ACK frames are unidentified, non-secured, etc...

Br,

Tomasz


Re: 802.15.4 stack question

Tomasz Bursztyka
 

Hi David,

 To clarify my general question, what I’m trying to understand is how do we generally expect to initialize/configure the 802.15.4 stack within our system or application? The IEEE802.15.4 specification defines several SAPs for MCPS and for MLME which is what I would expect to see on an interface (like 802.11 which I’m more familiar with)


You won't see the exact same interfaces a described in the specs. PHYs don't even follow it either btw.
Actually a good amount of the specs will probably never end up being coded at all (FFD part for instance).

. I can see some of the logical mappings between IEEE802.15.4 MLME operations to the NET_REQUEST_IEEE802154_CMD types we have in Zephyr but not all of them yet (still grepping the code/logic). And I see we have these net_mgmt() functions to set these values. Is it through these net_mgmt() functions that we are expected to setup the values?


Yes, and you probably just want to use net_app lib for it.

 With respect to the AR bit, I don’t understand your response about the AR bit in the frame control. If a frame is being transmitted from an IEEE Std 802 protocol then the AR field should follow the needs of the frame where a broadcast or group address frame has the AR field set to 0 and directed data frames have the AR field set to 1. The other 802.15.4 management frames all each have their own rules on setting or clearing this bit from what I can tell. I don’t get why there is even an API to enable/disable this as the frame type should be driving the needs of this bit.


Looks like forcing AR bit setting to 0 on broadcast type got forgotten, as it used to be always 0.
For MAC command frame it's properly handled.

On data frames, at least for version 2011 (didn't check later ones), nothing forces AR to be 1, see 5.2.2.2.
Moreover if your protocol handles re-transmission on its own you don't want 15.4 to add-up.
Also, until 2015 version, which is not supported atm, this "re-transmission" mechanism from 15.4 is just plain
crap: ACK frames are unidentified, non-secured, etc...

Br,

Tomasz


Re: 802.15.4 stack question

Johann Fischer
 

Hi David,

I'm looking at debug output and noting that the stack sends data frames and retries them all because it seems like it doesn't know to set the "ack required" field in the frame control. I can see that there seems to be these net_mgmt() commands to SET_ACK but it isn't clear to me when these actually should be invoked and what the expected behavior is.
I guess you use NXP hardware. The MCR20A driver has an little issue with
the ACKs, see [1], comes from my misunderstanding of the stack, the patch will
be reworked after #4094 is accepted. I have seen the same issue in KW41Z
driver, so this must also be fixed.

[1] https://github.com/zephyrproject-rtos/zephyr/pull/1135

Johann Fischer


Re: 802.15.4 stack question

David Leach
 

Tomaz,

 

Thank you for the response.

 

To clarify my general question, what I’m trying to understand is how do we generally expect to initialize/configure the 802.15.4 stack within our system or application? The IEEE802.15.4 specification defines several SAPs for MCPS and for MLME which is what I would expect to see on an interface (like 802.11 which I’m more familiar with). I can see some of the logical mappings between IEEE802.15.4 MLME operations to the NET_REQUEST_IEEE802154_CMD types we have in Zephyr but not all of them yet (still grepping the code/logic). And I see we have these net_mgmt() functions to set these values. Is it through these net_mgmt() functions that we are expected to setup the values?

 

With respect to the AR bit, I don’t understand your response about the AR bit in the frame control. If a frame is being transmitted from an IEEE Std 802 protocol then the AR field should follow the needs of the frame where a broadcast or group address frame has the AR field set to 0 and directed data frames have the AR field set to 1. The other 802.15.4 management frames all each have their own rules on setting or clearing this bit from what I can tell. I don’t get why there is even an API to enable/disable this as the frame type should be driving the needs of this bit.

 

David

 

From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Tomasz Bursztyka
Sent: Thursday, October 05, 2017 2:25 AM
To: zephyr-devel@...
Subject: Re: [Zephyr-devel] 802.15.4 stack question

 

Hi David,

How is the 15.4 stack interaction supposed to work when trying to tie it to something like the echo client/server?


As any L2. The IP layer and net application (whatever it is) has no knowledge of its inner logic. All is abstracted via net_if


 

I’m looking at debug output and noting that the stack sends data frames and retries them all because it seems like it doesn’t know to set the “ack required” field in the frame control. I can see that there seems to be these net_mgmt() commands to SET_ACK but it isn’t clear to me when these actually should be invoked and what the expected behavior is.


Hopefully IP stack does not request ACK flag by itself. That's completely up to the application and should be used very carefully.
echo apps are some kind of basic flooding apps just to see if the whole net logic works, and is really not a proper 15.4 test case.
But it's fine, as long as most of the packets go through. You can have losses, 15.4 (2011 version at least) is not meant to be a reliable
technology.


 

Also, the shell_cmd_ack() function in ieee802154_shell.c doesn’t seem right in that the unset command is still invoking the NET_REQUEST_IEEE802154_SET_ACK instead of the UNSET_ACK.


Yep, a q&d c/p issue. Will fix it.
I don't think anybody uses that shell, even myself actually.


Tomasz


 

David Leach

 

NXP Semiconductors

phone: +1.210.241.6761

Email: david.leach@...

 

 

** PROPRIETARY & COMPANY-CONFIDENTIAL **

 




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

 


Re: Bluetooth mesh - Key Refresh

Johan Hedberg
 

Hi Jehudi,

On Thu, Oct 05, 2017, Johan Hedberg wrote:
On Thu, Oct 05, 2017, Laczen JMS wrote:
I have a question regarding the key refresh procedure in bluetooth
mesh. As far as I understand it a key refresh procedure should be done
in the following way:

1. A netkey update command is send from a config client
2. A appkey update command can be send from a client config when the
node is in refresh phase 1
3. The client can advance to phase 2 by sending a kr set command where
it starts using the new keys and old keys
4. a kr set command can be issued to go to phase 3 and the node
forgets the old keys

In this last step I can see that the code does a switch from the old
netkey to the new netkey, but I cannot find the switch from the old
appkey to the new appkey (if available). Is this missing from the code
or am I misunderstanding the key refresh procedure ?
No, I think you're understanding it right. I thought this was
implemented & tested, but apparently not. Any updated app keys should
indeed get copied from &keys[1] to &keys[0] and the updated flag should
get cleared once the KR state goes to state 3 (and then immediately back
to normal). I'll try to come up with a fix for this.
I've now created pull request for this (only compile tested):

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

Could you please review (and if possible test) it. Thanks.

Johan


Re: Bluetooth mesh - Key Refresh

Johan Hedberg
 

Hi Jehudi,

On Thu, Oct 05, 2017, Laczen JMS wrote:
I have a question regarding the key refresh procedure in bluetooth
mesh. As far as I understand it a key refresh procedure should be done
in the following way:

1. A netkey update command is send from a config client
2. A appkey update command can be send from a client config when the
node is in refresh phase 1
3. The client can advance to phase 2 by sending a kr set command where
it starts using the new keys and old keys
4. a kr set command can be issued to go to phase 3 and the node
forgets the old keys

In this last step I can see that the code does a switch from the old
netkey to the new netkey, but I cannot find the switch from the old
appkey to the new appkey (if available). Is this missing from the code
or am I misunderstanding the key refresh procedure ?
No, I think you're understanding it right. I thought this was
implemented & tested, but apparently not. Any updated app keys should
indeed get copied from &keys[1] to &keys[0] and the updated flag should
get cleared once the KR state goes to state 3 (and then immediately back
to normal). I'll try to come up with a fix for this.

Johan


Bluetooth mesh - Key Refresh

laczenJMS
 

Hi,

I have a question regarding the key refresh procedure in bluetooth
mesh. As far as I understand it a key refresh procedure should be done
in the following way:

1. A netkey update command is send from a config client
2. A appkey update command can be send from a client config when the
node is in refresh phase 1
3. The client can advance to phase 2 by sending a kr set command where
it starts using the new keys and old keys
4. a kr set command can be issued to go to phase 3 and the node
forgets the old keys

In this last step I can see that the code does a switch from the old
netkey to the new netkey, but I cannot find the switch from the old
appkey to the new appkey (if available). Is this missing from the code
or am I misunderstanding the key refresh procedure ?

Thanks,

Jehudi


Re: 802.15.4 stack question

Tomasz Bursztyka
 

Hi David,

How is the 15.4 stack interaction supposed to work when trying to tie it to something like the echo client/server?


As any L2. The IP layer and net application (whatever it is) has no knowledge of its inner logic. All is abstracted via net_if

 

I’m looking at debug output and noting that the stack sends data frames and retries them all because it seems like it doesn’t know to set the “ack required” field in the frame control. I can see that there seems to be these net_mgmt() commands to SET_ACK but it isn’t clear to me when these actually should be invoked and what the expected behavior is.


Hopefully IP stack does not request ACK flag by itself. That's completely up to the application and should be used very carefully.
echo apps are some kind of basic flooding apps just to see if the whole net logic works, and is really not a proper 15.4 test case.
But it's fine, as long as most of the packets go through. You can have losses, 15.4 (2011 version at least) is not meant to be a reliable
technology.

 

Also, the shell_cmd_ack() function in ieee802154_shell.c doesn’t seem right in that the unset command is still invoking the NET_REQUEST_IEEE802154_SET_ACK instead of the UNSET_ACK.


Yep, a q&d c/p issue. Will fix it.
I don't think anybody uses that shell, even myself actually.


Tomasz

 

David Leach

 

NXP Semiconductors

phone: +1.210.241.6761

Email: david.leach@...

 

 

** PROPRIETARY & COMPANY-CONFIDENTIAL **

 



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



802.15.4 stack question

David Leach
 

How is the 15.4 stack interaction supposed to work when trying to tie it to something like the echo client/server?

 

I’m looking at debug output and noting that the stack sends data frames and retries them all because it seems like it doesn’t know to set the “ack required” field in the frame control. I can see that there seems to be these net_mgmt() commands to SET_ACK but it isn’t clear to me when these actually should be invoked and what the expected behavior is.

 

Also, the shell_cmd_ack() function in ieee802154_shell.c doesn’t seem right in that the unset command is still invoking the NET_REQUEST_IEEE802154_SET_ACK instead of the UNSET_ACK.

 

David Leach

 

NXP Semiconductors

phone: +1.210.241.6761

Email: david.leach@...

 

 

** PROPRIETARY & COMPANY-CONFIDENTIAL **

 


Re: RFC: Watchdog API update.

Michał Kruszewski <mkru@...>
 

I have updated watchdog API PR.

Michał Kruszewski


Sent with ProtonMail Secure Email.

-------- Original Message --------
Subject: Re: [Zephyr-devel] RFC: Watchdog API update.
Local Time: September 11, 2017 2:55 PM
UTC Time: September 11, 2017 12:55 PM
From: zephyr-devel@...
To: zephyr-devel@... <zephyr-devel@...>

Second update of Watchdog API RFC.

Michał Kruszewski

Sent with ProtonMail Secure Email.

-------- Original Message --------
Subject: Re: [Zephyr-devel] RFC: Watchdog API update.
Local Time: September 4, 2017 5:32 PM
UTC Time: September 4, 2017 3:32 PM
From: mkru@...
To: zephyr-devel@... <zephyr-devel@...>

I have updated Watchdog API RFC.
I am waiting for feedback!

Michał Kruszewski


Sent with ProtonMail Secure Email.

-------- Original Message --------
Subject: [Zephyr-devel] RFC: Watchdog API update.
Local Time: August 25, 2017 5:01 PM
UTC Time: August 25, 2017 3:01 PM
From: Michal.Kruszewski@...
To: zephyr-devel@... <zephyr-devel@...>


Hello developers,


As current watchdog API looks like legacy from QMSI I would like to propose some refresh.

My RFC adds support for watchdogs with multiple reload channels. It also enables configuring watchdog timer behavior when CPU is in sleep state as well as when it is halted by the debugger.

The biggest advantage is that it enables  setting watchdog timeout value in human friendly unit of microseconds.


Here is my PR: https://github.com/zephyrproject-rtos/zephyr/pull/1260


I am waiting for feedback!


Regards,

Michał Kruszewski





Re: mesh sdk

Johan Hedberg
 

Hi,

On Wed, Oct 04, 2017, lalit.mahajan-threemediatech wrote:
Can Any one help me to how to setup for mesh sample of Zephyr or actually
how it works ??
What have you tried so far? For provisioning you could e.g. use meshctl
from BlueZ or the Silicon Labs Android app. Note that both of these use
GATT, so you need that enabled on the Zephyr side.

Johan

4481 - 4500 of 7936