Date   
Need guidance for L2CAP programing

Ameer Tamboli <tamboli664@...>
 

Dear Sir/Madam,
Greetings of the day..! Presently I'm working on BLE with Zephyr RTOS + nrf52840DK board. While programming I'm stuck, as I wish to connect my remote device through l2cap. 
I tried to write using the API mentioned in l2cap.h but did not succed. 
Please help me in this regard.

Thank you,

Ameer S. Tamboli
+917709922348
Embedded Engineer

nRF Mesh Sample

Muhammad Muh <muhammad.muh83@...>
 

Dear Respectable Group Members,

Good Morning,

I hope you all will be doing well in this COVID 19 situation.

Regarding Zephyr, I am facing a problem in running the nrf mesh example. I will be grateful if you can help me in this regard.

Example: /home/muhammad/zephyrproject/zephyr/samples/boards/nrf/mesh/onoff-app.

I am using nrf52840_pca10056 DK, after flashing the board (west flash), the example runs fine prior to the provisioning process each button is controlling the state of its
the corresponding LED".
Moreover, after I provision the device with the help of application nRF Mesh installed on my mobile, the messages are not being sent and receive as given in the readme file. For your information, I am using (Putty) for debugging.

I will be grateful if you can help me in this regard.

Stay Safe

Best Regards
Muhammad

[Zephyr 2.3] Current status as of 14th of May

Carles Cufi
 

Hi all,

This is the current bug status for Zephyr 2.3 as of today.

High priority bugs: 8 (threshold for release is ==0)
https://github.com/zephyrproject-rtos/zephyr/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+label%3Abug+label%3A%22priority%3A+high%22+sort%3Aupdated-desc+-milestone%3Av1.14.1+-milestone%3Av1.14.2+

Medium priority bugs: 43 (threshold for release is <=20)
https://github.com/zephyrproject-rtos/zephyr/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+label%3Abug+label%3A%22priority%3A+medium%22+sort%3Aupdated-desc+-milestone%3Av1.14.1+-milestone%3Av1.14.2+

Since we are currently quite far away from the required thresholds in order to release 2.3.0, I would like to ask you all to go through the bug lists and try to fix (or close if they are no long applicable) as many as possible so that we do not need to delay the current tentative release date of May 29th.

Thank you all in advance.

Carles

Re: Dev-Review Meeting Agenda May 14

Kumar Gala
 

On May 13, 2020, at 9:56 PM, Kumar Gala via lists.zephyrproject.org <kumar.gala=linaro.org@...> wrote:

Here’s the agenda topics for this week:

* Review PR/issues’s tagged with dev-review:

* Support for buildtesting SoCs w/o boards
https://github.com/zephyrproject-rtos/zephyr/issues/25153

* Remove `default:` functionality from devicetree bindings
https://github.com/zephyrproject-rtos/zephyr/issues/25164

* Any 2.3 issues that need discussion

* Any 2.4 topics / initial plans of activity.

* Any topics anyone else has.
Adding the following to the agenda:

* RFC: device: convert device struct instances to const
https://github.com/zephyrproject-rtos/zephyr/pull/25208

- k

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

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

Reminder: Zephyr Project: Dev Meeting

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

Where:Microsoft Teams Meeting

An RSVP is requested. Click here to RSVP

Organizer: devel@...

Description: Join Microsoft Teams Meeting: https://teams.microsoft.com/l/meetup-join/19%3ameeting_M2Q2ZDk4OWItMWE2MS00MTExLTkyYTQtNmUwOTA4MzgwOGYw%40thread.v2/0?context=%7b%22Tid%22%3a%22686ea1d3-bc2b-4c6f-a92c-d99c5c301635%22%2c%22Oid%22%3a%2262b63b80-05d3-4465-b5a0-f04e4e156f10%22%7d

+1 213-437-3346 United States, Los Angeles (Toll)
Conference ID: 750 623 026#


Local numbers: 
https://dialin.teams.microsoft.com/488d1b50-0dd2-4ca1-aee4-92bb50a48081?id=750623026

Zephyr Toolchain Working Group - Thu, 05/14/2020 #cal-notice

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

Zephyr Toolchain Working Group

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

Where:
Microsoft Teams Meeting

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

