Date   

Re: Adding Nucleo-F030R8 support to Zephyr - runtime error

Yannis Damigos
 

@Bobby I missed that it is a pointer to const u32_t. It is fine.

On Mon, Sep 4, 2017 at 12:01 PM, Yannis Damigos
<giannis.damigos@...> wrote:
Hi Maciej and Bobby,

you can collaborate on Maciej github repository and push this commit
as a PR there and then to Zephyr's repo.

@Booby You declare vector_table_src as constant and the you change its
value. Does the compiler give you a warning for undefined behavior?

Yannis


Re: Adding Nucleo-F030R8 support to Zephyr - runtime error

Yannis Damigos
 

Hi Maciej and Bobby,

you can collaborate on Maciej github repository and push this commit
as a PR there and then to Zephyr's repo.

@Booby You declare vector_table_src as constant and the you change its
value. Does the compiler give you a warning for undefined behavior?

Yannis


Re: how to conditionally link a static library in Zephyr?

Paul Sokolovsky
 

Hello,

On Sun, 3 Sep 2017 06:28:52 +0000
"Li, Jun R" <jun.r.li@...> wrote:

Hi there,
I’m trying to build my zephyr app with a static library which is not
provided with its source code. I can achieve the goal by adding the
following two lines in my project’s Makefile:

export LDFLAGS_zephyr += -L$(SOURCE_DIR)/mylib/
export ALL_LIBS += mylib

However, I want to get the static library linked only when a specific
macro is defined, like below

Ifeq ($(CONFIG_ENABLE_MYLIB),y)
export LDFLAGS_zephyr += -L$(SOURCE_DIR)/mylib/
export ALL_LIBS += mylib
endif


Here `CONFIG_ENABLE_MYLIB` is a macro defined in a Kconfig file
somewhere.
Well, that's not specific enough. It's not enough to define a config
option "in a Kconfig file somewhere" for it to be actually available in
Zephyr build process. Nor you explain which Makefile contains
ifeq/endif snippet above.

However, the static library can’t be linked if I used the conditional
option even though the macro CONFIG_ENABLE_MYLIB is enabled in my
“prj.conf”.
With the (sparse) info above, I'd suggest checking that
outdir/$BOARD/.config actually contains CONFIG_ENABLE_MYLIB=y.


So, I’m wondering if anybody has done the similar work and can you
share the experience? Thank you very much!

Regards,
Jun


--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


Re: Adding Nucleo-F030R8 support to Zephyr - runtime error

Maciej Dębski <maciej.debski@...>
 

Hello Bobby,

amazing, thank you for doing this!
Yes, it works on my Nucleo-F030R8, hello world and blinky, both are fine.

Try to emphasize that this is related to my patch, so these should be released together.
If anyone knows what the procedure is in such cases, please, let me know. Should I just wait?

Thank you,
Maciej Dębski


On Sun, Sep 3, 2017 at 7:22 PM, b0661 <b0661n0e17e@...> wrote:
Hello Maciej,

I assume the problem is - as Yannis pointed out - the code triggers a write to flash which stops in some way  execution.

The commit "arch: arm: core: fix vector table relocate write to flash"
https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314
works for me on NUCLEO F091RC and I do not see any side effects (but who knows?).

I do not have a board that needs the relocation. So this is untested for such boards.
Nevertheless the commit passes my local sanity check.

If it works for Nucleo-F030R8 too I can prepare a pull request and see whether it passes CI.

Bobby


2017-08-25 14:24 GMT+02:00 Maciej Dębski <maciej.debski@...>:
Gentlemen,

thank you for your quick responses!

As I wanted to provide more info and debug output, I accidentally found the issue.
This little change in arch/arm/core/cortex_m/prep_c.c caused sys fatal error on my f0 board, even before the stm32f0_init.

Here is the commit:
And here are the specific changes causing problem:

diff --git a/arch/arm/core/cortex_m/prep_c.c b/arch/arm/core/cortex_m/prep_c.c
index d23dd8b..1382379 100644
--- a/arch/arm/core/cortex_m/prep_c.c
+++ b/arch/arm/core/cortex_m/prep_c.c
@@ -22,9 +22,20 @@
 #include <linker/linker-defs.h>
 #include <nano_internal.h>
 #include <arch/arm/cortex_m/cmsis.h>
