Date   

Re: Bluetooth mesh sample (mesh) - Hard Fault

Carles Cufi
 

Hi Jehudi,

-----Original Message-----
From: Laczen JMS [mailto:laczenjms@...]
Sent: 06 September 2017 15:46
To: Cufi, Carles <Carles.Cufi@...>
Cc: Johan Hedberg <johan.hedberg@...>; zephyr-
devel@...
Subject: Re: [Zephyr-devel] Bluetooth mesh sample (mesh) - Hard Fault

Hi Carles,


2017-09-06 15:26 GMT+02:00 Cufi, Carles <Carles.Cufi@...>:
Hi Jehudi,

-----Original Message-----
From: zephyr-devel-bounces@...
[mailto:zephyr-devel- bounces@...] On Behalf Of
Laczen JMS
Sent: 06 September 2017 15:20
To: Johan Hedberg <johan.hedberg@...>
Cc: zephyr-devel@...
Subject: Re: [Zephyr-devel] Bluetooth mesh sample (mesh) - Hard Fault

Hi Johan,

I increased the stack size to CONFIG_BT_RX_STACK_SIZE=2048 (I don't
understand why the real stack size is reported to be 2348), anyhow it
gives a new hard fault (but now with assert: '0' failed):

Kernel stacks:
main (real size 512): unused 220 usage 292 / 512 (57
%)
idle (real size 256): unused 200 usage 56 / 256 (21 %)
interrupt (real size 2048): unused 1640 usage 408 / 2048 (19
%)
workqueue (real size 2048): unused 1668 usage 380 / 2048 (18
%)
prio recv thread stack (real size 748): unused 440 usage 308 /
748
(41 %)
recv thread stack (real size 2348): unused 308 usage 2040 /
2348 (86 %)
[bt] [ERR] isr_rx_conn_pkt_ctrl: assert: '0' failed
***** HARD FAULT *****
Executing thread ID (thread): 0x200023dc
Faulting instruction address: 0x12d50 Fatal fault in ISR!
Spinning...

This is a BLE Controller assert that hit. Can you give us a couple of
additional tidbits of info to help us diagnose?

* What exact Zephyr version are you running? (if master please give us
the commit SHA)
I am using the latest zephyr version (pulled yesterday), commit
d3862d7b39349b079b0d125de0c27e54a41b8aa4
So that's the latest, excludes some fixes that came in some days ago. Thanks.


* What board are you using? Is this a combined (Host + Controller
single-chip) build or are you using 2 chips?

I am using a andtcl board with nrf51822 256kb flash and 32kb ram
Not sure what board that is, can you send a link?


* What configuration are you using? (your .conf file)
Included are the conf file from the mesh source directory, as well as
the .config files from the output directory
Got your config files, so this is a combined build with Host + Controller on a single chip. What would be interesting to know in this case is more info about the peer devices you are interacting with. Can you give us a clue of what dongles/chips/devices are you connecting to, what brand they are and what version? Also the number of simultaneous connections you have at any one time, and the general description of the setup you are running in terms of chips and stacks.

Thanks,

Carles


Re: Bluetooth mesh sample (mesh) - Hard Fault

laczenJMS
 

Hi Carles,


2017-09-06 15:26 GMT+02:00 Cufi, Carles <Carles.Cufi@...>:
Hi Jehudi,

-----Original Message-----
From: zephyr-devel-bounces@... [mailto:zephyr-devel-
bounces@...] On Behalf Of Laczen JMS
Sent: 06 September 2017 15:20
To: Johan Hedberg <johan.hedberg@...>
Cc: zephyr-devel@...
Subject: Re: [Zephyr-devel] Bluetooth mesh sample (mesh) - Hard Fault

Hi Johan,

I increased the stack size to CONFIG_BT_RX_STACK_SIZE=2048 (I don't
understand why the real stack size is reported to be 2348), anyhow it
gives a new hard fault (but now with assert: '0' failed):