Join Microsoft Teams Meeting: https://teams.microsoft.com/l/meetup-join/19%3ameeting_ZGRjNzNjMjEtOWJmMi00ODUxLWE2MjEtODM0M2FiMzQxMjE5%40thread.v2/0?context=%7b%22Tid%22%3a%22686ea1d3-bc2b-4c6f-a92c-d99c5c301635%22%2c%22Oid%22%3a%2262b63b80-05d3-4465-b5a0-f04e4e156f10%22%7d

+1 213-437-3346 United States, Los Angeles (Toll)

Conference ID: 570 955 823#

Local numbers: 
https://dialin.teams.microsoft.com/488d1b50-0dd2-4ca1-aee4-92bb50a48081?id=570955823

 


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

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

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

Reminder: Zephyr Toolchain Working Group

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

Where:Microsoft Teams Meeting

View Event

Organizer: Maureen Helm

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

Join Microsoft Teams Meeting: https://teams.microsoft.com/l/meetup-join/19%3ameeting_ZGRjNzNjMjEtOWJmMi00ODUxLWE2MjEtODM0M2FiMzQxMjE5%40thread.v2/0?context=%7b%22Tid%22%3a%22686ea1d3-bc2b-4c6f-a92c-d99c5c301635%22%2c%22Oid%22%3a%2262b63b80-05d3-4465-b5a0-f04e4e156f10%22%7d

+1 213-437-3346 United States, Los Angeles (Toll)

Conference ID: 570 955 823#

Local numbers: 
https://dialin.teams.microsoft.com/488d1b50-0dd2-4ca1-aee4-92bb50a48081?id=570955823

 


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

Zephyr Toolchain Working Group Meeting – 14 May 2020

Rasmussen, Torsten
 

*******************************

 

NOTE: We will be using Microsoft Teams for this meeting instead of zoom.  The link is found below.

 

*******************************

 

Hi,

 

Due to lack of people on last meeting, we have the same agenda.


Agenda

  • Updates:
  • Short term goals, way forward
    • Dedicated toolchain test cases.
    • Label PR for automatic execution of CI Toolchain test cases

 

 

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

________________________________________________________________________________

 

Join Microsoft Teams Meeting

+1 213-437-3346   United States, Los Angeles (Toll)

Conference ID: 570 955 823#

Local numbers | Reset PIN | Learn more about Teams | Meeting options

________________________________________________________________________________

 

Dev-Review Meeting Agenda May 14

Kumar Gala
 

Here’s the agenda topics for this week:

* Review PR/issues’s tagged with dev-review:

* Support for buildtesting SoCs w/o boards
https://github.com/zephyrproject-rtos/zephyr/issues/25153

* Remove `default:` functionality from devicetree bindings
https://github.com/zephyrproject-rtos/zephyr/issues/25164

* Any 2.3 issues that need discussion

* Any 2.4 topics / initial plans of activity.

* Any topics anyone else has.

- k

Re: Unable to run USB samples on STM32F411E-DISCO #samples

bbradley@...
 

Thanks for the feedback. I will go ahead and create an issue on github to describe the issue and show what I have tried so far.

Thanks!
Brian

Re: Unable to run USB samples on STM32F411E-DISCO #samples

Erwan Gouriou
 

Hi Brian,

Raising an issue would indeed help to provide support.
Don't hesitate to share the work you've already done to ease things.

BR
Erwan

On Tue, 12 May 2020 at 21:14, <bbradley@...> wrote:
So I think there are a few things going on here, and have begun to unravel it but I might need some guidance on how to proceed. 

I intend to utilize the STM32F411E MCU on an upcoming board, but I wanted to test the DISCO board in zephyr to get a feel for it first. One of the features I will need is USB, which the DISCO board appears to have available in the form of an OTG port. I only need the cdc mode of operation, so I think this shouldn't be too difficult of a task.

I pretty quickly realized that USB wasn't supported on this board on latest version of zephyr (2.3-rc0), so I started by trying to add it. I was able to get it compiled pretty quickly with some changes to the dts and pinmux.c by referencing other implementations and the datasheet for the MCU. 

So after some minor changes, I was able to get it to compile without any problems. Upon flashing it to the board *something* appears to be happening, but I am not sure if there is more that I am missing. Right now, the USB_OTG LED is illuminating on the DISCO board, which I think indicates something is happening, and the Device Manager (Windows 10) is recognizing a device, which is also good. But it is unable to setup the device and giving a "Device Descriptor Request Failed" error. I am curious if I am missing some additional steps to properly implement USB, and if I should possibly start an issue and work towards a PR on github.