+#include <string.h>
 
 #ifdef CONFIG_ARMV6_M
-static inline void relocate_vector_table(void) { /* do nothing */ }
+
+#define VECTOR_ADDRESS 0
+static inline void relocate_vector_table(void)
+{
+#if defined(CONFIG_XIP) && (CONFIG_FLASH_BASE_ADDRESS != 0) || \
+    !defined(CONFIG_XIP) && (CONFIG_SRAM_BASE_ADDRESS != 0)
+       size_t vector_size = (size_t)_vector_end - (size_t)_vector_start;
+       memcpy(VECTOR_ADDRESS, _vector_start, vector_size);
+#endif
+}
+
 #elif defined(CONFIG_ARMV7_M)
 #ifdef CONFIG_XIP
 #define VECTOR_ADDRESS ((uintptr_t)&_image_rom_start + \


When I deleted the new body of the relocate_vector_table function (to do nothing as it was) - blinky and hello world started to work fine again.
What should I do now? How to report it properly?

Thank you!

Yours faithfully,
Maciej Dębski




On Wed, Aug 23, 2017 at 10:47 AM, Maciej Dębski <maciej.debski@...> wrote:
Hello,

I am developing support for nucleo board, with stm32f030r8 MCU. The goal was to compile and run the samples provided with Zephyr, blinky and hello_world.

I managed to finish the job, all was good, so I have done a pull request. Then, one of the reviewers pointed out that new approach to pinctrl nodes and uart pinctrl configuration in stm32 socs DT files was introduced. I was asked to do appropriate changes.

I modified my code to fit the Zephyr master. Sadly, blinky and hello_world have stopped working. The code itself is compiling and flashing fine. Just the board is reporting a fatal error before even my code is executed.
After checking the code over and over, I think I need help!

I believe most of the values are correct. I just do not fully understand the new dts/arm file structure, which is in Python, maybe I have missed something. Would you be so kind as to look at my code and help me find the issue?


This is my pull request. I would focus on dts/arm and include/dt-bindings.

Yours faithfully,
Maciej Dębski


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




Re: Remove/change fs_truncate() API

Paul Sokolovsky
 

Hello,

On Mon, 4 Sep 2017 09:27:30 +0200
Andrzej Kaczmarek <andrzej.kaczmarek@...> wrote:

Hi,

I was trying to implement fs_truncate() for NFFS but this does not
seem to be possible in a reasonable way, at least not with current
NFFS API. The only option I see now is to copy contents to new file
and unlink old one, but this has obvious disadvantages: it's slow, we
may easily run out of space etc.
ENOTSUP is your friend (except Linux thinks it should be EPERM, see
below).

So do we really need option to truncate any opened file to any size?
POSIX has it:
http://pubs.opengroup.org/onlinepubs/7908799/xsh/ftruncate.html , so we
apparently need it too.

In Mynewt there's only option to truncate file to 0 when opening it by
specifying flag to fs_open() and this seems to be just enough.There
seems to be not many references to fs API right now (actually
Bluetooth subsystem is the only one) so perhaps we could just remove
fs_truncate() and allow truncate to 0 using something else?
In a Linux system, only 0.0001% or so of the source code belongs to the
kernel. With that ratio in mind, how many Zephyr applications have you
considered?

My proposal would be one of:
- add flag to fs_open()
- make fs_truncate() truncate file specified by *path* to 0
Let's have a look at https://linux.die.net/man/2/ftruncate :

truncate(): /* Since glibc 2.12: */ _POSIX_C_SOURCE >= 200809L
ftruncate(): /* Since glibc 2.3.5: */ _POSIX_C_SOURCE >= 200112L

So, ftruncate() was categorized in glibc since the break of the century,
while truncate()-by-path is much more of a novelty, which should set
a priority of the order of their support.

The reason why I'd prefer to have truncation done by *path* instead of
*fp* is because it's simpler to implement in NFFS since what needs to
be done is to unlink old file and create new one. The API to create
new file takes full path as a parameter so having fp only makes it a
bit more complicated.
This seems like a logical fallacy: you have a problem with a single
thing on your hands (NFFS) and you want to change the world around it
(Zephyr API). Just accepting that NFFS is a novel, unproven,
underdeveloped and undertested filesystem should give enough of a
solution: just treat ftruncate operation as unsupported on it. Another
solution of course is to fix NFFS to support a standard POSIX
filesystem operation repertoire.

