-----Original Message-----
From: devel@lists.zephyrproject.org <devel@lists.zephyrproject.org> On
Behalf Of Chettimada, Vinayak Kariappa
Sent: 05 October 2018 10:36
To: dhguja@gmail.com; devel@lists.zephyrproject.org
Subject: Re: [Zephyr-devel] Choosing Tx Buffers in BLE stack

Do you have a sniffer trace you can send to me email?

It appears the peer is not responding to a control procedure.

-Vinayak

-----Original Message-----
From: <devel@lists.zephyrproject.org> on behalf of "dhguja@gmail.com"
<dhguja@gmail.com>
Date: Thursday, 4 October 2018 at 11:19 AM
To: "devel@lists.zephyrproject.org" <devel@lists.zephyrproject.org>
Subject: Re: [Zephyr-devel] Choosing Tx Buffers in BLE stack




Hello All,
I did some more debugging on my problem and i noticed that
whenever the characters are stopped receiving by windows host i get a
disconnection in my device with either
LMP RESPONSE TIMEOUT / LL RESPONSE TIMEOUT (0x22) or CONNECTION
TIMEOUT (0x08)
always.

Is this expected on the zephyr side? Is there anything else i can do
from my device perspective?


I also posted my queries in MS forums and waiting for some solution
there too.

Thanks for the help.
Dhananjay G J

-----Original Message-----
From: Chettimada, Vinayak Kariappa
Sent: 05 October 2018 09:54
To: vikrant8051 <vikrant8051@gmail.com>; devel@lists.zephyrproject.org;
Cufi, Carles <Carles.Cufi@nordicsemi.no>
Subject: Re: [Zephyr-devel] Bluetooth: about latest Kernel OOPS

Hi Vikrant,

It appears a recent merged PR has introduced regression.
https://github.com/zephyrproject-rtos/zephyr/pull/10289

I am analysing the issue, meanwhile you can revert the said commit so as
to unblock your tasks.

Regards,
Vinayak

-----Original Message-----
From: <devel@lists.zephyrproject.org> on behalf of vikrant8051
<vikrant8051@gmail.com>
Date: Friday, 5 October 2018 at 9:37 AM
To: "devel@lists.zephyrproject.org" <devel@lists.zephyrproject.org>,
Carles Cufi <Carles.Cufi@nordicsemi.no>
Subject: [Zephyr-devel] Bluetooth: about latest Kernel OOPS

Hi,
Today I synced my local repo with Zephyr master & while testing with

Bluetooth Mesh App I got following Kernel OOPS:


***** Kernel OOPS! *****

Current thread ID = 0x200018c0

Faulting instruction address = 0x16d84

Fatal fault in ISR! Spinning...


I executed following command :

/opt/zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/bin/arm-zephyr-
eabi/arm-zephyr-eabi-addr2line -e zephyr.elf 0x16d84


o/p ->
/home/vikrant/zephyr/subsys/bluetooth/controller/ll_sw/ctrl.c:6353


Please suggest me how to overcome this.


Thank You !!

Hey,

Keep in mind that some Linux distros having a modemmanger. If you not having a blocking udev rule or uninstalling it, this piece of software will try to connect through your uart.

Cheers

Stefan

Hi Cale,

 

The controller doesn´t seem to be responding to the Reset command, as if perhaps the serial (UART) connection was not working.

Can you try building and flashing the “hello_world” sample and visualize the output using minicom or similar, to make sure the serial link is working?

 

Carles

 

From: Cale Collins <ccollins@...>
Date: Wednesday, 3 October 2018 at 20:48
To: "Cufi, Carles" <Carles.Cufi@...>
Cc: "devel@..." <devel@...>, Luiz Augusto von Dentz <luiz.dentz@...>
Subject: Re: [Zephyr-devel] HCI_UART

 

Charles, 

 

Thank you very much for the reply.  

 

Here is a paste-bin of the logs you requested.  Please let me know if there's any further information you would like me to provide.  

 

https://paste.ubuntu.com/p/NsgDx6fqB7/

 

Best regards, 

Cale Collins
Field Application Engineer
Gateworks Corporation

