Date   
Dev-Review Meeting Agenda Mar 25

Kumar Gala
 

Here’s the agenda topics for this week:

* Review PR’s tagged with dev-review
* use of PRE_KERNEL_1/PRE_KERNEL_2...
* Pinmux/pinctrl (Piotr/Erwan)
* Any topics anyone else has

- k

Zephyr crypto APIs and mbed TLS

Carles Cufi
 

Hi all,

I was wondering about the state of crypto APIs in Zephyr and whether it makes sense to move them forward or instead we should consider simply using the mbed TLS set of APIs as Zephyr's crypto API.

The reason I say this is that today we have include/crypto/cipher.h which abstracts ciphers, but that's about it. Most users in the code seem to use mbed TLS APIs directly when they require crypto functionality (with the exception of Bluetooth which can use TinyCrypt or mbed TLS and has its own abstraction) with only the IEEE 802.15.4 stack using cipher.h.
mbed TLS is a recognized crypto API that (as far as I know) can be used with or without the actual mbed TLS implementation, so I question the need to define our own in this particular case, although I might be missing key information. Unless I am mistaken one can implement hardware-accelerated or custom or proprietary implementations of crypto functions and shim them so that they expose the mbed TLS API.

In any case I do believe this is something that needs discussion since the current usage in the tree is inconsistent and the subset of APIs defined in include/crypto is very small.

If we did decide to use mbed TLS as an API we would then also need to discuss how to go about it, since mbed TLS is today an (optional) module and therefore the header files themselves are not included in the main zephyr tree.

Input welcome!

Regards,

Carles

Re: nrf52840 ble error #ble #nrf52840

Narendar Malepu
 

Yes previously I posted same issue, but iam not creating any threads in my application


On Tue, 24 Mar, 2020, 2:14 PM Chettimada, Vinayak Kariappa, <vinayak.kariappa.chettimada@...> wrote:

Please create a github issue with details of building your application and steps to reproduce the issue.

Do specify the commit hash, and if you have a branch, do mention that too.

 

I see you have re-sent this mail again to mailing list, did you try measuring the stack usage of threads using the PR mentioned in previous email threads?

 

Regards,

Vinayak

 

From: devel@... <devel@...> On Behalf Of Narendar Malepu via Lists.Zephyrproject.Org
Sent: 24 March 2020 07:20
To: devel@...
Cc: devel@...
Subject: [Zephyr-devel] nrf52840 ble error #ble #nrf52840

 

Hi,

Iam using nrf52840 development board, developing software using zephyr.
In software development iam using bluetooth as a peripheral and uart in interrupt mode(to get data from other module), when iam trying to run both interfaces the getting below errors and iam included watchdog timer so after sometime it is restarting.

[00:01:36.902,862] <inf> os: prio recv thread stack : unused 336 usage 112 / 448 (25 %)

[00:01:36.902,893] <err> os: ***** BUS FAULT *****

[00:01:36.902,893] <err> os:   Imprecise data bus error

[00:01:36.902,923] <err> os: r0/a1:  0x00000029  r1/a2:  0x00000004  r2/a3:  0x00000000

[00:01:36.902,923] <err> os: r3/a4:  0x20004a0c r12/ip:  0x00000000 r14/lr:  0x000388fb

[00:01:36.902,923] <err> os:  xpsr:  0x61000000

[00:01:36.902,923] <err> os: Faulting instruction address (r15/pc): 0x000390ee

[00:01:36.902,923] <err> os: >>> ZEPHYR FATAL ERROR 0: CPU exception on CPU 0

[00:01:36.902,923] <err> os: Current thread: 0x20000eec (unknown)

[00:01:37.159,637] <err> os: Halting system

When i checked with above address error is at
zephyr/include/sys/dlist.h:211

can someone help with above error

Thanks

Upcoming Event: Zephyr Project: APIs - Tue, 03/24/2020 9:00am-10:00am, Please RSVP #cal-reminder