Let's look at https://linux.die.net/man/2/ftruncate again:

EPERM
The underlying file system does not support extending a file beyond its
current size.

However, my local man has more of it:

EPERM The underlying filesystem does not support extending
a file beyond its current size.

EPERM The operation was prevented by a file seal; see fcntl(2).

So, in Linux, EPERM is ambiguous. There's actually a better error code
- ENOTSUP. Arguably, it's the same "POSIX drama" as with EPERM vs
EACCESS, vividly explained here:
http://blog.unclesniper.org/archives/2-Linux-programmers,-learn-the-difference-between-EACCES-and-EPERM-already!.html
Following the same logic, I'd recommend to use ENOTSUP here (then wait
until Zephyr's POSIX subsystem matures, apps getting ported, and break
because of the "non-Linuxy" error code is used, then we switch it to
EPERM).


Best regards,
Andrzej


--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


Remove/change fs_truncate() API

Andrzej Kaczmarek
 

Hi,

I was trying to implement fs_truncate() for NFFS but this does not
seem to be possible in a reasonable way, at least not with current
NFFS API. The only option I see now is to copy contents to new file
and unlink old one, but this has obvious disadvantages: it's slow, we
may easily run out of space etc.

So do we really need option to truncate any opened file to any size?
In Mynewt there's only option to truncate file to 0 when opening it by
specifying flag to fs_open() and this seems to be just enough. There
seems to be not many references to fs API right now (actually
Bluetooth subsystem is the only one) so perhaps we could just remove
fs_truncate() and allow truncate to 0 using something else?

My proposal would be one of:
- add flag to fs_open()
- make fs_truncate() truncate file specified by *path* to 0

The reason why I'd prefer to have truncation done by *path* instead of
*fp* is because it's simpler to implement in NFFS since what needs to
be done is to unlink old file and create new one. The API to create
new file takes full path as a parameter so having fp only makes it a
bit more complicated.

Best regards,
Andrzej


Re: Adding Nucleo-F030R8 support to Zephyr - runtime error

Bobby
 

Hello Maciej,

I assume the problem is - as Yannis pointed out - the code triggers a write to flash which stops in some way  execution.

The commit "arch: arm: core: fix vector table relocate write to flash"
https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314
works for me on NUCLEO F091RC and I do not see any side effects (but who knows?).

I do not have a board that needs the relocation. So this is untested for such boards.
Nevertheless the commit passes my local sanity check.

If it works for Nucleo-F030R8 too I can prepare a pull request and see whether it passes CI.

Bobby


2017-08-25 14:24 GMT+02:00 Maciej Dębski <maciej.debski@...>:

Gentlemen,

thank you for your quick responses!

As I wanted to provide more info and debug output, I accidentally found the issue.
This little change in arch/arm/core/cortex_m/prep_c.c caused sys fatal error on my f0 board, even before the stm32f0_init.

Here is the commit:
And here are the specific changes causing problem:

diff --git a/arch/arm/core/cortex_m/prep_c.c b/arch/arm/core/cortex_m/prep_c.c
index d23dd8b..1382379 100644
--- a/arch/arm/core/cortex_m/prep_c.c
+++ b/arch/arm/core/cortex_m/prep_c.c
@@ -22,9 +22,20 @@
 #include <linker/linker-defs.h>
 #include <nano_internal.h>
 #include <arch/arm/cortex_m/cmsis.h>
+#include <string.h>
 
 #ifdef CONFIG_ARMV6_M
-static inline void relocate_vector_table(void) { /* do nothing */ }
+
+#define VECTOR_ADDRESS 0
+static inline void relocate_vector_table(void)
+{
+#if defined(CONFIG_XIP) && (CONFIG_FLASH_BASE_ADDRESS != 0) || \
+    !defined(CONFIG_XIP) && (CONFIG_SRAM_BASE_ADDRESS != 0)
+       size_t vector_size = (size_t)_vector_end - (size_t)_vector_start;
+       memcpy(VECTOR_ADDRESS, _vector_start, vector_size);
+#endif
+}
+
 #elif defined(CONFIG_ARMV7_M)
 #ifdef CONFIG_XIP
 #define VECTOR_ADDRESS ((uintptr_t)&_image_rom_start + \