Thanks for any advice!
Brian

Unable to run USB samples on STM32F411E-DISCO #samples

bbradley@...
 

So I think there are a few things going on here, and have begun to unravel it but I might need some guidance on how to proceed. 

I intend to utilize the STM32F411E MCU on an upcoming board, but I wanted to test the DISCO board in zephyr to get a feel for it first. One of the features I will need is USB, which the DISCO board appears to have available in the form of an OTG port. I only need the cdc mode of operation, so I think this shouldn't be too difficult of a task.

I pretty quickly realized that USB wasn't supported on this board on latest version of zephyr (2.3-rc0), so I started by trying to add it. I was able to get it compiled pretty quickly with some changes to the dts and pinmux.c by referencing other implementations and the datasheet for the MCU. 

So after some minor changes, I was able to get it to compile without any problems. Upon flashing it to the board *something* appears to be happening, but I am not sure if there is more that I am missing. Right now, the USB_OTG LED is illuminating on the DISCO board, which I think indicates something is happening, and the Device Manager (Windows 10) is recognizing a device, which is also good. But it is unable to setup the device and giving a "Device Descriptor Request Failed" error. I am curious if I am missing some additional steps to properly implement USB, and if I should possibly start an issue and work towards a PR on github.

Thanks for any advice!
Brian

Zephyr SDK 0.11.x and Python support query

Kumar Gala
 

As part of the SDK 0.11.x SDK we moved from python2.7 to python3.6 as the version of python that GDB is linked against, partially due to the deprecation of python2.7.

There have been several issues opened about this on various Linux distributions. It was suggested that Python3.8 would be a better choice since there are options on most of the major distribution versions to install a python3.8 package.

I wanted to see if this change caused any major concerns.

If you want to test out the python3.8 version, here’s a link a test SDK build:

https://builds.zephyrproject.org/zephyrproject-rtos/sdk-ng/210/zephyr-sdk-0.11.3-beta-1-pr-210-setup.run

Please let me know by end of Thur (May 14th) if you have concerns.

Thanks

- k

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

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

Reminder: Zephyr Project: APIs

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

Where:Microsoft Teams Meeting

An RSVP is requested. Click here to RSVP

Organizer: devel@...

Description: Join Microsoft Teams Meeting:
https://teams.microsoft.com/l/meetup-join/19%3ameeting_YzYzZTAzNGItOWFiMS00MDBkLTkyYmMtNzljZjkwNDVlMThm%40thread.v2/0?context=%7b%22Tid%22%3a%22686ea1d3-bc2b-4c6f-a92c-d99c5c301635%22%2c%22Oid%22%3a%2262b63b80-05d3-4465-b5a0-f04e4e156f10%22%7d

+1 213-437-3346 United States, Los Angeles (Toll)

Conference ID: 262 362 129#

Local numbers: 
https://dialin.teams.microsoft.com/488d1b50-0dd2-4ca1-aee4-92bb50a48081?id=262362129


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

API meeting: agenda

Carles Cufi
 

Hi all,

*************************************************
We will be using Teams instead of Zoom:
https://teams.microsoft.com/l/meetup-join/19%3ameeting_YzYzZTAzNGItOWFiMS00MDBkLTkyYmMtNzljZjkwNDVlMThm%40thread.v2/0?context=%7b%22Tid%22%3a%22686ea1d3-bc2b-4c6f-a92c-d99c5c301635%22%2c%22Oid%22%3a%2262b63b80-05d3-4465-b5a0-f04e4e156f10%22%7d
*************************************************

Today's topics:

- dma: enable edma drivers for mcux
- PR https://github.com/zephyrproject-rtos/zephyr/pull/23689

- Documenting API behavior in Doxygen:
- Issue: https://github.com/zephyrproject-rtos/zephyr/issues/18970
- Issue: https://github.com/zephyrproject-rtos/zephyr/issues/21061

- RTC API follow-up (if the relevant people are present and there is material for discussion)
- PR: https://github.com/zephyrproject-rtos/zephyr/pull/23526

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