devel@lists.zephyrproject.org Calendar <devel@...>
 

Reminder: Zephyr Project: APIs

When: Tuesday, 24 March 2020, 9:00am to 10:00am, (GMT-07:00) America/Los Angeles

Where:https://zoom.us/j/177647878

An RSVP is requested. Click here to RSVP

Organizer: devel@...

Description: Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/177647878

Or iPhone one-tap :
    US: +16465588656,,177647878# or +16699006833,,177647878# 
Or Telephone:
    Dial(for higher quality, dial a number based on your current location): 
        US: +1 646 558 8656 or +1 669 900 6833 or +1 855 880 1246 (Toll Free) or +1 877 369 0926 (Toll Free)
    Meeting ID: 177 647 878
    International numbers available: https://zoom.us/zoomconference?m=ioAR9GK1OE5LkN1ojt-heTCl7yPcJrhY


 Live meeting minutes: https://docs.google.com/document/d/1lv-8B5QE2m4FjBcvfqAXFIgQfW5oz6306zJ7GIZIWCk/edit?usp=sharing

Re: net_buf: non-atomic reference counting

Paul Sokolovsky
 

Hello,

On Tue, 24 Mar 2020 11:25:48 +0200
"Jukka Rissanen" <jukka.rissanen@...> wrote:

Hi Darryl,

I think it is more of a historical relic than a purpose design. There
has not been any reports that this have caused issues. Patches are
welcome of course.
Perhaps it could be rephrased differently: net_buf is more like Zephyr's
internal system object. Where it's used currently, thread
synchronization is expected(*) to happen on different level(s), and
net_buf itself is kept lightweight and optimized. Perhaps that can be
changed, but effects on existing subsystems using net_buf should be
considered.

(*) That doesn't mean there're no bugs, so reproducible bugreports are
welcome.


Cheers,
Jukka


On Sun, 2020-03-22 at 17:39 -0700, Darryl Gamroth wrote:
Hi all,

I was looking at using net_bufs for an application broadcasting
reference counted buffers to multiple threads and I noticed the
reference counting is not atomic. I'm curious, is this by design?

Thanks.

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

API meeting: agenda

Carles Cufi
 

Hi all,

Note: This is the last week where the meeting takes place at 17h CET. Next week we go back to 18h CET.

Today's topics:

- How to document standalone drivers like the enc28j60 (Piotr)

- Upgrade the hwinfo API to stable
- PR: https://github.com/zephyrproject-rtos/zephyr/pull/23661

- RTC API proposal
- PR: https://github.com/zephyrproject-rtos/zephyr/pull/23526/commits/2880ee02b0f2fd91d897d8a11a4cbdefe87a19b0

- Naming in the async_notify module
- PR: https://github.com/zephyrproject-rtos/zephyr/pull/23601

Additional items in the "Triage" column in the GitHub project may be discussed if time permits.
If you want an item included in the meeting, please add it to the GitHub project.

https://github.com/zephyrproject-rtos/zephyr/wiki/Zephyr-Committee-and-Working-Group-Meetings#zephyr-api-discussion
https://github.com/zephyrproject-rtos/zephyr/projects/18
https://docs.google.com/document/d/1lv-8B5QE2m4FjBcvfqAXFIgQfW5oz6306zJ7GIZIWCk/edit

Regards,

Carles

Re: net_buf: non-atomic reference counting

Jukka Rissanen
 

Hi Darryl,

I think it is more of a historical relic than a purpose design. There
has not been any reports that this have caused issues. Patches are
welcome of course.

Cheers,
Jukka

On Sun, 2020-03-22 at 17:39 -0700, Darryl Gamroth wrote:
Hi all,

I was looking at using net_bufs for an application broadcasting
reference counted buffers to multiple threads and I noticed the
reference counting is not atomic. I'm curious, is this by design?

Thanks.

Re: nrf52840 ble error #ble #nrf52840

Chettimada, Vinayak Kariappa
 