When I deleted the new body of the relocate_vector_table function (to do nothing as it was) - blinky and hello world started to work fine again.
What should I do now? How to report it properly?

Thank you!

Yours faithfully,
Maciej Dębski




On Wed, Aug 23, 2017 at 10:47 AM, Maciej Dębski <maciej.debski@...> wrote:
Hello,

I am developing support for nucleo board, with stm32f030r8 MCU. The goal was to compile and run the samples provided with Zephyr, blinky and hello_world.

I managed to finish the job, all was good, so I have done a pull request. Then, one of the reviewers pointed out that new approach to pinctrl nodes and uart pinctrl configuration in stm32 socs DT files was introduced. I was asked to do appropriate changes.

I modified my code to fit the Zephyr master. Sadly, blinky and hello_world have stopped working. The code itself is compiling and flashing fine. Just the board is reporting a fatal error before even my code is executed.
After checking the code over and over, I think I need help!

I believe most of the values are correct. I just do not fully understand the new dts/arm file structure, which is in Python, maybe I have missed something. Would you be so kind as to look at my code and help me find the issue?


This is my pull request. I would focus on dts/arm and include/dt-bindings.

Yours faithfully,
Maciej Dębski


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



Re: Bluetooth mesh - error when proxy connected

Johan Hedberg
 

Hi Jehudi,

On Sun, Sep 03, 2017, Johan Hedberg wrote:
On Sat, Sep 02, 2017, Laczen JMS wrote:
I am using bluetooth mesh on zephyr. As soon as I make a proxy
connection to a node I am getting errors:

[bt] [ERR] node_id_adv: Failed to advertise using Node ID (err -5)

and after some time this changes to:

[bt] [ERR] net_id_adv: Failed to advertise using Network ID (err -5)

I have set the configuration parameter: CONFIG_BT_MAX_CONN=1.
I think those errors are mostly harmless. What's happening is that the
code tries to re-enable connectable advertising, however since the
controller only supports one connection it results in a failure. We
should probably add an #ifdef somewhere so that the code doesn't attempt
this when BT_MAX_CONN=1.
You could try e.g. the attached patch. It should change the error into a
warning when the connection limit is reached.

Johan


how to conditionally link a static library in Zephyr?

Li, Jun R
 

Hi there,

I’m trying to build my zephyr app with a static library which is not provided with its source code. I can achieve the goal by adding the following two lines in my project’s Makefile:

 

export LDFLAGS_zephyr += -L$(SOURCE_DIR)/mylib/

export ALL_LIBS += mylib

 

However, I want to get the static library linked only when a specific macro is defined, like below

 

Ifeq ($(CONFIG_ENABLE_MYLIB),y)

export LDFLAGS_zephyr += -L$(SOURCE_DIR)/mylib/

export ALL_LIBS += mylib

endif

 

 

Here `CONFIG_ENABLE_MYLIB` is a macro defined in a Kconfig file somewhere.

 

However, the static library can’t be linked if I used the conditional option even though the macro CONFIG_ENABLE_MYLIB is enabled in my “prj.conf”.

 

So, I’m wondering if anybody has done the similar work and can you share the experience? Thank you very much!

 

Regards,

Jun

 


Re: Bluetooth mesh - error when proxy connected

Johan Hedberg
 

Hi Jehudi,

On Sat, Sep 02, 2017, Laczen JMS wrote:
I am using bluetooth mesh on zephyr. As soon as I make a proxy
connection to a node I am getting errors:

[bt] [ERR] node_id_adv: Failed to advertise using Node ID (err -5)

and after some time this changes to:

[bt] [ERR] net_id_adv: Failed to advertise using Network ID (err -5)

I have set the configuration parameter: CONFIG_BT_MAX_CONN=1.
I think those errors are mostly harmless. What's happening is that the
code tries to re-enable connectable advertising, however since the
controller only supports one connection it results in a failure. We
should probably add an #ifdef somewhere so that the code doesn't attempt
this when BT_MAX_CONN=1.