[Zephyr 2.3] Please set the 2.3.0 milestone on all relevant PRs

Carles Cufi
 

Hi all,

I'd like to ask you to set the milestone in all Pull Requests that need to be merged during the stabilization period (be them bugfix and documentation or special cases, in which case they also require the "TSC" label).
This will help filter out any PRs that can wait until 2.3 is released, thus alleviating the burden on reviewers and maintainers.

Thanks in advance.

Regards,

Carles

Re: #networking #ppp #gsm_modem #mbedtls #ppp #gsm_modem #mbedtls #networking

Bo.Kragelund@...
 

Hi Jukka
And thank you very much for your very quick answer.
I am sorry I haven't repsonded before, but we had a national Holiday in Denmark Friday the 8th.

I will try to answer on your comments.

Regarding the buffer counts, having a value of 14 is written in the documentation of zephyr 2.2.0 as the link below shows.
https://docs.zephyrproject.org/2.2.0/reference/kconfig/CONFIG_NET_PKT_RX_COUNT.html?highlight=config_net_pkt_rx_count#cmdoption-arg-config-net-pkt-rx-count

Regarding the buffer counts, having a value of 36 is written in the documentation of zephyr 2.2.0 as the link below shows.
https://docs.zephyrproject.org/2.2.0/reference/kconfig/CONFIG_NET_BUF_TX_COUNT.html?highlight=config_net_buf_tx_count#cmdoption-arg-config-net-buf-tx-count

We are already using a maximum heap size for CONFIG_MBEDTLS_HEAP_SIZE of 65356.
CONFIG_MBEDTLS_SSL_MAX_CONTENT_LEN is set to 8196.
And it is the same configuration in both Ethernet and GSM modem.

Using the maximum value of 16384 for CONFIG_MBEDTLS_SSL_MAX_CONTENT_LEN gives another error of "<err> net_sock_tls: TLS handshake error: -4310" when running state MBEDTLS_SSL_CERTIFICATE_VERIFY.

Anyway, this is the "maximum" configuration we use now, where some buffers and also some NET RX and TX stacks are increased to the double of default.

I have disabled some shell to get more memory available for this.
And I am still stuck with the same error in the GSM modem variant.
The Ethernet variant still works perfect.

Again, I have attached the two auto generated header files, so they can be compared directly.
Basically the header file for Ethernet has some ETH related configuration and the GSM modem header has some MODEM and PPP related configuration.
I have also attached the two proj.cnf so they can be compared directly.
And basically you will see, that there is a section at the bottom for using GSM modem, which is based on the GSM_modem sample project.
And when building for Ethernet, you will see this section outcommented more or less, except for the buffers and some net stacks. The only other thing Ethernet variant has enabled is the DHCPV4.


Regarding using latest upstream zephyr version I have tried using 2.2.3rc1 and compare with 2.2.0.
I am only testing the gsm_modem sample project, but using UART 3 on the frdm_k64f board, which is compatible with Arduino pinout, which my modem shield uses.

Using an oscilloscope, no data is sent out on UART 3 for communicating with the modem shield, when I test with zephyr 2.2.3rc1.
Everything works fine with zephyr version 2.2.0 and I can use the net shell to ping some IP addresses, meaning the modem is being configured correct via PPP over UART 3.

What am I missing in order to sent out data on UART 3 on the frdm_k64f board??
 
There are some changes to the configuration of UART 3 between zephyr 2.2.3rc1 and 2.2.0.

In zephyr 2.2.0 the following configuration parameters are needed to make the UART 3 work, which can be seen in the attahced proj.2.2.0.conf for the gms_modem sample project:
CONFIG_SERIAL=y CONFIG_UART_MCUX_3=y CONFIG_MODEM_GSM_UART_NAME="UART_3" 

In zephyr 2.2.3rc1 it seems like CONFIG_UART_MCUX_3=y is no longer needed and I only have to set the two other configuration parameters, which can be seen in the attached proj.2.2.3rc1.conf for the gms_modem sample project: CONFIG_SERIAL=y CONFIG_MODEM_GSM_UART_NAME="UART_3"

I hope to get 2.2.3rc1 up and running to see if it solves my issues with mbedtls certificate handshaking, as you also suggest as first thing to try.

Best regards,
Bo

Re: Thread Scheduling question