Please create a github issue with details of building your application and steps to reproduce the issue.

Do specify the commit hash, and if you have a branch, do mention that too.

 

I see you have re-sent this mail again to mailing list, did you try measuring the stack usage of threads using the PR mentioned in previous email threads?

 

Regards,

Vinayak

 

From: devel@... <devel@...> On Behalf Of Narendar Malepu via Lists.Zephyrproject.Org
Sent: 24 March 2020 07:20
To: devel@...
Cc: devel@...
Subject: [Zephyr-devel] nrf52840 ble error #ble #nrf52840

 

Hi,

Iam using nrf52840 development board, developing software using zephyr.
In software development iam using bluetooth as a peripheral and uart in interrupt mode(to get data from other module), when iam trying to run both interfaces the getting below errors and iam included watchdog timer so after sometime it is restarting.

[00:01:36.902,862] <inf> os: prio recv thread stack : unused 336 usage 112 / 448 (25 %)

[00:01:36.902,893] <err> os: ***** BUS FAULT *****

[00:01:36.902,893] <err> os:   Imprecise data bus error

[00:01:36.902,923] <err> os: r0/a1:  0x00000029  r1/a2:  0x00000004  r2/a3:  0x00000000

[00:01:36.902,923] <err> os: r3/a4:  0x20004a0c r12/ip:  0x00000000 r14/lr:  0x000388fb

[00:01:36.902,923] <err> os:  xpsr:  0x61000000

[00:01:36.902,923] <err> os: Faulting instruction address (r15/pc): 0x000390ee

[00:01:36.902,923] <err> os: >>> ZEPHYR FATAL ERROR 0: CPU exception on CPU 0

[00:01:36.902,923] <err> os: Current thread: 0x20000eec (unknown)

[00:01:37.159,637] <err> os: Halting system

When i checked with above address error is at
zephyr/include/sys/dlist.h:211

can someone help with above error

Thanks

nrf52840 ble error #ble #nrf52840

Narendar Malepu
 

Hi,

Iam using nrf52840 development board, developing software using zephyr.
In software development iam using bluetooth as a peripheral and uart in interrupt mode(to get data from other module), when iam trying to run both interfaces the getting below errors and iam included watchdog timer so after sometime it is restarting.

[00:01:36.902,862] <inf> os: prio recv thread stack : unused 336 usage 112 / 448 (25 %)
[00:01:36.902,893] <err> os: ***** BUS FAULT *****
[00:01:36.902,893] <err> os:   Imprecise data bus error
[00:01:36.902,923] <err> os: r0/a1:  0x00000029  r1/a2:  0x00000004  r2/a3:  0x00000000
[00:01:36.902,923] <err> os: r3/a4:  0x20004a0c r12/ip:  0x00000000 r14/lr:  0x000388fb
[00:01:36.902,923] <err> os:  xpsr:  0x61000000
[00:01:36.902,923] <err> os: Faulting instruction address (r15/pc): 0x000390ee
[00:01:36.902,923] <err> os: >>> ZEPHYR FATAL ERROR 0: CPU exception on CPU 0
[00:01:36.902,923] <err> os: Current thread: 0x20000eec (unknown)
[00:01:37.159,637] <err> os: Halting system

When i checked with above address error is at
zephyr/include/sys/dlist.h:211

can someone help with above error

Thanks

net_buf: non-atomic reference counting

Darryl Gamroth
 

Hi all,

I was looking at using net_bufs for an application broadcasting reference counted buffers to multiple threads and I noticed the reference counting is not atomic. I'm curious, is this by design?

Thanks.

[API stability change] Request to change the stability of HWINFO from unstable to stable

Alexander Wachter <alexander@...>
 

Dear all,

This email is a request to change the stability of the Hardware Information API from "unstable" to "stable".

Pull-request: #23661
Discussion in the API meeting takes place on Tuesday, March 24th.

If there are any objections, please comment on the PR or attend to the API meeting.

Kind regards,