3026 S. Higuera, SLO, CA 93401
T: (805)781-2000 x37

www.gateworks.com

 

On Wed, Oct 3, 2018 at 8:56 AM, Cufi, Carles <Carles.Cufi@...> wrote:

Hi there,

 

Could you please attach a btmon log of the attach procedure?

 

On one shell run “sudo btmon”

On another shell then run: “sudo btattach -B /dev/ttyACM0 -S 1000000”

 

And then attach the log output from btmon in an email or paste service.

 

Also, have you tried “sudo btmgmt --index 0”? i.e. specifying the index when invoking btmgmt?

 

Carles

 

From: devel@... <devel@...> On Behalf Of Cale Collins
Sent: 03 October 2018 17:43
To: devel@...
Subject: [Zephyr-devel] HCI_UART

 

Hello,

 

I have built and installed HCI_UART to nRF52840 Nordic Development kit.  When I connect this device it appears with "lsusb", seemingly I can attach it using "btattach -B /dev/ttyACM0 -S 1000000", revealing hci0.  I have made the recommended adaptation to "/lib/systemd/system/bluetooth.service", appending -E to the "ExecStart=/usr/lib/bluetooth/bluetoothd -E" line.

 

When issuing commands with "btmgmt", "btmon" reports "Invalid Index (0x11)".  Normal HCI commands fail such as "hciconfig hci0 up".  

 

Using Bionic-Beaver Ubuntu, 4.15 kernel, Bluez 5.48, also tested with Xenial Ubuntu 4.15 kernel, Bluez 5.50.  Any suggestions would be greatly appreciated. 

 

Best regards, 

 

Cale Collins
Field Application Engineer
Gateworks Corporation

3026 S. Higuera, SLO, CA 93401
T: (805)781-2000 x37

www.gateworks.com

 

Hello Zephyr community !

We are two students of the Université catholique de Louvain from
Belgium and we work on our master thesis. The thesis is called
"Benchmarking of Real-Time Operating Systems for Internet of Things
Devices" and is about comparing the different implementations of
open-source RTOS's currently available on the market.

In broad outline, we are planning to analyze the scheduling,
switching context, memory management and/or any relevant metric
dependant of the operating system.

Another goal is to compare networking performances or implementations
of the various stacks available. We have currently no concrete
planning for this part.

This project will be open source (because we <3 the open source).

Here are some questions we have for you:
- "What would you like to see in this benchmarking project?";
- "What RTOS should we benchmark?";
- "What metric should we consider?".

We'd love to hear your recommandations or any help you can provide us
with.

Also if you are interested about how the project will evolve, we'll
be glad to update you on our progress.

If the project gain lot of interests, we will probably create a
communication channel like Slack or Gitter.

Sincerely,
Julien Gomez and Trong-Vu Tran

Hi Cale,

 

The controller doesn´t seem to be responding to the Reset command, as if perhaps the serial (UART) connection was not working.

Can you try building and flashing the “hello_world” sample and visualize the output using minicom or similar, to make sure the serial link is working?

 

Carles

 

From: Cale Collins <ccollins@...>
Date: Wednesday, 3 October 2018 at 20:48
To: "Cufi, Carles" <Carles.Cufi@...>
Cc: "devel@..." <devel@...>, Luiz Augusto von Dentz <luiz.dentz@...>
Subject: Re: [Zephyr-devel] HCI_UART

 

Charles, 

 

Thank you very much for the reply.  

 

Here is a paste-bin of the logs you requested.  Please let me know if there's any further information you would like me to provide.  

 

https://paste.ubuntu.com/p/NsgDx6fqB7/

 

Best regards, 

Cale Collins
Field Application Engineer
Gateworks Corporation

3026 S. Higuera, SLO, CA 93401
T: (805)781-2000 x37

www.gateworks.com

 

On Wed, Oct 3, 2018 at 8:56 AM, Cufi, Carles <Carles.Cufi@...> wrote:

Hi there,

 

Could you please attach a btmon log of the attach procedure?

 

On one shell run “sudo btmon”

On another shell then run: “sudo btattach -B /dev/ttyACM0 -S 1000000”

 