Kernel stacks:
main (real size 512): unused 220 usage 292 / 512 (57 %)
idle (real size 256): unused 200 usage 56 / 256 (21 %)
interrupt (real size 2048): unused 1640 usage 408 / 2048 (19 %)
workqueue (real size 2048): unused 1668 usage 380 / 2048 (18 %)
prio recv thread stack (real size 748): unused 440 usage 308 / 748
(41 %)
recv thread stack (real size 2348): unused 308 usage 2040 /
2348 (86 %)
[bt] [ERR] isr_rx_conn_pkt_ctrl: assert: '0' failed
***** HARD FAULT *****
Executing thread ID (thread): 0x200023dc
Faulting instruction address: 0x12d50 Fatal fault in ISR! Spinning...
This is a BLE Controller assert that hit. Can you give us a couple of additional tidbits of info to help us diagnose?

* What exact Zephyr version are you running? (if master please give us the commit SHA)
I am using the latest zephyr version (pulled yesterday), commit
d3862d7b39349b079b0d125de0c27e54a41b8aa4

* What board are you using? Is this a combined (Host + Controller single-chip) build or are you using 2 chips?
I am using a andtcl board with nrf51822 256kb flash and 32kb ram

* What configuration are you using? (your .conf file)
Included are the conf file from the mesh source directory, as well as
the .config files from the output directory


Thanks,

Carles
Kind regards,

Jehudi


Re: Bluetooth mesh sample (mesh) - Hard Fault

Carles Cufi
 

Hi Jehudi,

-----Original Message-----
From: zephyr-devel-bounces@... [mailto:zephyr-devel-
bounces@...] On Behalf Of Laczen JMS
Sent: 06 September 2017 15:20
To: Johan Hedberg <johan.hedberg@...>
Cc: zephyr-devel@...
Subject: Re: [Zephyr-devel] Bluetooth mesh sample (mesh) - Hard Fault

Hi Johan,

I increased the stack size to CONFIG_BT_RX_STACK_SIZE=2048 (I don't
understand why the real stack size is reported to be 2348), anyhow it
gives a new hard fault (but now with assert: '0' failed):

Kernel stacks:
main (real size 512): unused 220 usage 292 / 512 (57 %)
idle (real size 256): unused 200 usage 56 / 256 (21 %)
interrupt (real size 2048): unused 1640 usage 408 / 2048 (19 %)
workqueue (real size 2048): unused 1668 usage 380 / 2048 (18 %)
prio recv thread stack (real size 748): unused 440 usage 308 / 748
(41 %)
recv thread stack (real size 2348): unused 308 usage 2040 /
2348 (86 %)
[bt] [ERR] isr_rx_conn_pkt_ctrl: assert: '0' failed
***** HARD FAULT *****
Executing thread ID (thread): 0x200023dc
Faulting instruction address: 0x12d50 Fatal fault in ISR! Spinning...
This is a BLE Controller assert that hit. Can you give us a couple of additional tidbits of info to help us diagnose?

* What exact Zephyr version are you running? (if master please give us the commit SHA)
* What board are you using? Is this a combined (Host + Controller single-chip) build or are you using 2 chips?
* What configuration are you using? (your .conf file)

Thanks,

Carles


Re: Bluetooth mesh sample (mesh) - Hard Fault

laczenJMS
 

Hi Johan,

I increased the stack size to CONFIG_BT_RX_STACK_SIZE=2048 (I don't
understand why the real stack size is reported to be 2348), anyhow it
gives a new hard fault (but now with assert: '0' failed):

Kernel stacks:
main (real size 512): unused 220 usage 292 / 512 (57 %)
idle (real size 256): unused 200 usage 56 / 256 (21 %)
interrupt (real size 2048): unused 1640 usage 408 / 2048 (19 %)
workqueue (real size 2048): unused 1668 usage 380 / 2048 (18 %)
prio recv thread stack (real size 748): unused 440 usage 308 / 748 (41 %)
recv thread stack (real size 2348): unused 308 usage 2040 / 2348 (86 %)
[bt] [ERR] isr_rx_conn_pkt_ctrl: assert: '0' failed
***** HARD FAULT *****
Executing thread ID (thread): 0x200023dc
Faulting instruction address: 0x12d50
Fatal fault in ISR! Spinning...