--
Alexander Wachter

The guy who introduced this API

Zephyr Toolchain Working Group Meeting – 19 March 2020

Rasmussen, Torsten
 

Hi,

 

Today’s meeting minutes:

https://docs.google.com/document/d/1IQKBK-GcJNZG0O9QArqYfvb6Huk5xHscN-XIGEZr-z8/

 

Notes/Minutes

Status updates

  • Status update from Wayne regarding PR#22668
    • No news.
  • Status update from Thomas regarding IAR: Nothing new. regarding PR#22668
    • Has been working on two routes: 
      • CMake
        • work has come fairly far.
        • not able to build entire chain, but fairly close,

expect to hit same include files issue, as with using IAR IDE.

      • IAR IDE
        • Struggle with include file issue, as there are much gcc specific include (gcc assembly)

This will be hard to solve.

      • IAR Linking
        • IAR has --whole-archive support, so should not be an issue.
      • Thomas has looked into linker script generation in other projects
        • TF-M generates toolchain specific linker script.
          Those are based on toolchain specific templates.
        • Mbed specific linker script for each toolchain.
        • cmsis uses memory layer on target

There are attributes set per target regarding memory:

read-only

read-write

Settings are specified in an xml file

 

AP:

  •  Nothing new

 

Short term goals:

  • Toolchain test cases
    • Test cases should not be ordinary Zephyr tests

Could be completely different test system with focus on:

      • Optimization
      • Linker
      • archive
    • Should test features that is known to be used inside Zephyr
      • Determine what is most important to test / ensure support for.
    • Needs to work with any toolchain, also out-of-tree toolchains.

 

Toolchain abstraction:

  • Several choices in current Zephyr originates from the early KBuild solution, as example, the cross-compiler interface.
    • Consider to drop compatibility to old legacy, in order to ease the process of going forward.
      • Things was carried over from KBuild, without cleaning up
      • Consider drop support for not-used features
  • Support for toolchain files

 

  • Current situation is that in order to add additional toolchain support, then there is a need to implement a lot of macros, even macros that is of no interest, and thus just empty.
    • To improve:
      The toolchain abstraction interface must be improved. (Agreed by everyone)
      • Note: It is still important to ensure the possibility of out-of-tree toolchains.
        Also, keep in mind there are users that are using the current toolchain abstraction interface.

 

Linker

  • What Zephyr faces, is a common issue
    • What have other done
    • What Zephyr solves might be useful for others (generic solution)
  • Step 1) Get it working for Zephyr, but have the generic support in mind.

 

 

Best regards

 

Torsten T. Rasmussen

Upcoming Event: Zephyr Project: Dev Meeting - Thu, 03/19/2020 8:00am-9:00am, Please RSVP #cal-reminder

devel@lists.zephyrproject.org Calendar <devel@...>
 

Reminder: Zephyr Project: Dev Meeting

When: Thursday, 19 March 2020, 8:00am to 9:00am, (GMT-07:00) America/Los Angeles

Where:https://zoom.us/j/993312203

An RSVP is requested. Click here to RSVP

Organizer: devel@...

Description: Join Zoom Meeting
https://zoom.us/j/993312203

One tap mobile
+16699006833,,993312203# US (San Jose)
+16465588656,,993312203# US (New York)

Dial by your location
        +1 669 900 6833 US (San Jose)
        +1 646 558 8656 US (New York)
        +1 877 369 0926 US Toll-free
        +1 855 880 1246 US Toll-free
Meeting ID: 993 312 203
Find your local number: https://zoom.us/u/ankEMRagf

Zephyr Toolchain Working Group - Thu, 03/19/2020 #cal-notice

devel@lists.zephyrproject.org Calendar <noreply@...>
 

Zephyr Toolchain Working Group

When:
Thursday, 19 March 2020
7:00am to 8:00am
(GMT-07:00) America/Los Angeles

Where:
https://zoom.us/j/967549258