Johan


Bluetooth mesh - error when proxy connected

laczenJMS
 

Hi,

I am using bluetooth mesh on zephyr. As soon as I make a proxy
connection to a node I am getting errors:

[bt] [ERR] node_id_adv: Failed to advertise using Node ID (err -5)

and after some time this changes to:

[bt] [ERR] net_id_adv: Failed to advertise using Network ID (err -5)

I have set the configuration parameter: CONFIG_BT_MAX_CONN=1.

Kind regards,

Jehudi


Re: Counter API ambiguity.

Tseng, Kuo-Lang <kuo-lang.tseng@...>
 

Hi,


From: zephyr-devel-bounces@... [mailto:zephyr-devel-
bounces@...] On Behalf Of Michal Kruszewski via Zephyr-devel
Sent: Monday, August 28, 2017 1:51 AM
To: zephyr-devel@...
Subject: [Zephyr-devel] Counter API ambiguity.

In the counter API we can find following function with its description:

/**
* @brief Set an alarm.
* @param dev Pointer to the device structure for the driver instance.
* @param callback Pointer to the callback function. if this is NULL,
*                 this function unsets the alarm.
* @param count Number of counter ticks.
* @param user_data Pointer to user data.
*
* @retval 0 If successful.
* @retval -ENOTSUP if the counter was not started yet.
* @retval -ENODEV if the device doesn't support interrupt (e.g. free
*                        running counters).
* @retval Negative errno code if failure.
*/
static inline int counter_set_alarm(struct device *dev,
    counter_callback_t callback,
    u32_t count, void *user_data)
{
const struct counter_driver_api *api = dev->driver_api;

return api->set_alarm(dev, callback, count, user_data); }

Description: * @param count Number of counter ticks is misleading because it is
not explicitly defined if it is relative count (relative to current counter value) or
absolute counter count value.
Baohong can correct me. I believe this is the number of counter ticks for the counter to send a notification. User would not need to know what current counter value is; when the API is called, the counter would start counting this number of ticks and when it reaches to that many ticks, it would generate a notification, i.e. the callback will be invoked.


Can anyone clarify it and can we make PR to add that information to API so that
application developers do not interpret it in wrong way?

Michał Kruszewski

Sent with ProtonMail Secure Email.


Re: Counter API ambiguity.

Boie, Andrew P
 

Baohong,

 

I see you contributed these APIs to Zephyr, can you help us understand the intention with the "count" parameter to count_set_alarm()?

 

From: Cufi, Carles [mailto:Carles.Cufi@...]
Sent: Friday, September 1, 2017 2:30 AM
To: Michał Kruszewski <mkru@...>; zephyr-devel@...; Tomasz Bursztyka <tomasz.bursztyka@...>; Boie, Andrew P <andrew.p.boie@...>
Subject: RE: [Zephyr-devel] Counter API ambiguity.

 

Hi Tomasz, Andrew

 

Do you have any feedback for Michal regarding the issue below?

 

Thanks!

 

Carles

 

From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Michal Kruszewski via Zephyr-devel
Sent: 28 August 2017 10:51
To: zephyr-devel@...
Subject: [Zephyr-devel] Counter API ambiguity.

 

In the counter API we can find following function with its description:

 

/**

* @brief Set an alarm.

* @param dev Pointer to the device structure for the driver instance.

* @param callback Pointer to the callback function. if this is NULL,

*                 this function unsets the alarm.

* @param count Number of counter ticks.

* @param user_data Pointer to user data.

*

* @retval 0 If successful.

* @retval -ENOTSUP if the counter was not started yet.

* @retval -ENODEV if the device doesn't support interrupt (e.g. free

*                        running counters).

* @retval Negative errno code if failure.

*/

static inline int counter_set_alarm(struct device *dev,

    counter_callback_t callback,

    u32_t count, void *user_data)

{

const struct counter_driver_api *api = dev->driver_api;

 

return api->set_alarm(dev, callback, count, user_data);

}

 

Description: * @param count Number of counter ticks is misleading because it is not explicitly defined if it is relative count (relative to current counter value) or absolute counter count value.

 