Kind regards,

Jehudi

2017-09-06 11:35 GMT+02:00 Johan Hedberg <johan.hedberg@...>:

Hi Jehudi,

On Wed, Sep 06, 2017, Laczen JMS wrote:
Running the bluetooth mesh example (samples/bluetooth/mesh/) on a
nrf51822 results in a Hard Fault. The provisioner is meshctl (bluez).
After successful provisioning I disconnect from the mesh, when
connecting again the hard fault appears:

Kernel stacks:
main (real size 512): unused 228 usage 284 / 512 (55 %)
idle (real size 256): unused 200 usage 56 / 256 (21 %)
interrupt (real size 2048): unused 1656 usage 392 / 2048 (19 %)
workqueue (real size 1024): unused 676 usage 348 / 1024 (33 %)
prio recv thread stack (real size 448): unused 144 usage 304 / 448 (67 %)
recv thread stack (real size 1396): unused 32 usage 1364 / 1396 (97 %)
***** HARD FAULT *****
Executing thread ID (thread): 0x20001f04
Faulting instruction address: 0xf63c
Fatal fault in ISR! Spinning...

If needed I can provide more info/logging...
I'd bet the recv thread stack overflowed. It's already at 97% with only
32 unused bytes based on the above log. Try increasing its size to
something bigger. The Kconfig variable is called CONFIG_BT_RX_STACK_SIZE.

Johan


Question regarding to implement a UDP client using net_app APIs

Robert Chou
 

Hi,

 

I’m comparing implement a UDP client by using net_app and net_context APIs.

 

When using net_context APIs, I’m able to send and receive data from any peer (register receive callback through net_context_recv()).

Since UDP is connectionless, it’s an expected behavior as long as I don’t call net_context_connect().

 

However, if I use net_app APIs to implement a UDP client, it seems that I’m unable to do the same thing.

I’m able to send out the data to the requested peer by calling net_app_send_pkt().

However, I’m unable to receive the data from the peer by registering the receive callback through net_app_set_cb() and without calling net_app_connect().

 

Is this an intended behavior of net_app API?

 

Robert

==---------------------------------------------------------------
This email contains information that is for sole use of the intended recipient and may be confidential or privileged.If you are not the intended recipient, any further review, disclosure, copying, distribution, or use of this email, or the contents of this email is prohibited. Please notify the sender by reply this email and destroy the original email if your receipt of this email is in error.
---------------------------------------------------------------==!!



Re: Bluetooth mesh sample (mesh) - Hard Fault

Johan Hedberg
 

Hi Jehudi,

On Wed, Sep 06, 2017, Laczen JMS wrote:
Running the bluetooth mesh example (samples/bluetooth/mesh/) on a
nrf51822 results in a Hard Fault. The provisioner is meshctl (bluez).
After successful provisioning I disconnect from the mesh, when
connecting again the hard fault appears:

Kernel stacks:
main (real size 512): unused 228 usage 284 / 512 (55 %)
idle (real size 256): unused 200 usage 56 / 256 (21 %)
interrupt (real size 2048): unused 1656 usage 392 / 2048 (19 %)
workqueue (real size 1024): unused 676 usage 348 / 1024 (33 %)
prio recv thread stack (real size 448): unused 144 usage 304 / 448 (67 %)
recv thread stack (real size 1396): unused 32 usage 1364 / 1396 (97 %)
***** HARD FAULT *****
Executing thread ID (thread): 0x20001f04
Faulting instruction address: 0xf63c
Fatal fault in ISR! Spinning...

If needed I can provide more info/logging...
I'd bet the recv thread stack overflowed. It's already at 97% with only
32 unused bytes based on the above log. Try increasing its size to
something bigger. The Kconfig variable is called CONFIG_BT_RX_STACK_SIZE.

Johan


Bluetooth mesh sample (mesh) - Hard Fault

laczenJMS
 

Hi,