Description:
Zephyr Working Group is inviting you to a scheduled Zoom meeting.

 

Topic:  Zephyr Toolchain Working Group

Time: Mar 19, 2020 07:00 AM Pacific Time (US and Canada)

        Every 2 weeks on Thu, until Jul 23, 2020, 10 occurrence(s)

        Mar 19, 2020 07:00 AM

        Apr 2, 2020 07:00 AM

        Apr 16, 2020 07:00 AM

        Apr 30, 2020 07:00 AM

        May 14, 2020 07:00 AM

        May 28, 2020 07:00 AM

        Jun 11, 2020 07:00 AM

        Jun 25, 2020 07:00 AM

        Jul 9, 2020 07:00 AM

        Jul 23, 2020 07:00 AM

Please download and import the following iCalendar (.ics) files to your calendar system.

Weekly: https://zoom.us/meeting/tJIqcu2hrD4id0z59MlGQgtjfduqRH_iTA/ics?icsToken=98tyKuCuqT4uE9aQuF39e7cqA97lbN-1i3UesPYEsRPCMidHaAXyI_NwGo12JPmB

 

Join Zoom Meeting

https://zoom.us/j/967549258

 

Meeting ID: 967 549 258

 

One tap mobile

+16699006833,,967549258# US (San Jose)

+16465588656,,967549258# US (New York)

 

Dial by your location

        +1 669 900 6833 US (San Jose)

        +1 646 558 8656 US (New York)

        855 880 1246 US Toll-free

        877 369 0926 US Toll-free

        +1 647 558 0588 Canada

        855 703 8985 Canada Toll-free

Meeting ID: 967 549 258

Find your local number: https://zoom.us/u/abfRKTHWtN

 


Live meeting minutes: https://docs.google.com/document/d/1IQKBK-GcJNZG0O9QArqYfvb6Huk5xHscN-XIGEZr-z8/edit#heading=h.x36xe8bnwr9r

Dev-Review Meeting Agenda Mar 19 2020

Kumar Gala
 

Agenda:

* Review any open PR / issues with dev-review label
* Device Tree update / next steps (Kumar & Marti)
* Power Management thoughts / initial ideas / plans (Peter)
* Pinmux / DT (Piotr)

If you have anything you’d like to add let me know

Thanks

- k

Upcoming Event: Zephyr Toolchain Working Group - Thu, 03/19/2020 7:00am-8:00am #cal-reminder

devel@lists.zephyrproject.org Calendar <devel@...>
 

Reminder: Zephyr Toolchain Working Group

When: Thursday, 19 March 2020, 7:00am to 8:00am, (GMT-07:00) America/Los Angeles

Where:https://zoom.us/j/967549258

View Event

Organizer: Maureen Helm

Description: Zephyr Working Group is inviting you to a scheduled Zoom meeting.

 

Topic:  Zephyr Toolchain Working Group

Time: Mar 19, 2020 07:00 AM Pacific Time (US and Canada)

        Every 2 weeks on Thu, until Jul 23, 2020, 10 occurrence(s)

        Mar 19, 2020 07:00 AM

        Apr 2, 2020 07:00 AM

        Apr 16, 2020 07:00 AM

        Apr 30, 2020 07:00 AM

        May 14, 2020 07:00 AM

        May 28, 2020 07:00 AM

        Jun 11, 2020 07:00 AM

        Jun 25, 2020 07:00 AM

        Jul 9, 2020 07:00 AM

        Jul 23, 2020 07:00 AM

Please download and import the following iCalendar (.ics) files to your calendar system.

Weekly: https://zoom.us/meeting/tJIqcu2hrD4id0z59MlGQgtjfduqRH_iTA/ics?icsToken=98tyKuCuqT4uE9aQuF39e7cqA97lbN-1i3UesPYEsRPCMidHaAXyI_NwGo12JPmB

 

Join Zoom Meeting

https://zoom.us/j/967549258

 

Meeting ID: 967 549 258

 