Can anyone clarify it and can we make PR to add that information to API so that application developers do not interpret it in wrong way?

 

Michał Kruszewski

 

Sent with ProtonMail Secure Email.

 


Re: Zephyr DFU protocol

Carles Cufi
 

Hi David,

-----Original Message-----
From: David Brown [mailto:david.brown@...]
Sent: 31 August 2017 17:40
To: Cufi, Carles <Carles.Cufi@...>
Cc: zephyr-devel@...
Subject: Re: [Zephyr-devel] Zephyr DFU protocol

On Wed, Aug 30, 2017 at 09:38:44AM +0000, Cufi, Carles wrote:

That would be my preference as well, but it might not be as trivial as
it sounds. I need to discuss this further with the Mynewt developers,
because some of the abstractions (namely mbuf) might not be easy to
port. Once we choose a protocol, and if this ends up being NMP, I would
like to start those discussions ASAP with the contributions of the
Mynewt community.
I think we should go ahead and start the conversation with them, on
mailing lists.

Unfortunately, the Mynewt mailing lists add a Reply-to header, which
causes that list to "steal" replies that are cross posted. So, you if
you send to both the Zephyr and the Mynewt list, the replies will
randomly discard the Zephyr list, which tends to fork threads (randomly
because it depends on which mailing list server replies quicker, and
which message a given recipient's mail system decides to use, gmail
tends to use the first one, for example).

Feel free to help me apply pressure to get their list configuration
fixed.
I've copied Sterling to see if he can do something about this before we start cross-list conversations.

Regards,

Carles


Re: Bluetooth mesh - provisioning with static OOB

laczenJMS
 

Hi Johan,

The patch solves the issue.

Kind regards,

Jehudi

2017-09-01 12:18 GMT+02:00 Johan Hedberg <johan.hedberg@...>:

Hi,

On Fri, Sep 01, 2017, Johan Hedberg wrote:
On Fri, Sep 01, 2017, Laczen JMS wrote:
I would like to create a zephyr bluetooth mesh node with a public key
using static OOB provisioning. I tried using

static uint8_t static_key[16] = {0x01, 0x23, 0x45, 0x67, 0x89, 0xab,
0xcd, 0xef, 0x01, 0x23, 0x45, 0x67, 0x89, 0xab, 0xcd, 0xef,};

static const struct bt_mesh_prov prov = {
.uuid = dev_uuid,
.static_val = static_key,
.static_val_len = 16,
.complete = prov_complete,
};

The provisioner (meshctl) never asks for the public key when
provisioning and provisioning fails. Is this the correct way to setup
static OOB ?
I took a look at the Zephyr prov.c code, and it looks like there's a
possible off-by-one error in setting the Static OOB type value in the
Provisioning Capabilities PDU. Does the attached patch help?
After cross-checking with the Mesh spec this does look like a clear bug
to me, so I've opened a PR for it:

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

If things still don't work after this I'd start looking at meshctl code.

Johan


Re: Bluetooth mesh - provisioning with static OOB

Johan Hedberg
 

Hi,

On Fri, Sep 01, 2017, Johan Hedberg wrote:
On Fri, Sep 01, 2017, Laczen JMS wrote:
I would like to create a zephyr bluetooth mesh node with a public key
using static OOB provisioning. I tried using

static uint8_t static_key[16] = {0x01, 0x23, 0x45, 0x67, 0x89, 0xab,
0xcd, 0xef, 0x01, 0x23, 0x45, 0x67, 0x89, 0xab, 0xcd, 0xef,};

static const struct bt_mesh_prov prov = {
.uuid = dev_uuid,
.static_val = static_key,
.static_val_len = 16,
.complete = prov_complete,
};

The provisioner (meshctl) never asks for the public key when
provisioning and provisioning fails. Is this the correct way to setup
static OOB ?
I took a look at the Zephyr prov.c code, and it looks like there's a
possible off-by-one error in setting the Static OOB type value in the
Provisioning Capabilities PDU. Does the attached patch help?
After cross-checking with the Mesh spec this does look like a clear bug
to me, so I've opened a PR for it:

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

If things still don't work after this I'd start looking at meshctl code.

Johan


Re: Bluetooth mesh - provisioning with static OOB