Running the bluetooth mesh example (samples/bluetooth/mesh/) on a
nrf51822 results in a Hard Fault. The provisioner is meshctl (bluez).
After successful provisioning I disconnect from the mesh, when
connecting again the hard fault appears:

Kernel stacks:
main (real size 512): unused 228 usage 284 / 512 (55 %)
idle (real size 256): unused 200 usage 56 / 256 (21 %)
interrupt (real size 2048): unused 1656 usage 392 / 2048 (19 %)
workqueue (real size 1024): unused 676 usage 348 / 1024 (33 %)
prio recv thread stack (real size 448): unused 144 usage 304 / 448 (67 %)
recv thread stack (real size 1396): unused 32 usage 1364 / 1396 (97 %)
***** HARD FAULT *****
Executing thread ID (thread): 0x20001f04
Faulting instruction address: 0xf63c
Fatal fault in ISR! Spinning...

If needed I can provide more info/logging...

Kind regards,

Jehudi


Re: [Zephyr-builds] Hello, I have some questions for building hello-world samples.

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

Hello,

a quick thought - did you try to write in Hello World example the following lines?
$ make help
$ make BOARD=<board_name>
$ make BOARD=<board_name> flash
$ make BOARD=<board_name> debug

Try to use these. Also, be sure you installed all linux prerequisites:
https://www.zephyrproject.org/doc/getting_started/installation_linux.html

Good luck,
Maciej Dębski

On Wed, Sep 6, 2017 at 2:52 AM, Nashif, Anas <anas.nashif@...> wrote:

Hi,

You need to install the SDK, it seems line you are missing this step. Please follow the instructions in the getting started guide to install the SDK, then point the variables to the directory where you have installed it.

 

Please use the zephyr-devel@ mailing list, not zephyr-builds@

 

Anas

 

From: zephyr-builds-bounces@lists.zephyrproject.org [mailto:zephyr-builds-bounces@lists.zephyrproject.org] On Behalf Of ???
Sent: Tuesday, September 5, 2017 4:40 AM
To: zephyr-builds@lists.zephyrproject.org
Subject: [Zephyr-builds] Hello, I have some questions for building hello-world samples.

 

Hi, it is the first time to use zephyr so I am little clumsy for understanding this RTOS. Thankyou for understanding.

 

I am using Linux 16.xx 64bit.

 

I tried to follow https://www.zephyrproject.org/doc/getting_started/getting_started.html to compile and build the hello-world.

 

I have cloned this->>git clone https://github.com/zephyrproject-rtos/zephyr.git   at the Desktop folder.

 

 