One tap mobile

+16699006833,,967549258# US (San Jose)

+16465588656,,967549258# US (New York)

 

Dial by your location

        +1 669 900 6833 US (San Jose)

        +1 646 558 8656 US (New York)

        855 880 1246 US Toll-free

        877 369 0926 US Toll-free

        +1 647 558 0588 Canada

        855 703 8985 Canada Toll-free

Meeting ID: 967 549 258

Find your local number: https://zoom.us/u/abfRKTHWtN

 


Live meeting minutes: https://docs.google.com/document/d/1IQKBK-GcJNZG0O9QArqYfvb6Huk5xHscN-XIGEZr-z8/edit#heading=h.x36xe8bnwr9r

Re: Socket Poll functionality in case of socket is closed

Ravi kumar Veeramally
 

Hi,

Thanks for clarification.

Ravi

On 19/03/2020 14.30, Paul Sokolovsky wrote:
Hello,

On Wed, 18 Mar 2020 11:34:00 +0200
"Ravi kumar Veeramally" <ravikumar.veeramally@...> wrote:

Hi,

what should be the return value or behavior of socket poll() call in
case of TCP socket is closed from peer side.
If a peer closes TCP connection from its side, it's effectively an
analog of EOF condition. In this case, poll() should return POLLIN.
This will cause a client to issue a recv()/read() call, which will
return 0, and will let a client detect the EOF condition.

This is one of the "most basic" of "not immediately obvious" API
contracts re: sockets and polling. It's definitely something like that,
because quickly looking for normative references in the POSIX standard,
I can't find them, e.g. in
https://pubs.opengroup.org/onlinepubs/9699919799/functions/poll.html
this particular case isn't described (some other "not immediately
obvious" cases are). So, it's a kind of common knowledge, and a lot of
software relies on that behavior (well, it's not possible to write
async socket code without it). If you google for it, you should be able
to find a lot of references.

Note that there's also a POLLHUP flag, behavior of which in regard to
sockets is "less clear" and "somewhat of a gray area".


As per
https://github.com/zephyrproject-rtos/zephyr/blob/master/subsys/net/lib/sockets/sockets.c#L1018,
zsock_poll_prepare_ctx() call returns -EALREADY.
zsock_poll_prepare_ctx() is an internal function, which uses a special
internal API contract, where particular error codes are used to signal
very specific conditions. -EALREADY is one of such codes. It doesn't
reach public API clients (and doesn't have the same meaning as POSIX
EALREADY error).

But
https://github.com/zephyrproject-rtos/zephyr/blob/master/subsys/net/lib/sockets/sockets.c#L1088.
Return value of z_fdtable_call_ioctl() function call handler assumes
"If POLL_PREPARE returned with EALREADY, it means it already detected
that some socket is ready."
Right, to achieve the behavior described above.

I did a simple test with few modifications in echo-client and
echo-server in net tools. echo-server closes the client connection.
poll(fds, nfds, 0) call returns "> 0" and error value set to 0. But
send failed with return value -ve and error value set to ESHUTDOWN.
That sounds *about* right. Except that POSIX requires EPIPE to be
returned trying to write to a socket with underlying connection closed.
Or to be more exact, with the quote
(https://pubs.opengroup.org/onlinepubs/9699919799/functions/send.html):

-------
[EPIPE]
The socket is shut down for writing, or the socket is
connection-mode and is no longer connected. In the latter case, and if
the socket is of type SOCK_STREAM or SOCK_SEQPACKET and the
MSG_NOSIGNAL flag is not set, the SIGPIPE signal is generated to the
calling thread.
-------

So, if we return ESHUTDOWN, we should change that to EPIPE.


If your mail trails to the ultimate question of "how to detect
peer-closed socket if we called poll with POLLOUT?", then to keep it
short:

a) Hmm, I don't have an answer right away, though I bet I used to
consider it (likely outside Zephyr context).
b) I bet that's where POLLHUP return status kicks in.
c) In all cases like that, where we can't "extract" normative behavior
description from POSIX, we should check and follow the behavior of a
well-know implementation, and that's definitely Linux.