Peter A. Bigot
 

> I'm not quite sure what you are trying to mitigate, exactly.  This is the desired behavior.  You WANT your two custom threads to run instead of  your main thread, that's why they're higher priority.

I think the mitigation is of Zephyr's default behavior: that the main thread is preemptible by default.  I've also run into this where starting a repeating timer with no initial delay in main caused a work item to be submitted (from interrupt) and started (from system work thread, which is default cooperative) before I'd finished configuring the work item back in main.

Not that it's wrong, but it's unexpected to have main be preemptible, and since every thread declared in the samples and drivers is cooperative people just starting with threads are likely to make this "mistake".

Peter

Re: Thread Scheduling question

Raj Gundi
 

This will help, Andy. Thanks for your inputs!

 

Regards,

Raj

 

From: Ross, Andrew J <andrew.j.ross@...>
Sent: 11 May 2020 10:53
To: Gundi, Rajavardhan <rajavardhan.gundi@...>; devel@...
Subject: Re: [Zephyr-devel] Thread Scheduling question

 

Your understanding is correct.  If a higher priority thread is available to run, then a preemptible thread will yield to that thread at every scheduling point.

I'm not quite sure what you are trying to mitigate, exactly.  This is the desired behavior.  You WANT your two custom threads to run instead of  your main thread, that's why they're higher priority.  I think you might want to revisit the priority design in your app, basically.  The priorities you've assigned to your threads don't reflect what you want them to do.

If you just need the custom threads to get out of the way at startup, why not just have them sleep a bit, or (much better) block on a semaphore or whatever waiting for main to signal them to begin.  Or you can change priorities at runtime -- have main start at a very high priority but then lower itself, for example.  Or launch the threads dynamically via k_thread_create() at runtime once you know it's safe for them to run...

Andy

On 5/10/2020 9:24 PM, Raj Gundi wrote:

Hi,

 

This is a question related to thread scheduling. Imagine you have 2 custom threads in addition to the “main thread”. The custom threads are created static (K_THREAD_DEFINE) and are cooperative threads (let’s say the priority is -5) whereas the main thread is preemptive (priority 0). Now, as soon as the main thread is handed control (via switch_to_main_thread), it is possible the scheduler gets triggered and one of the cooperative threads gets scheduled. This may be undesirable since main thread may need to get some stuff done before the cooperative threads take over.

 

Is my reading of the above situation correct? If yes, I would like to see how this can be mitigated. One easy thing is to make main thread also cooperative (say, a priority of -6). The other is to lock the scheduler as soon as the main thread is entered and unlock only after the relevant stuff is addressed. Please let me know your views.

 

Regards,

Raj

Re: Thread Scheduling question

Andy Ross
 

Your understanding is correct.  If a higher priority thread is available to run, then a preemptible thread will yield to that thread at every scheduling point.

I'm not quite sure what you are trying to mitigate, exactly.  This is the desired behavior.  You WANT your two custom threads to run instead of  your main thread, that's why they're higher priority.  I think you might want to revisit the priority design in your app, basically.  The priorities you've assigned to your threads don't reflect what you want them to do.

If you just need the custom threads to get out of the way at startup, why not just have them sleep a bit, or (much better) block on a semaphore or whatever waiting for main to signal them to begin.  Or you can change priorities at runtime -- have main start at a very high priority but then lower itself, for example.  Or launch the threads dynamically via k_thread_create() at runtime once you know it's safe for them to run...

Andy

On 5/10/2020 9:24 PM, Raj Gundi wrote:

Hi,

 

This is a question related to thread scheduling. Imagine you have 2 custom threads in addition to the “main thread”. The custom threads are created static (K_THREAD_DEFINE) and are cooperative threads (let’s say the priority is -5) whereas the main thread is preemptive (priority 0). Now, as soon as the main thread is handed control (via switch_to_main_thread), it is possible the scheduler gets triggered and one of the cooperative threads gets scheduled. This may be undesirable since main thread may need to get some stuff done before the cooperative threads take over.

 

Is my reading of the above situation correct? If yes, I would like to see how this can be mitigated. One easy thing is to make main thread also cooperative (say, a priority of -6). The other is to lock the scheduler as soon as the main thread is entered and unlock only after the relevant stuff is addressed. Please let me know your views.

 

Regards,

Raj