As you see the screen-shot above, I exported like that. (I am not sure the SDK_INSTALL_DIR's exact directory, please tell me if I got the wrong directory)

 

I did source zephyr-env.sh

 

Finally I type make to build the hello-world and I got these error.

 

 

please give me some advise. Thank you 

Image removed by sender.

 


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



Re: [Zephyr-builds] Hello, I have some questions for building hello-world samples.

Nashif, Anas
 

Hi,

You need to install the SDK, it seems line you are missing this step. Please follow the instructions in the getting started guide to install the SDK, then point the variables to the directory where you have installed it.

 

Please use the zephyr-devel@ mailing list, not zephyr-builds@

 

Anas

 

From: zephyr-builds-bounces@... [mailto:zephyr-builds-bounces@...] On Behalf Of ???
Sent: Tuesday, September 5, 2017 4:40 AM
To: zephyr-builds@...
Subject: [Zephyr-builds] Hello, I have some questions for building hello-world samples.

 

Hi, it is the first time to use zephyr so I am little clumsy for understanding this RTOS. Thankyou for understanding.

 

I am using Linux 16.xx 64bit.

 

I tried to follow https://www.zephyrproject.org/doc/getting_started/getting_started.html to compile and build the hello-world.

 

I have cloned this->>git clone https://github.com/zephyrproject-rtos/zephyr.git   at the Desktop folder.

 

 

As you see the screen-shot above, I exported like that. (I am not sure the SDK_INSTALL_DIR's exact directory, please tell me if I got the wrong directory)

 

I did source zephyr-env.sh

 

Finally I type make to build the hello-world and I got these error.

 

 

please give me some advise. Thank you 

Image removed by sender.

 


Re: Remove/change fs_truncate() API

David Brown
 

On Tue, Sep 05, 2017 at 10:18:01AM +0200, Andrzej Kaczmarek wrote:

I'm not really sure if this needs to be POSIX compliant - the Jira ticket for
adding filesystem APIs states that it is designed after POSIX but is not POSIX
compliant. For example, fs_open() does not have flags which could be used to
truncate existing file when opening, so it would cover one of possible
scenarios here. But perhaps something changed since then, don't know.
Perhaps we should change the API to add the truncate option to
fs_open(), at least provided at least one underlying implementation
supports this.

Yes, currently I return ENOTSUP for this. My only concern here is that this
means there is no way to open existing file and truncate it other than
fs_unlink() + fs_open() due to missing flags in fs_open() I mentioned above.
BTW, does it make sense to have fs_truncate() work for '0' as offset and return
e.g. EINVAL for other values? This should be doable I think.
Only if the fs_truncate() for 0 offset can be implemented atomically.
I'm not sure how that would work for operations given by file
descriptor, since the file is already opened.

I think there should be as little between the Zephyr fs API and the
NFFS API. A developer using a filesystem on an embedded system needs
to understand what is happening (and specifically what will happen if
power is interrupted during an operation). That means we should avoid
having API calls that try to simulate behavior that isn't there.

For example, if fs_truncate() somehow were to use fs_open() by
figuring out the filename the existing file descriptor used, and
opening with truncation in NFFS, this would cause an additional file
descriptor to be used for the operation (even if just momentarily).
In a system design, it is possible that the developer will configure
the exact number of file descriptors available, which could cause this
operation to either mysteriously fail, or succeed, but use the file
descriptor temporarily, causing another thread's filesystem operation
to fail.

So, my suggestion would be to add the O_TRUNC (or equivalent) flag to
open, make fs_truncate() return ENOTSUP, and just document this. If
arbitrary truncation, or truncation of an open file is desired, that
can be added later to NFFS, and then to the API.

David


Re: Remove/change fs_truncate() API

Andrzej Kaczmarek
 

Hi David,

On Mon, Sep 4, 2017 at 5:17 PM, David Brown <david.brown@...> wrote:
On Mon, Sep 04, 2017 at 09:27:30AM +0200, Andrzej Kaczmarek wrote:

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.

If your goal is posix compliance, this isn't going to be right anyway.
truncate is required to be atomic.

The POSIX truncate call is also allowed to be used to extend the size
of a file.

​I'm not really sure if ​this needs to be POSIX compliant - the Jira ticket for adding filesystem APIs states that it is designed after POSIX but is not POSIX compliant. For example, fs_open() does not have flags which could be used to truncate existing file when opening, so it would cover one of possible scenarios here. But perhaps something changed since then, don't know.
 
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.

I think it would be better to return ENOTSUP than to implement it in a
non-compliant way.  My suggestion would be to document it as not
supported, and make a ticket to add support to NFFS for truncation
later.

​Yes, currently I return ENOTSUP for this. My only concern here is that this means there is no way to open existing file and truncate it other than fs_unlink() + fs_open() due to missing flags in fs_open() I mentioned above.
BTW, does it make sense to have fs_truncate() work for '0' as offset and return e.g. EINVAL for other values? This should be doable I think.
 
David

​Best regards,
Andrzej​


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

Nashif, Anas
 

Hi,

The Kconfig options (macro) you define need to be included (sourced) in the overall Kconfig structure of zephyr, just adding an option to prj.conf does not give you what you want. This is possible and there are a few examples for doing this, see

 

tests/benchmarks/object_footprint/: This test uses local Kconfig variables

samples/application_development/: A few samples for linking external libraries and 3rd party code.

 

Anas

 

From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Li, Jun R
Sent: Sunday, September 3, 2017 2:29 AM
To: zephyr-devel@...
Subject: [Zephyr-devel] how to conditionally link a static library in Zephyr?

 

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: Zephyr 1.9.0 RC3 tagged

Nashif, Anas
 

Fixed, blame form auto-complete.

Anas

-----Original Message-----
From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Piotr Mienkowski
Sent: Monday, September 4, 2017 3:13 PM
To: zephyr-devel@...
Subject: Re: [Zephyr-devel] Zephyr 1.9.0 RC3 tagged

Hi Anas,

We have just tagged RC3, please see the changes since RC2 here:

https://github.com/zephyrproject-rtos/zephyr/releases/tag/v1.9.0-rc3
Thanks for preparing the release. Just a minor remark, after opening the link the page title seems to be incorrect. It states: "Zephyr SDK 0.9.2-rc3"

Regards,
Piotr

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


Re: Zephyr 1.9.0 RC3 tagged

Piotr Mienkowski
 

Hi Anas,

We have just tagged RC3, please see the changes since RC2 here:

https://github.com/zephyrproject-rtos/zephyr/releases/tag/v1.9.0-rc3
Thanks for preparing the release. Just a minor remark, after opening the
link the page title seems to be incorrect. It states: "Zephyr SDK 0.9.2-rc3"

Regards,
Piotr


Zephyr 1.9.0 RC3 tagged

Nashif, Anas
 

Hi,

 

We have just tagged RC3, please see the changes since RC2 here:

 

https://github.com/zephyrproject-rtos/zephyr/releases/tag/v1.9.0-rc3

 

 

If no major issues are found, we are expected to tag the final 1.9.0 in the next 2-3 days.

 

Regards,

Anas


Re: RFC: Watchdog API update.

Michał Kruszewski <mkru@...>
 

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: Remove/change fs_truncate() API

David Brown
 

On Mon, Sep 04, 2017 at 09:27:30AM +0200, Andrzej Kaczmarek wrote:

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.
If your goal is posix compliance, this isn't going to be right anyway.
truncate is required to be atomic.

The POSIX truncate call is also allowed to be used to extend the size
of a file.

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.
I think it would be better to return ENOTSUP than to implement it in a
non-compliant way. My suggestion would be to document it as not
supported, and make a ticket to add support to NFFS for truncation
later.

David


Re: info about device tree for stm32f412zg

Erwan Gouriou
 

Hi,

According to stm32f412zg datasheet, usart2_pin_c is actually supported on stm32f412zg, so I don't see issue to populate it in stm32f4-pinctrl.dtsi.
Besides, as mentioned by Andy, it's not a problem to be defined in a generic file.
Though you need to take care to enable only what is supported by your board in you project.

This being said, I know we didn't address yet the problem of different packages of a same SoC (64, 100, 144 pins).
In this case it is possible we'll have pins defined for a soc not supported on the smallest package of this SoC.
This does not trigger issues since what matters is the configurations you actually define on your board/project,
but maybe we could split -pinctrl files in -64.dsti, -100.dsti, -144.dtsi files to have a fully clean dts description.
We'll see if this is required.

Erwan


On 9 August 2017 at 19:14, Andy Gross <andy.gross@...> wrote:
On 9 August 2017 at 11:01, massimiliano cialdi
<massimiliano.cialdi@powersoft.it> wrote:
> Fo the nucleo_f412zg there is the file
>
> zephyr/dts/arm/nucleo_f412zg.dts
>
> that includes st/stm32f412.dtsi and then
> #include <st/stm32f412-pinctrl.dtsi>
> #include <st/stm32f411.dtsi>
>
> stm32f411.dtsi indirectly includes stm32f4-pinctrl.dtsi
>
> file stm32f4-pinctrl.dtsi contains
>
> usart2_pins_a: usart2@0 {
>   rx_tx {
>     rx = <STM32_PIN_PA3 (STM32_PINMUX_ALT_FUNC_7 | STM32_PUPDR_NO_PULL)>;
>     tx = <STM32_PIN_PA2 (STM32_PINMUX_ALT_FUNC_7 | STM32_PUSHPULL_NOPULL)>;
>   };
> };
> usart2_pins_b: usart2@1 {
>   rx_tx {
>     rx = <STM32_PIN_PA15 (STM32_PINMUX_ALT_FUNC_7 | STM32_PUPDR_NO_PULL)>;
>     tx = <STM32_PIN_PA2 (STM32_PINMUX_ALT_FUNC_7 | STM32_PUSHPULL_NOPULL)>;
>   };
> };
> usart2_pins_c: usart2@2 {
>   rx_tx {
>     rx = <STM32_PIN_PD6 (STM32_PINMUX_ALT_FUNC_7 | STM32_PUPDR_NO_PULL)>;
>     tx = <STM32_PIN_PA2 (STM32_PINMUX_ALT_FUNC_7 | STM32_PUSHPULL_NOPULL)>;
>   };
> };
>
> and if I want to use USART2 I have to add to stm32f412-pinctrl.dtsi
>
> usart2_pins_a: usart2@0 {
>   rx_tx {
>     rx = <STM32_PIN_PA3 (STM32_PINMUX_ALT_FUNC_7 | STM32_PUSHPULL_PULLUP)>;
>     tx = <STM32_PIN_PA2 (STM32_PINMUX_ALT_FUNC_7 | STM32_PUSHPULL_PULLUP)>;
>   };
> };
> usart2_pins_b: usart2@1 {
>   rx_tx {
>     rx = <STM32_PIN_PD6 (STM32_PINMUX_ALT_FUNC_7 | STM32_PUSHPULL_PULLUP)>;
>     tx = <STM32_PIN_PD5 (STM32_PINMUX_ALT_FUNC_7 | STM32_PUSHPULL_PULLUP)>;
>   };
> };
>
> because chip has only those two mux for USART2.
>
> In the compiled dts there is also usart2_pins_c that it doen't actually
> exist in the chip, how to remove it?

So if there are pin differences between the two, then anything non
generic needs to be removed from the .dtsi and put inside a more
specific .dtsi file that is included.  The intent of the definitions
was to allow reuse and make it easier to choose things without having
to consult the manual.

The pins_c should only be appearing if it is defined and someone is using it.

>
> the file stm32f4-pinctrl.dtsi should be generic for stm32f4 family chips. So
> why it contains a specific multiplexing for the usart that has to be
> overridden by specific pinmux files?

If the f412 has differences in pinmuxing from the f4, then those
things needs to be separated out.  The entries in the -pinctrl.dtsi
are used in the actual nodes in the board specific files.  Just
because something is defined does not mean that it is used unless
there is a pinctrl-0/pinctrl-1/pinctrl-2 property in the node that
uses one of the definitions.
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


Re: Zephyr SDK 0.9.2-rc1

Nashif, Anas
 

0.9.2 RC2 is now available from https://github.com/zephyrproject-rtos/meta-zephyr-sdk/releases/tag/0.9.2-rc2 with the following changes:

 

Changes since 0.9.2-rc1:

 

Anas

 

 

 

From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Nashif, Anas
Sent: Wednesday, August 30, 2017 10:00 AM
To: Zephyr Devel <devel@...>
Subject: [Zephyr-devel] Zephyr SDK 0.9.2-rc1

 

Hi,

 

We have a new SDK release candidate available @ https://github.com/zephyrproject-rtos/meta-zephyr-sdk/releases/tag/0.9.2-rc1:

 

 

Following changes since 0.9.1:

 

* openocd 0.10.0

  * Zephyr support in openocd

* qemu 2.10.0-rc4

   * 2.10.0-rc4: x86, arm, nios, xtensa

   * 2.7.50: riscv32

* bossac tool update

 

Known Issues:

 

* qemu for NIOS is not compatible with the board configuration available in Zephyr. Work on a fix is in progress.

 

 

Please give it a try and report any issues.

 

Thanks

Anas

 

 


Re: Bluetooth mesh - error when proxy connected

laczenJMS
 

Hi Johan,

With the patch applied I am getting still getting the warning every 10 seconds.

Kind regards,

Jehudi

2017-09-03 8:57 GMT+02:00 Johan Hedberg <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

5381 - 5400 of 8692