Johan Hedberg
 

Hi Jehudi,

On Fri, Sep 01, 2017, Laczen JMS wrote:
I would like to create a zephyr bluetooth mesh node with a public key
using static OOB provisioning. I tried using

static uint8_t static_key[16] = {0x01, 0x23, 0x45, 0x67, 0x89, 0xab,
0xcd, 0xef, 0x01, 0x23, 0x45, 0x67, 0x89, 0xab, 0xcd, 0xef,};

static const struct bt_mesh_prov prov = {
.uuid = dev_uuid,
.static_val = static_key,
.static_val_len = 16,
.complete = prov_complete,
};

The provisioner (meshctl) never asks for the public key when
provisioning and provisioning fails. Is this the correct way to setup
static OOB ?
I took a look at the Zephyr prov.c code, and it looks like there's a
possible off-by-one error in setting the Static OOB type value in the
Provisioning Capabilities PDU. Does the attached patch help?

Johan


Bluetooth mesh - provisioning with static OOB

laczenJMS
 

Hi,

I would like to create a zephyr bluetooth mesh node with a public key
using static OOB provisioning. I tried using

static uint8_t static_key[16] = {0x01, 0x23, 0x45, 0x67, 0x89, 0xab,
0xcd, 0xef, 0x01, 0x23, 0x45, 0x67, 0x89, 0xab, 0xcd, 0xef,};

static const struct bt_mesh_prov prov = {
.uuid = dev_uuid,
.static_val = static_key,
.static_val_len = 16,
.complete = prov_complete,
};

The provisioner (meshctl) never asks for the public key when
provisioning and provisioning fails. Is this the correct way to setup
static OOB ?

Kind regards,

Jehudi


Re: Counter API ambiguity.

Carles Cufi
 

Hi Tomasz, Andrew

 

Do you have any feedback for Michal regarding the issue below?

 

Thanks!

 

Carles

 

From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Michal Kruszewski via Zephyr-devel
Sent: 28 August 2017 10:51
To: zephyr-devel@...
Subject: [Zephyr-devel] Counter API ambiguity.

 

In the counter API we can find following function with its description:

 

/**

* @brief Set an alarm.

* @param dev Pointer to the device structure for the driver instance.

* @param callback Pointer to the callback function. if this is NULL,

*                 this function unsets the alarm.

* @param count Number of counter ticks.

* @param user_data Pointer to user data.

*

* @retval 0 If successful.

* @retval -ENOTSUP if the counter was not started yet.

* @retval -ENODEV if the device doesn't support interrupt (e.g. free

*                        running counters).

* @retval Negative errno code if failure.

*/

static inline int counter_set_alarm(struct device *dev,

    counter_callback_t callback,

    u32_t count, void *user_data)

{

const struct counter_driver_api *api = dev->driver_api;

 

return api->set_alarm(dev, callback, count, user_data);

}

 

Description: * @param count Number of counter ticks is misleading because it is not explicitly defined if it is relative count (relative to current counter value) or absolute counter count value.

 

Can anyone clarify it and can we make PR to add that information to API so that application developers do not interpret it in wrong way?

 

Michał Kruszewski

 

Sent with ProtonMail Secure Email.

 


Re: Zephyr DFU protocol

David Brown
 

On Wed, Aug 30, 2017 at 09:38:44AM +0000, Cufi, Carles wrote:

That would be my preference as well, but it might not be as trivial
as it sounds. I need to discuss this further with the Mynewt
developers, because some of the abstractions (namely mbuf) might not
be easy to port. Once we choose a protocol, and if this ends up being
NMP, I would like to start those discussions ASAP with the
contributions of the Mynewt community.
I think we should go ahead and start the conversation with them, on
mailing lists.

Unfortunately, the Mynewt mailing lists add a Reply-to header, which
causes that list to "steal" replies that are cross posted. So, you
if you send to both the Zephyr and the Mynewt list, the replies will
randomly discard the Zephyr list, which tends to fork threads
(randomly because it depends on which mailing list server replies
quicker, and which message a given recipient's mail system decides to
use, gmail tends to use the first one, for example).

Feel free to help me apply pressure to get their list configuration
fixed.

David

5401 - 5420 of 8692