Any thoughts @rlubos <https://github.com/rlubos> @pfalcon
<https://github.com/pfalcon>?
Please don't hesitate to cc: me on mails like this, I may sometimes not
check the mailing list for a few days.

Regards,

Ravi.
[]

Zephyr Toolchain Working Group Meeting – 19 March 2020

Rasmussen, Torsten
 

Hi,

 

For today’s meeting let’s follow up on last meeting action items and get a status update.

Also I think we should continue the talk on the short goals, to get some progress.

Where:
https://zoom.us/j/967549258

Agenda

  • Updates:
    • Wayne: PR22668: Anything new ?
    • Thomas: IAR: Get basic hello world compiling, (linking with GCC) : Status ?
  • Short term goals, way forward
    • Dedicated toolchain test cases, 
    • Label PR for automatic execution of CI Toolchain test cases
  • Toolchain abstraction: Re-opened: https://github.com/zephyrproject-rtos/zephyr/issues/16031

 

 

 

 

Feel free to send a mail, if you would like additional topics to be discussed.

 

Best regards

 

Torsten T. Rasmussen           

 

Live meeting minutes: https://docs.google.com/document/d/1IQKBK-GcJNZG0O9QArqYfvb6Huk5xHscN-XIGEZr-z8/edit#heading=h.x36xe8bnwr9r

 

           

 

Re: Socket Poll functionality in case of socket is closed

Paul Sokolovsky
 

Hello,

On Wed, 18 Mar 2020 11:34:00 +0200
"Ravi kumar Veeramally" <ravikumar.veeramally@...> wrote:

Hi,

what should be the return value or behavior of socket poll() call in
case of TCP socket is closed from peer side.
If a peer closes TCP connection from its side, it's effectively an
analog of EOF condition. In this case, poll() should return POLLIN.
This will cause a client to issue a recv()/read() call, which will
return 0, and will let a client detect the EOF condition.

This is one of the "most basic" of "not immediately obvious" API
contracts re: sockets and polling. It's definitely something like that,
because quickly looking for normative references in the POSIX standard,
I can't find them, e.g. in
https://pubs.opengroup.org/onlinepubs/9699919799/functions/poll.html
this particular case isn't described (some other "not immediately
obvious" cases are). So, it's a kind of common knowledge, and a lot of
software relies on that behavior (well, it's not possible to write
async socket code without it). If you google for it, you should be able
to find a lot of references.

Note that there's also a POLLHUP flag, behavior of which in regard to
sockets is "less clear" and "somewhat of a gray area".



As per
https://github.com/zephyrproject-rtos/zephyr/blob/master/subsys/net/lib/sockets/sockets.c#L1018,
zsock_poll_prepare_ctx() call returns -EALREADY.
zsock_poll_prepare_ctx() is an internal function, which uses a special
internal API contract, where particular error codes are used to signal
very specific conditions. -EALREADY is one of such codes. It doesn't
reach public API clients (and doesn't have the same meaning as POSIX
EALREADY error).

But
https://github.com/zephyrproject-rtos/zephyr/blob/master/subsys/net/lib/sockets/sockets.c#L1088.
Return value of z_fdtable_call_ioctl() function call handler assumes
"If POLL_PREPARE returned with EALREADY, it means it already detected
that some socket is ready."
Right, to achieve the behavior described above.