And then attach the log output from btmon in an email or paste service.

 

Also, have you tried “sudo btmgmt --index 0”? i.e. specifying the index when invoking btmgmt?

 

Carles

 

From: devel@... <devel@...> On Behalf Of Cale Collins
Sent: 03 October 2018 17:43
To: devel@...
Subject: [Zephyr-devel] HCI_UART

 

Hello,

 

I have built and installed HCI_UART to nRF52840 Nordic Development kit.  When I connect this device it appears with "lsusb", seemingly I can attach it using "btattach -B /dev/ttyACM0 -S 1000000", revealing hci0.  I have made the recommended adaptation to "/lib/systemd/system/bluetooth.service", appending -E to the "ExecStart=/usr/lib/bluetooth/bluetoothd -E" line.

 

When issuing commands with "btmgmt", "btmon" reports "Invalid Index (0x11)".  Normal HCI commands fail such as "hciconfig hci0 up".  

 

Using Bionic-Beaver Ubuntu, 4.15 kernel, Bluez 5.48, also tested with Xenial Ubuntu 4.15 kernel, Bluez 5.50.  Any suggestions would be greatly appreciated. 

 

Best regards, 

 

Cale Collins
Field Application Engineer
Gateworks Corporation

3026 S. Higuera, SLO, CA 93401
T: (805)781-2000 x37

www.gateworks.com

 

Hi, everybody:
I´m using four boards Nordic PCA10056 with nRF52840 for creating a simple mesh net. For provisioning I´m using the Nordic App  nRF mesh. I'm using the sample "onoff_level_lighting_vnd_app". Two of the boards are configured as relays, one is Generic On/Off Client and the last one is Generic On/Off  Server. Between the Client and the Server are the relays like this:

Client -> Relay1 -> Relay2 -> Server

When I´m close to the Client the App nRF mesh doesn't reach  the Server and when I'm close to the Server the doesn't reach  the Client. For provisioning all the net I have to move close to the Server and close to the Client. 
I would like to know if Zephyr allows to provisioning using  relays.

Thanks in advance.
Best regards

So we are trying to have the out of box config of a board to enable a default set of features for that board.

I see now what was done on the other Atmel SAM platforms. So defining the pins in socmap.h makes sense and than having the driver have a pin_list and call soc_gpio_list_configure() is what we should do for now.

There’s a fair amount of inconsistency between SoC & board ports in this area. It needs cleaning up, but for now we should keep with the pattern used for other SAM devices.

- k

On Oct 3, 2018, at 10:31 AM, Jiří Kubias <jiri.kubias@gmail.com> wrote:

Hi,
isn't better to put the pin config into the arch/.../soc_pinmap.h and then the user app is responsible for proper pin setup. As the same board can be used in various way (typically dev boards) and some MCU can map peripheral pin function to varios pins so the soc_pinmap.h should contain all configuration variables and user have to select the correct one for his board.

Best regards,
Jiri

st 3. 10. 2018 v 17:14 odesílatel Kumar Gala <kumar.gala@linaro.org> napsal:

On Oct 3, 2018, at 6:15 AM, Vincent - VLoTech <vincent@vlotech.nl> wrote:

Hi all,

I'm currently extending the support for the sam4s and same70, by adding the SPI driver for it.

To create / extend a board which actually uses the SPI bus, I noticed there several different approaches to handle the pinmux.
1) device tree spec at board level assigning peripheral pins.
2) pinmux.c file using pinmux interface
3) pinmux.c file useing pinmux device interface

What is the preferred way, or better said, what is the design pattern to apply for now and in the near future.

Looking forward to your insights.

Kind regards,

Vincent van der Locht

I’d avoid device tree for right now, it is were we want to be, but requires a bunch of other work we are making progress on.

So we should have a pinmux driver that sets pins, and than we have board level pin settings. You can look at boards/arm/frdm_k64f/pinmux.c and drivers/pinmux/pinmux_mcux.c for an example/pattern to use.

- k




--
===================================================
Ing. Jiri Kubias

e-mail: jiri.kubias@gmail.com
mobile: 775 593 956
===================================================