I did a simple test with few modifications in echo-client and
echo-server in net tools. echo-server closes the client connection.
poll(fds, nfds, 0) call returns "> 0" and error value set to 0. But
send failed with return value -ve and error value set to ESHUTDOWN.
That sounds *about* right. Except that POSIX requires EPIPE to be
returned trying to write to a socket with underlying connection closed.
Or to be more exact, with the quote
(https://pubs.opengroup.org/onlinepubs/9699919799/functions/send.html):

-------
[EPIPE]
The socket is shut down for writing, or the socket is
connection-mode and is no longer connected. In the latter case, and if
the socket is of type SOCK_STREAM or SOCK_SEQPACKET and the
MSG_NOSIGNAL flag is not set, the SIGPIPE signal is generated to the
calling thread.
-------

So, if we return ESHUTDOWN, we should change that to EPIPE.


If your mail trails to the ultimate question of "how to detect
peer-closed socket if we called poll with POLLOUT?", then to keep it
short:

a) Hmm, I don't have an answer right away, though I bet I used to
consider it (likely outside Zephyr context).
b) I bet that's where POLLHUP return status kicks in.
c) In all cases like that, where we can't "extract" normative behavior
description from POSIX, we should check and follow the behavior of a
well-know implementation, and that's definitely Linux.



Any thoughts @rlubos <https://github.com/rlubos> @pfalcon
<https://github.com/pfalcon>?
Please don't hesitate to cc: me on mails like this, I may sometimes not
check the mailing list for a few days.


Regards,

Ravi.
[]

--
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: nrf52840 ble error #ble #nrf52840

Narendar Malepu
 

But i'm not using any threads in my application, did you mean ble created threads


On Wed, Mar 18, 2020 at 6:45 PM Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@...> wrote:

Sorry, forgot to paste the link:

 

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

 

-Vinayak

 

From: devel@... <devel@...> On Behalf Of Chettimada, Vinayak Kariappa via Lists.Zephyrproject.Org
Sent: 18 March 2020 14:04
To: Narendar Malepu <narendarm@...>
Cc: devel@...
Subject: Re: [Zephyr-devel] nrf52840 ble error #ble #nrf52840

 

Please identify and increase thread stack size based on your application code.  You can use the implementation in this PR to analyse stack usage.

 

-Vinayak

 

From: Narendar Malepu <narendarm@...>
Sent: 18 March 2020 13:33
To: Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@...>
Cc: devel@...
Subject: Re: [Zephyr-devel] nrf52840 ble error #ble #nrf52840

 

Hi Vinayak Kariappa,

 

Here is the result for above command

zephyr/include/sys/dlist.h:211

 

On Wed, Mar 18, 2020 at 12:57 PM Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@...> wrote:

Please provide the details of:

# arm-none-eabi-addr2line -e <path to zephyr.elf file> 0x000390ee

 

-Vinayak

 

From: devel@... <devel@...> On Behalf Of Narendar Malepu via Lists.Zephyrproject.Org
Sent: 17 March 2020 14:12
To: devel@...
Cc: devel@...
Subject: [Zephyr-devel] nrf52840 ble error #ble #nrf52840

 

Hi,

Iam using nrf52840 development board, developing software using zephyr.
In software development iam using bluetooth as a peripheral and uart in interrupt mode(to get data from other module), when iam trying to run both interfaces the getting below errors and iam included watchdog timer so after sometime it is restarting.

[00:01:36.902,862] <inf> os: prio recv thread stack : unused 336 usage 112 / 448 (25 %)

[00:01:36.902,893] <err> os: ***** BUS FAULT *****

[00:01:36.902,893] <err> os:   Imprecise data bus error

[00:01:36.902,923] <err> os: r0/a1:  0x00000029  r1/a2:  0x00000004  r2/a3:  0x00000000

[00:01:36.902,923] <err> os: r3/a4:  0x20004a0c r12/ip:  0x00000000 r14/lr:  0x000388fb

[00:01:36.902,923] <err> os:  xpsr:  0x61000000

[00:01:36.902,923] <err> os: Faulting instruction address (r15/pc): 0x000390ee

[00:01:36.902,923] <err> os: >>> ZEPHYR FATAL ERROR 0: CPU exception on CPU 0

[00:01:36.902,923] <err> os: Current thread: 0x20000eec (unknown)

[00:01:37.159,637] <err> os: Halting system

can someone help me with above problem.

Thanks