Date   

Re: What is the acceptable license for documentation files in Zephyr?

David Brown
 

On Fri, Nov 17, 2017 at 03:36:37PM +0000, Kinder, David B wrote:

Best though, would be to avoid inclusion of GPL content (docs or code) into the
Zephyr tree. The nice thing about content is you can write a short summary in
the Zephyr docs in your own words, and then include a link to the Linux
documents for more details, rather than directly including them. You could
also include short quotes and properly cite the source material with a link to
provide due credit to the authors.
Has anyone tried to figure out what the GPL even would mean for
documentation? Forming a derived work kind of makes sense, but what
about compiling and source code? Would including a chapter of GPL
documentation into a document under another license cause the rest of
the work to be a derived work?

There is a reason the FSF doesn't use the GPL for their documentation.

David


Re: Zephyr Based Bluetooth Mesh implementation on nRF52840-PDK boards

Kinder, David B <david.b.kinder@...>
 

Hmm... indeed something is amiss with generation of the mesh API documentation.
I'm heading out for Thanksgiving vacation, so for now, indeed the header files should be consulted. I'll submit a github issue and look into this more when I return, unless someone else wants to look into this before then.

-- david

-----Original Message-----
From: Johan Hedberg [mailto:johan.hedberg@intel.com]
Sent: Thursday, November 16, 2017 11:43 PM
To: Kinder, David B <david.b.kinder@intel.com>
Cc: Vikrant More <vikrant8051@gmail.com>; zephyr-
users@lists.zephyrproject.org; zephyr-devel@lists.zephyrproject.org
Subject: Re: [Zephyr-devel] Zephyr Based Bluetooth Mesh implementation
on nRF52840-PDK boards

Hi David,

On Fri, Nov 17, 2017, Kinder, David B wrote:
The documents from the master branch (including the doxygen API
material) are published nightly to
docs.zephyrproject.org<http://docs.zephyrproject.org>
Thanks, I suppose the right place should then be:

http://docs.zephyrproject.org/api/bluetooth.html#mesh-profile

However, that seems to be broken/incomplete at the moment, since it only
lists the doxygen group bt_mesh but doesn't provide any links to its
subgroups (there are many of them). If I tracked this down right the page
gets generated from doc/api/bluetooth.rst, so that likely needs fixing.
Meanwhile, it seems the best source for Mesh documentation right now is to
look at the header files directly.

Johan


Re: What is the acceptable license for documentation files in Zephyr?

Kinder, David B <david.b.kinder@...>
 

Hi Bobby,

 

There is a process documented here for how to get non Apache-2.0 material into the Zephyr tree. 

 

Best though, would be to avoid inclusion of GPL content (docs or code) into the Zephyr tree.  The nice thing about content is you can write a short summary in the Zephyr docs in your own words, and then include a link to the Linux documents for more details, rather than directly including them.  You could also include short quotes and properly cite the source material with a link to provide due credit to the authors.

 

-- david

 

 

From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of b0661
Sent: Friday, November 17, 2017 5:52 AM
To: zephyr-devel@...
Subject: [Zephyr-devel] What is the acceptable license for documentation files in Zephyr?

 

Hello,

I wan´t to partly re-use doumentation from Linux for Zephyr documentation (rst files not source files). Linux documentation is (presumably) GPLv2.

The documentation file header might become:

..
    Copyright (c) 2017 Linux
    Copyright (c) 2017 ...
    SPDX-License-Identifier: GPL-2.0

Is it possible to include such GPLv2 documentation in Zephyr?

Thanks

Bobby


Re: accelerometer/gyroscope applications

punit vara <punitvara@...>
 

Hi Tamra

I think Its not available at the moment. But you can use BMI160 which has both Accelerometer and gyroscope. You can get xyz from same sample app. 

Regards
PV

On Nov 17, 2017 10:10 AM, "Tamra Oyama" <tamrako@...> wrote:
Hello all,

I am trying to incorporate the accelerometer and gyroscope data into an application. I want to print the xyz values from the buffer of with other data outputs like rssi values in scan_adv so it would look like,

Device found: 1c:3d:94:52:70:b6 (random) (RSSI -79)
accel/gyroscope data

I can run each sample individually, but I cannot seem to mesh the two. Any ideas?

Thank you,
Tamrra

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


What is the acceptable license for documentation files in Zephyr?

Bobby
 

Hello,

I wan´t to partly re-use doumentation from Linux for Zephyr documentation (rst files not source files). Linux documentation is (presumably) GPLv2.

The documentation file header might become:

..
    Copyright (c) 2017 Linux
    Copyright (c) 2017 ...
    SPDX-License-Identifier: GPL-2.0

Is it possible to include such GPLv2 documentation in Zephyr?

Thanks
Bobby


Resources for ble mesh development

ashish.shukla@corvi.com <ashish.shukla@...>
 


Hi all, 

I find very less documentation for ble mesh developed under Zephyr project. Can you please suggest links and resources for detailed documentation of the mesh implementation. 
--
Warm regards,
Ashish Shukla
Jr. Embedded Engineer
Research & Development


Please consider the environment before printing this e-mail or its attachments.

Disclaimer: The information contained herein (including any accompanying documents) is confidential and is intended solely for the addressee(s). If you have erroneously received this message, please immediately delete it and notify the sender. Also, if you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or taking any action in reliance on the contents of this message or any accompanying document is strictly prohibited and is unlawful. The organization is not responsible for any damage caused by a virus or alteration of the e-mail by a third party or otherwise. The contents of this message may not necessarily represent the views or policies of Corvi


Re: NRF5x I2C driver and the sensor/th02 example

Arthur Mühlbeier <arthur.muehlbeier@...>
 

Hello Andrzej,

thank you for the informative reply. You are totally right. I am getting the answers. I was using printk wrong
printk("T:%.1f%cC\n",   sensor_value_to_double(val),  223);
I changed it to first create a string and then print the string.
char myTemperature[16];
sprintf(myTemperature, "T:%.1f%cC", sensor_value_to_double(val), 223 /* degree symbol */);
printk("%s\n", myTemperature);

Now it is working. Also I overlooked that I was sleeping with the Raspi for 500 ms after I triggered the measurement and with the Zephyr Node I tried to get the measurement instantly. That is why it was polled and the logic analyzer output was different.
Thank you very much. I was unable to see the wood for the trees.

Have a nice day and best regards,
Arthur

On 17.11.2017 11:52, Głąbek, Andrzej wrote:

Hi Arthur,

 

There is nothing wrong in the sequence you presented. Raspberry PI just does the communication a bit differently:

  • 1.055657625000000,I2C,Setup Write to ['128'] + ACK
  • 1.055747625000000,I2C,'3' + ACK
  • 1.055837625000000,I2C,'17' + ACK

It waits 500 ms here. And reads 3 registers - STATUS (0 -> the result is ready), DATAh, DATAl - in a row:

  • 1.558392000000000,I2C,Setup Write to ['128'] + ACK
  • 1.558482000000000,I2C,'0' + ACK
  • 1.558650875000000,I2C,Setup Read to ['129'] + ACK
  • 1.558740875000000,I2C,'0' + ACK
  • 1.558830875000000,I2C,$ + ACK
  • 1.558920875000000,I2C,'140' + NAK

Now the driver from Zephyr:

  • 1.631275625000000,I2C,Setup Write to ['128'] + ACK
  • 1.631315375000000,I2C,'3' + ACK
  • 1.631363125000000,I2C,'17' + ACK
  • 1.631439375000000,I2C,Setup Write to ['128'] + ACK
  • 1.631479125000000,I2C,'0' + ACK
  • 1.631538750000000,I2C,Setup Read to ['129'] + ACK
  • 1.631574625000000,I2C,'1' + NAK

There was no waiting so the /RDY bit in the STATUS register is 1 (result not ready). It is then polled a couple of times:

  • 1.631641000000000,I2C,Setup Write to ['128'] + ACK
  • 1.631680750000000,I2C,'0' + ACK
  • 1.631740375000000,I2C,Setup Read to ['129'] + ACK
  • 1.631776125000000,I2C,'1' + NAK
  • 1.631842500000000,I2C,Setup Write to ['128'] + ACK
  • 1.631882375000000,I2C,'0' + ACK
  • 1.631942000000000,I2C,Setup Read to ['129'] + ACK
  • 1.631977750000000,I2C,'1' + NAK
  • ...
  • 1.763528625000000,I2C,Setup Write to ['128'] + ACK
  • 1.763568375000000,I2C,'0' + ACK
  • 1.763628000000000,I2C,Setup Read to ['129'] + ACK
  • 1.763663750000000,I2C,'0' + NAK

And here the /RDY bit is finally 0, so the result can be read. But it is done here in two “read register” transactions, for DATAh and DATAl separately (and perhaps this could be improved).

  • 1.763730250000000,I2C,Setup Write to ['128'] + ACK
  • 1.763770000000000,I2C,'1' + ACK
  • 1.763829625000000,I2C,Setup Read to ['129'] + ACK
  • 1.763865375000000,I2C,M + NAK
  • 1.763931625000000,I2C,Setup Write to ['128'] + ACK
  • 1.763971250000000,I2C,'2' + ACK
  • 1.764030875000000,I2C,Setup Read to ['129'] + ACK
  • 1.764066625000000,I2C,'160' + NAK

 

Could you then describe what is actually not working for you?

 

Best regards,

Andrzej

 

 

From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Arthur Mühlbeier
Sent: Thursday, November 16, 2017 5:07 PM
To: zephyr-devel@...
Subject: [Zephyr-devel] NRF5x I2C driver and the sensor/th02 example

 

Hello,

I am trying to get running the example sensor/th02 with the nrf52_pca10040 or nrf51_pca10028. I disbaled the Grove LCD display in menuconfig. I configured the I2C drivers like
https://imgur.com/Q6bh1XJ
I set the priority to 8 and tried also other values. I tried also different pins. This is what I get from the logic analyzer with both boards and different pins.
Time [s], Analyzer Name, Decoded Protocol Result

  • 1.631275625000000,I2C,Setup Write to ['128'] + ACK
  • 1.631315375000000,I2C,'3' + ACK
  • 1.631363125000000,I2C,'17' + ACK
  • 1.631439375000000,I2C,Setup Write to ['128'] + ACK
  • 1.631479125000000,I2C,'0' + ACK
  • 1.631538750000000,I2C,Setup Read to ['129'] + ACK
  • 1.631574625000000,I2C,'1' + NAK
  • 1.631641000000000,I2C,Setup Write to ['128'] + ACK
  • 1.631680750000000,I2C,'0' + ACK
  • 1.631740375000000,I2C,Setup Read to ['129'] + ACK
  • 1.631776125000000,I2C,'1' + NAK
  • 1.631842500000000,I2C,Setup Write to ['128'] + ACK
  • 1.631882375000000,I2C,'0' + ACK
  • 1.631942000000000,I2C,Setup Read to ['129'] + ACK
  • 1.631977750000000,I2C,'1' + NAK
  • ...
  • 1.763528625000000,I2C,Setup Write to ['128'] + ACK
  • 1.763568375000000,I2C,'0' + ACK
  • 1.763628000000000,I2C,Setup Read to ['129'] + ACK
  • 1.763663750000000,I2C,'0' + NAK
  • 1.763730250000000,I2C,Setup Write to ['128'] + ACK
  • 1.763770000000000,I2C,'1' + ACK
  • 1.763829625000000,I2C,Setup Read to ['129'] + ACK
  • 1.763865375000000,I2C,M + NAK
  • 1.763931625000000,I2C,Setup Write to ['128'] + ACK
  • 1.763971250000000,I2C,'2' + ACK
  • 1.764030875000000,I2C,Setup Read to ['129'] + ACK
  • 1.764066625000000,I2C,'160' + NAK


So it seems that there is some working I2C functionality. But it seems to not working after the read command.
I tried the sensor with the Raspberry PI to find out what the expected output is and whether the sensor is working.
Raspi Log:

  • Time [s], Analyzer Name, Decoded Protocol Result
  • 1.055657625000000,I2C,Setup Write to ['128'] + ACK
  • 1.055747625000000,I2C,'3' + ACK
  • 1.055837625000000,I2C,'17' + ACK
  • 1.558392000000000,I2C,Setup Write to ['128'] + ACK
  • 1.558482000000000,I2C,'0' + ACK
  • 1.558650875000000,I2C,Setup Read to ['129'] + ACK
  • 1.558740875000000,I2C,'0' + ACK
  • 1.558830875000000,I2C,$ + ACK
  • 1.558920875000000,I2C,'140' + NAK

I have already asked for help in the IRC channel. I know that the "wrong" sequence is received after

if (offset == 0) {
      SYS_LOG_DBG("STARTRX");
      twi->TASKS_STARTRX = 1;
} in i2c_nrf5.c     function i2c_nrf5_read

Am I miconfiguring the I2C driver or is there a bug with the driver. Any help would be greatly appreciated. Thank you and have a nice day.

Arthur

 



Re: NRF5x I2C driver and the sensor/th02 example

Andrzej G??bek
 

Hi Arthur,

 

There is nothing wrong in the sequence you presented. Raspberry PI just does the communication a bit differently:

  • 1.055657625000000,I2C,Setup Write to ['128'] + ACK
  • 1.055747625000000,I2C,'3' + ACK
  • 1.055837625000000,I2C,'17' + ACK

It waits 500 ms here. And reads 3 registers - STATUS (0 -> the result is ready), DATAh, DATAl - in a row:

  • 1.558392000000000,I2C,Setup Write to ['128'] + ACK
  • 1.558482000000000,I2C,'0' + ACK
  • 1.558650875000000,I2C,Setup Read to ['129'] + ACK
  • 1.558740875000000,I2C,'0' + ACK
  • 1.558830875000000,I2C,$ + ACK
  • 1.558920875000000,I2C,'140' + NAK

Now the driver from Zephyr:

  • 1.631275625000000,I2C,Setup Write to ['128'] + ACK
  • 1.631315375000000,I2C,'3' + ACK
  • 1.631363125000000,I2C,'17' + ACK
  • 1.631439375000000,I2C,Setup Write to ['128'] + ACK
  • 1.631479125000000,I2C,'0' + ACK
  • 1.631538750000000,I2C,Setup Read to ['129'] + ACK
  • 1.631574625000000,I2C,'1' + NAK

There was no waiting so the /RDY bit in the STATUS register is 1 (result not ready). It is then polled a couple of times:

  • 1.631641000000000,I2C,Setup Write to ['128'] + ACK
  • 1.631680750000000,I2C,'0' + ACK
  • 1.631740375000000,I2C,Setup Read to ['129'] + ACK
  • 1.631776125000000,I2C,'1' + NAK
  • 1.631842500000000,I2C,Setup Write to ['128'] + ACK
  • 1.631882375000000,I2C,'0' + ACK
  • 1.631942000000000,I2C,Setup Read to ['129'] + ACK
  • 1.631977750000000,I2C,'1' + NAK
  • ...
  • 1.763528625000000,I2C,Setup Write to ['128'] + ACK
  • 1.763568375000000,I2C,'0' + ACK
  • 1.763628000000000,I2C,Setup Read to ['129'] + ACK
  • 1.763663750000000,I2C,'0' + NAK

And here the /RDY bit is finally 0, so the result can be read. But it is done here in two “read register” transactions, for DATAh and DATAl separately (and perhaps this could be improved).

  • 1.763730250000000,I2C,Setup Write to ['128'] + ACK
  • 1.763770000000000,I2C,'1' + ACK
  • 1.763829625000000,I2C,Setup Read to ['129'] + ACK
  • 1.763865375000000,I2C,M + NAK
  • 1.763931625000000,I2C,Setup Write to ['128'] + ACK
  • 1.763971250000000,I2C,'2' + ACK
  • 1.764030875000000,I2C,Setup Read to ['129'] + ACK
  • 1.764066625000000,I2C,'160' + NAK

 

Could you then describe what is actually not working for you?

 

Best regards,

Andrzej

 

 

From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Arthur Mühlbeier
Sent: Thursday, November 16, 2017 5:07 PM
To: zephyr-devel@...
Subject: [Zephyr-devel] NRF5x I2C driver and the sensor/th02 example

 

Hello,

I am trying to get running the example sensor/th02 with the nrf52_pca10040 or nrf51_pca10028. I disbaled the Grove LCD display in menuconfig. I configured the I2C drivers like
https://imgur.com/Q6bh1XJ
I set the priority to 8 and tried also other values. I tried also different pins. This is what I get from the logic analyzer with both boards and different pins.
Time [s], Analyzer Name, Decoded Protocol Result

  • 1.631275625000000,I2C,Setup Write to ['128'] + ACK
  • 1.631315375000000,I2C,'3' + ACK
  • 1.631363125000000,I2C,'17' + ACK
  • 1.631439375000000,I2C,Setup Write to ['128'] + ACK
  • 1.631479125000000,I2C,'0' + ACK
  • 1.631538750000000,I2C,Setup Read to ['129'] + ACK
  • 1.631574625000000,I2C,'1' + NAK
  • 1.631641000000000,I2C,Setup Write to ['128'] + ACK
  • 1.631680750000000,I2C,'0' + ACK
  • 1.631740375000000,I2C,Setup Read to ['129'] + ACK
  • 1.631776125000000,I2C,'1' + NAK
  • 1.631842500000000,I2C,Setup Write to ['128'] + ACK
  • 1.631882375000000,I2C,'0' + ACK
  • 1.631942000000000,I2C,Setup Read to ['129'] + ACK
  • 1.631977750000000,I2C,'1' + NAK
  • ...
  • 1.763528625000000,I2C,Setup Write to ['128'] + ACK
  • 1.763568375000000,I2C,'0' + ACK
  • 1.763628000000000,I2C,Setup Read to ['129'] + ACK
  • 1.763663750000000,I2C,'0' + NAK
  • 1.763730250000000,I2C,Setup Write to ['128'] + ACK
  • 1.763770000000000,I2C,'1' + ACK
  • 1.763829625000000,I2C,Setup Read to ['129'] + ACK
  • 1.763865375000000,I2C,M + NAK
  • 1.763931625000000,I2C,Setup Write to ['128'] + ACK
  • 1.763971250000000,I2C,'2' + ACK
  • 1.764030875000000,I2C,Setup Read to ['129'] + ACK
  • 1.764066625000000,I2C,'160' + NAK


So it seems that there is some working I2C functionality. But it seems to not working after the read command.
I tried the sensor with the Raspberry PI to find out what the expected output is and whether the sensor is working.
Raspi Log:

  • Time [s], Analyzer Name, Decoded Protocol Result
  • 1.055657625000000,I2C,Setup Write to ['128'] + ACK
  • 1.055747625000000,I2C,'3' + ACK
  • 1.055837625000000,I2C,'17' + ACK
  • 1.558392000000000,I2C,Setup Write to ['128'] + ACK
  • 1.558482000000000,I2C,'0' + ACK
  • 1.558650875000000,I2C,Setup Read to ['129'] + ACK
  • 1.558740875000000,I2C,'0' + ACK
  • 1.558830875000000,I2C,$ + ACK
  • 1.558920875000000,I2C,'140' + NAK

I have already asked for help in the IRC channel. I know that the "wrong" sequence is received after

if (offset == 0) {
      SYS_LOG_DBG("STARTRX");
      twi->TASKS_STARTRX = 1;
} in i2c_nrf5.c     function i2c_nrf5_read

Am I miconfiguring the I2C driver or is there a bug with the driver. Any help would be greatly appreciated. Thank you and have a nice day.

Arthur

 


Re: Zephyr Based Bluetooth Mesh implementation on nRF52840-PDK boards

Johan Hedberg
 

Hi David,

On Fri, Nov 17, 2017, Kinder, David B wrote:
The documents from the master branch (including the doxygen API
material) are published nightly to
docs.zephyrproject.org<http://docs.zephyrproject.org>
Thanks, I suppose the right place should then be:

http://docs.zephyrproject.org/api/bluetooth.html#mesh-profile

However, that seems to be broken/incomplete at the moment, since it only
lists the doxygen group bt_mesh but doesn't provide any links to its
subgroups (there are many of them). If I tracked this down right the
page gets generated from doc/api/bluetooth.rst, so that likely needs
fixing. Meanwhile, it seems the best source for Mesh documentation right
now is to look at the header files directly.

Johan


Re: Zephyr Based Bluetooth Mesh implementation on nRF52840-PDK boards

Kinder, David B <david.b.kinder@...>
 

The documents from the master branch (including the doxygen API material) are published nightly to docs.zephyrproject.org

-- david kinder

On Nov 16, 2017, at 10:42 PM, Johan Hedberg <johan.hedberg@...> wrote:

Hi Vikrant,

On Fri, Nov 17, 2017, Vikrant More wrote:
Could you please share in details documentation for Bluetooth Mesh
implementation for Zephyr ?

The API is documented with the usual doxygen syntax. I'm not sure how
frequently documentation in the master branch gets generated onto the
website, so it might be better for you to generate the documentation
either yourself, or perhaps simpler, look at the header files directly.
They can be found under include/bluetooth/mesh/ in the master branch.

Another good reference is how the mesh sample applications use the API,
so you could look e.g. at samples/bluetooth/src/main.c. Yet another
fairly good reference is the implementation of the foundation models,
which you can find in subsys/bluetooth/host/mesh/cfg_srv.c and
subsys/bluetooth/host/mesh/health_srv.c (note that these are only valid
for the latest master branch since the files were recently renamed).

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


Re: Zephyr Based Bluetooth Mesh implementation on nRF52840-PDK boards

Johan Hedberg
 

Hi Vikrant,

On Fri, Nov 17, 2017, Vikrant More wrote:
Could you please share in details documentation for Bluetooth Mesh
implementation for Zephyr ?
The API is documented with the usual doxygen syntax. I'm not sure how
frequently documentation in the master branch gets generated onto the
website, so it might be better for you to generate the documentation
either yourself, or perhaps simpler, look at the header files directly.
They can be found under include/bluetooth/mesh/ in the master branch.

Another good reference is how the mesh sample applications use the API,
so you could look e.g. at samples/bluetooth/src/main.c. Yet another
fairly good reference is the implementation of the foundation models,
which you can find in subsys/bluetooth/host/mesh/cfg_srv.c and
subsys/bluetooth/host/mesh/health_srv.c (note that these are only valid
for the latest master branch since the files were recently renamed).

Johan


Re: Zephyr Based Bluetooth Mesh implementation on nRF52840-PDK boards

Vikrant More <vikrant8051@...>
 

Could you please share in details documentation for Bluetooth Mesh implementation for Zephyr ?

On Fri, Nov 17, 2017 at 11:43 AM, Vikrant More <vikrant8051@...> wrote:
patch are giving me error. 

So please share original files.

what is original file for bluez-mesh.patch ?


On Fri, Nov 17, 2017 at 11:28 AM, Vikrant More <vikrant8051@...> wrote:
I simply add nrf52840.h & nrf_delay.h from nrf52_SDK into --> zephyr/boards/arm/nrf52840_pca10056.

And include these headder file in main.c ( Zephyr Mesh Example)

After that I add following line for testing of integration of newly added files with Zephyr project.



void main(void)
{
int err;
        
        NRF_P0->DIR |= 0x0001E000;
        NRF_P0->OUTSET |= 0x0001E000;
        
        while(1)
        {
           printk("Initializing...\n");

           NRF_P0->OUT ^= 0x0001E000;
        
          nrf_delay_ms(100);

        } 

/* Initialize the Bluetooth Subsystem */
err = bt_enable(bt_ready);
if (err) {
printk("Bluetooth init failed (err %d)\n", err);
}
}


After executing this on PDK board, I get result as expected .....All four LEDs are blinking continuously.



Next,

I removed above mentioned while loop & edit 

static void gen_onoff_get(struct bt_mesh_model *model,
  struct bt_mesh_msg_ctx *ctx,
  struct net_buf_simple *buf)
{
    NRF_P0->OUT |= 0x0001E000;
}

static void gen_onoff_set(struct bt_mesh_model *model,
  struct bt_mesh_msg_ctx *ctx,
  struct net_buf_simple *buf)
{
    NRF_P0->OUT &= 0xFFFE1FFF;
}


-------------------------------------------------------------------------------------

After giving onoff 1 / get on [on/off: Target=0111]# terminal I get following error -->

Failed to write


After trying same command again it does not reply anything. But LEDs status is also not changes on the Board.

On Thu, Nov 16, 2017 at 7:32 PM, Steve Brown <sbrown@...> wrote:
Here is the code I've been working with.

There is a patch to sample/bluetooth/mesh/main.c and another one to
bluez's mesh stuff.

The first one adds the led code. Some is commented out for working on
another board. I had all 4 leds working at 0100, 0101, 0102 & 0103. Per
the mesh specs, 0100 is the primary element and is the only one with a
config and health server. It also adds an onoff client for the button.
I only hooked up one button. If you want to experiment with group
addresses, you need to configure the button client (element 0100 &
model 1001) to publish to a group address, like c000 and set one or
more buttons to subscribe to c000. That way the button can control more
than one led. Also, the provisioning UUID is set to the MAC address of
the board instead of dddd00...000 so you don't have to power the boards
up one at a time.

You can't use meshctl to send onoff to group addresses. That isn't
implemented yet in the bluez mesh stack.

The bluez's patch adds some informational diagnostics, fixes a bug in
ascii oob input and adds heartbeat and subscribe commands.

I'm certain this is all very buggy, but it's been pretty educational
getting this far.

Steve


On Thu, 2017-11-16 at 19:04 +0530, Vikrant More wrote:
> [meshctl]# configure 0109
> [config: Target = 0109]# add-appkey 1
> [config: Target = 0109]# bind 0 1 1000
> [config: Target = 0109]# back
> [meshctl]# onoff 0109
> [on/off: Target = 0109] onoff 1     // nothing changed on PDK serial
> terminal nor changed LED status
> [on/off: Target = 0109] onoff 0     // nothing changed on PDK serial
> terminal nor changed LED status
>
> I last mail you mentioned that, to change LED status we have to write
> code which will execute after giving onoff 1/0 command.
> So could you please help me it that ?
>
> I know this code to Turn LED1 ON:
> NRF_P0 ->OUT &= ~(1<<13);
>
> & for off -->  NRF_P0 ->OUT |= (1<<13);
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Thu, Nov 16, 2017 at 6:42 PM, Steve Brown <sbrown@...>
> wrote:
> > Looks like you are making progress.
> >
> > I'd recommend that you do a "git checkout mesh/*.json" when you
> > start
> > each session. Otherwise, the node/element data accumulates and it's
> > hard to keep track of which node is which. This initializes the
> > first
> > element to 0100.
> >
> > Before you can use the onoff server, you have to issue the
> > following
> > configure commands:
> >
> > add-appkey 1   # that's the appkey that meshctl uses for the onoff
> > app
> > bind 0 1 1000  # this binds that appkey to the onoff server
> >
> > Now the onoff server should be able to accept meshctl onnoff
> > commands.
> >
> > Steve
> >
> > On Thu, 2017-11-16 at 18:26 +0530, Vikrant More wrote:
> > > Thanks !!
> > >
> > > After following your idea,
> > >
> > > On [nRF52840 termianl]-->  provisined ......
> > >                                              Failed to advertise
> > > using Node ID (err -5)
> > >
> > > & after this PDK board stop advertising itself as "Zephyr"
> > >
> > >
> > > If I hit command as "provision dddd0000000000000000000000000000"
> > > then it give as o/p as --> Already provisioned with unicast 0106
> > >
> > > So unicast address is 0106
> > >
> > > Then I run --> configure 0106
> > > [config: Target = 0077]# help
> > >
> > >  Client Configuration Menu
> > > Available commands:
> > >   target <unicast>                          Set target node to
> > > configure
> > >   get-composition [<page_num>]              Get Composition Data
> > >   add-netkey <net_idx>                      Add network key
> > >   del-netkey <net_idx>                      Delete network key
> > >   add-appkey <app_idx>                      Add application key
> > >   del-appkey <app_idx>                      Delete application
> > key
> > >   bind <ele_idx> <app_idx> <mod_id> [cid]   Bind app key to a
> > model
> > >   set-ttl <ttl>                             Set default TTL
> > >   get-ttl                                   Get default TTL
> > >   set-pub <ele_addr> <pub_addr> <app_idx> <period (step|res)>
> > <model>
> > > Set publication
> > >   back                                      Back to main menu
> > >   help                                      Config Commands
> > >
> > >
> > > If I run --> onff 0106       it gives
> > >
> > > [on/off: Target = 0106]# help
> > > Client Configuration Menu
> > > Available commands:
> > >   target <unicast>                          Set node to configure
> > >   get                                       Get ON/OFF status
> > >   onoff <0/1>                               Send "SET ON/OFF"
> > command
> > >   back                                      Back to main menu
> > >   help                                      Config Commands
> > > [on/off: Target = 0106]#
> > >
> > > If I run --> [on/off: Target = 0106]#  onoff 0          it gives
> > > Failed to write
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Then we test #
> > >
> > > On Thu, Nov 16, 2017 at 4:53 PM, Steve Brown <sbrown@...
> > >
> > > wrote:
> > > > In the 52840 terminal output, you will see something like:
> > > >
> > > > OOB Number: 6021
> > > >
> > > > That's the number to input to meshctl.
> > > >
> > > > Steve
> > > >
> > > > On Thu, 2017-11-16 at 16:11 +0530, Vikrant More wrote:
> > > > > On [meshctl] --> [mesh] Enter Numeric key:
> > > > > Here I input 1234
> > > > >
> > > > > On [nRF52840 termianl]--> Invalid Confirmation Value
> > > > >
> > > > >
> > > > >
> > > > > -----------------------------------------------------------
> > ----
> > > > ----
> > > > > ------------------------------------------
> > > > >
> > > > > On Thu, Nov 16, 2017 at 2:14 PM, Steve Brown <sbrown@cortland
> > .com
> > > > >
> > > > > wrote:
> > > > > > In looking at the output again, It doesn't look like
> > > > > > provisioningcompleted.
> > > > > >
> > > > > > The out-of-band code is output on the 52840's serial port
> > and
> > > > > > forwarded
> > > > > > to probably /dev/ttyACM0. That's the code you need to
> > enter.
> > > > > >
> > > > > > Steve
> > > > > >
> > > > > > On Thu, 2017-11-16 at 10:45 +0530, Vikrant More wrote:
> > > > > > > It is working now !!
> > > > > > > I run hcitool lescan on another terminal & { discover-
> > > > > > unprovisioned
> > > > > > > on , provision dddd0000000000000000000000000000 } on
> > messhctl
> > > > > > > terminal.
> > > > > > >
> > > > > > > Output -->
> > > > > > > -------------------------------------------------------
> > ----
> > > > ----
> > > > > > ----
> > > > > > > -------------------------------------------------------
> > ----
> > > > ----
> > > > > > ----
> > > > > > > -------------------------------------------------------
> > ----
> > > > ----
> > > > > > ----
> > > > > > > -----------------------------
> > > > > > >
> > > > > > > [meshctl]# discover-unprovisioned on
> > > > > > > set_scan_filter_uuids 00001827-0000-1000-8000-
> > 00805f9b34fb
> > > > > > > SetDiscoveryFilter success
> > > > > > > Discovery started
> > > > > > > Adapter property changed
> > > > > > > [CHG] Controller F0:03:8C:B7:5A:18 Discovering: yes
> > > > > > >               Mesh Provisioning Service (00001827-0000-
> > 1000-
> > > > 8000-
> > > > > > > 00805f9b34fb)
> > > > > > >                       Device UUID:
> > > > > > dddd0000000000000000000000000000
> > > > > > >                       OOB: 0000
> > > > > > > [NEW] Device EA:E8:05:9B:16:1D Zephyr
> > > > > > > [meshctl]# provision dddd0000000000000000000000000000
> > > > > > > Trying to connect Device EA:E8:05:9B:16:1D Zephyr
> > > > > > > Adapter property changed
> > > > > > > [CHG] Controller F0:03:8C:B7:5A:18 Discovering: no
> > > > > > > [Zephyr]# Connection successful
> > > > > > > [Zephyr]# Service added
> > > > > > > /org/bluez/hci0/dev_EA_E8_05_9B_16_1D/service0006
> > > > > > > Service added
> > > > /org/bluez/hci0/dev_EA_E8_05_9B_16_1D/service000a
> > > > > > > Char added
> > > > > > >
> > /org/bluez/hci0/dev_EA_E8_05_9B_16_1D/service000a/char000b:
> > > > > > > Char added
> > > > > > >
> > /org/bluez/hci0/dev_EA_E8_05_9B_16_1D/service000a/char000d:
> > > > > > > Services resolved yes
> > > > > > > Found matching char: path
> > > > > > >
> > /org/bluez/hci0/dev_EA_E8_05_9B_16_1D/service000a/char000b,
> > > > uuid
> > > > > > > 00002adb-0000-1000-8000-00805f9b34fb
> > > > > > > Found matching char: path
> > > > > > >
> > /org/bluez/hci0/dev_EA_E8_05_9B_16_1D/service000a/char000d,
> > > > uuid
> > > > > > > 00002adc-0000-1000-8000-00805f9b34fb
> > > > > > > Start notification on
> > > > > > >
> > /org/bluez/hci0/dev_EA_E8_05_9B_16_1D/service000a/char000d
> > > > > > > Characteristic property changed
> > > > > > >
> > /org/bluez/hci0/dev_EA_E8_05_9B_16_1D/service000a/char000d
> > > > > > > Notify started
> > > > > > > Notify for Mesh Provisioning Out Data started
> > > > > > > Open-Node: 0x1444640
> > > > > > > Open-Prov: 0x1446380
> > > > > > > Open-Prov: proxy 0x144a150
> > > > > > > GATT-TX:  03 00 10
> > > > > > > Attempting to write
> > > > > > >
> > /org/bluez/hci0/dev_EA_E8_05_9B_16_1D/service000a/char000b
> > > > > > > Initiated provisioning
> > > > > > > Characteristic property changed
> > > > > > >
> > /org/bluez/hci0/dev_EA_E8_05_9B_16_1D/service000a/char000d
> > > > > > > GATT-RX:       03 01 01 00 01 00 00 04 00 08 00 00 00
> > > > > > > Got provisioning data (12 bytes)
> > > > > > >        01 01 00 01 00 00 04 00 08 00 00 00
> > > > > > > GATT-TX:  03 02 00 00 02 03 04
> > > > > > > Attempting to write
> > > > > > >
> > /org/bluez/hci0/dev_EA_E8_05_9B_16_1D/service000a/char000b
> > > > > > > GATT-TX:  03 03 a8 09 93 50 18 6f 0d 3a cb af 39 40 28 60
> > > > > > > GATT-TX:  9b fa 15 c9
> > > > > > > Attempting to write
> > > > > > >
> > /org/bluez/hci0/dev_EA_E8_05_9B_16_1D/service000a/char000b
> > > > > > > Characteristic property changed
> > > > > > >
> > /org/bluez/hci0/dev_EA_E8_05_9B_16_1D/service000a/char000d
> > > > > > > GATT-RX:       03 03 3a bd 0b 6e 8a d8 dd a9 92 22 a9 3c
> > e4
> > > > c7
> > > > > > > GATT-RX:       fe c3 f1 08 d9 5b ef ff 56 49 87 aa 64 ca
> > 74
> > > > af
> > > > > > > GATT-RX:       ed 3d 89 b9 60 9c b8 19 a3 54 16 a4 dd 12
> > 8d
> > > > 3c
> > > > > > > GATT-RX:       f3 79 1c 18 15 2e 64 3a 4a e2 c1 34 19 c7
> > 39
> > > > ab
> > > > > > > GATT-RX:       9f e3
> > > > > > > Got provisioning data (65 bytes)
> > > > > > >        03 3a bd 0b 6e 8a d8 dd a9 92 22 a9 3c e4 c7 fe
> > > > > > >        c3 f1 08 d9 5b ef ff 56 49 87 aa 64 ca 74 af ed
> > > > > > >        3d 89 b9 60 9c b8 19 a3 54 16 a4 dd 12 8d 3c f3
> > > > > > >        79 1c 18 15 2e 64 3a 4a e2 c1 34 19 c7 39 ab 9f
> > > > > > >        e3
> > > > > > > Request decimal key (0 - 9999)
> > > > > > > [mesh] Enter Numeric key: 1234
> > > > > > > GATT-TX:  03 05 79 75 31 d9 3c ce a3 27 2c d7 1b 5d 90 f3
> > > > > > > GATT-TX:  30 27
> > > > > > > Attempting to write
> > > > > > >
> > /org/bluez/hci0/dev_EA_E8_05_9B_16_1D/service000a/char000b
> > > > > > > Characteristic property changed
> > > > > > >
> > /org/bluez/hci0/dev_EA_E8_05_9B_16_1D/service000a/char000d
> > > > > > > GATT-RX:       03 05 eb 68 f7 99 be 18 ef 71 6e 51 10 f6
> > f5
> > > > 05
> > > > > > > GATT-RX:       d2 40
> > > > > > > Got provisioning data (17 bytes)
> > > > > > >        05 eb 68 f7 99 be 18 ef 71 6e 51 10 f6 f5 05 d2
> > > > > > >        40
> > > > > > > GATT-TX:  03 06 af 78 37 46 88 64 92 8f f1 f4 9c c1 18 95
> > > > > > > GATT-TX:  a7 8d
> > > > > > > Attempting to write
> > > > > > >
> > /org/bluez/hci0/dev_EA_E8_05_9B_16_1D/service000a/char000b
> > > > > > > [Zephyr]#
> > > > > > >
> > > > > > > -------------------------------------------------------
> > ----
> > > > ----
> > > > > > ----
> > > > > > > -------------------------------------------------------
> > ----
> > > > ----
> > > > > > ----
> > > > > > > -------------------------------------------------------
> > ----
> > > > ----
> > > > > > ----
> > > > > > > -------------------------------------------------------
> > ----
> > > > ----
> > > > > > ----
> > > > > > > -------------------------------------------------------
> > ----
> > > > ----
> > > > > > ----
> > > > > > > ---
> > > > > > >
> > > > > > > Now what to do next ??
> > > > > > > I've repeat this procedure on all three board.
> > > > > > >
> > > > > > > How to control LEDs on these board using meshctl or any
> > > > android
> > > > > > APP
> > > > > > > ??
> > > > > > >
> > > > > > > Thank You!!
> > > > > > >
> > > > > > >
> > > > > > >
> > > > >
> > > > >
> > >
> > >
>
>




Re: Zephyr flash won't work without usb connection

Jie Zhou <zhoujie@...>
 

Hi guys,

So application can flash over DFU with an GND/VIN battery connected to the board. I found out what my issue with the application not rebooting was. During normal application run time, the steady state current is somewhat constant. However, when you try to reboot, (i.e. re-power and press master reset button to re run application) the board requires an sudden increase in current, I measured about 5 - 10 mA higher than steady state. If your power source is regulated, the board might not have sufficient power to reboot the application. I had a boost converter of 3.8V to 5V between my li-ion battery and my board. It was regulating my power delivered to the board so I was having trouble with rebooting my application. I fixed it by getting rid of the boost converter and directly powering my board with the 3.8V battery. Turned out, tinyTILE's VIN supports DC voltage of 3.8 - 15 V (awesome). Anyways, thanks for all the help, I really appreciated.

Sincerely,
Jie

 

On Tue, Nov 14, 2017 at 10:20 PM, Andrei Emeltchenko <andrei.emeltchenko.news@...> wrote:
Hi,

tinytile has only one USB connector. After connecting to PC first couple
of seconds it waits in DFU mode after that it loads Zephyr and in the
default configuration enables USB UART console, see:
boards/x86/tinytile/tinytile_defconfig. So only one USB connector is
enough and it should be fine to connect to USB power. Remember to reset
and flash quickly while it is in DFU mode.

Best regards
Andrei Emeltchenko

On Wed, Nov 15, 2017 at 01:52:45AM +0000, Rosen, Michael R wrote:
>    Jie,
>
>     
>
>    If you flashed your Zephyr application over USB, it should now be in the
>    device’s flash memory and should be loaded and run on every reboot. If you
>    are not seeing the application load when you run the device off external
>    power, that might be a very different issue. But you will not be able to
>    flash it once it has been disconnected.
>
>     
>
>    Mike
>
>     
>
>    From: Jie Zhou [mailto:zhoujie@...]
>    Sent: Tuesday, November 14, 2017 5:49 PM
>    To: Rosen, Michael R <michael.r.rosen@...>;
>    zephyr-devel@lists.zephyrproject.org
>    Subject: Re: [Zephyr-devel] Zephyr flash won't work without usb connection
>
>     
>
>    Hi Mike,
>
>    I'll investigate on the vin/gnd battery. I also have the flyswatter, but I
>    remember having trouble with flashing with it, so I sticked with the FTDI
>    but will check that out too. Eventually, I would want the board to run the
>    application on power up, so it would require no connection with my
>    computer at all. Zephyr, being a IoT OS, must have this capability. Let me
>    know if anyone else knows how to by pass the need of usb.
>
>    Thanks,
>
>    Jie 
>
>     
>
>    On Tue, Nov 14, 2017 at 1:27 PM, Rosen, Michael R
>    <[1]michael.r.rosen@...> wrote:
>
>      Jie,
>
>       
>
>      Curie boards generally flash in one of two ways: over JTAG or over USB.
>      In typical uses, they actually flash over the Curie USB interface (using
>      the USB DFU protocol; via dfu-util). That’s why you need USB connected
>      in order to flash the device. Not sure how easy it is to do JTAG
>      flashing on tinyTILE though, it requires a flyswatter2 or similar device
>      for Arduino 101.
>
>       
>
>      Not 100% sure of this, but you should be able to connect a battery to
>      the VIN/GND holes of the tinyTILE and leave the USB open for flashing.
>      If you intend to use a USB Battery, then you are somewhat stuck; though
>      there might be ways to do OTA updates using the BLE Radio SoC if you are
>      interested in investigating that…
>
>       
>
>      Also note that on boot, there might be a UART flashing mechanism on
>      boot, but I really haven’t done anything with it before and its really
>      an afterthought to the main USB or JTAG mechanisms. It uses the XModem
>      protocol and I think you will likely have to make a script specifically
>      for handling it. But if your needs really merit it, it might be worth
>      the effort. This feature may or may not be there on the default tinyTILE
>      bootloader.
>
>       
>
>      Code for the bootloader(s) that run on tinyTILE (or at least a close
>      version to the one on tinyTILE) can be found here:
>      [2]https://github.com/CurieBSP/bootloader
>
>       
>
>      Mike
>
>       
>
>       
>
>      From: [3]zephyr-devel-bounces@lists.zephyrproject.org
>      [mailto:[4]zephyr-devel-bounces@....org] On Behalf Of
>      Jie Zhou
>      Sent: Tuesday, November 14, 2017 3:09 PM
>      To: [5]zephyr-devel@lists.zephyrproject.org
>      Subject: [Zephyr-devel] Zephyr flash won't work without usb connection
>
>       
>
>      Hi all,
>
>      I'm flashing my tinyTILE using DFU over FTDI cable. My computer, that
>      has the zephyr applications, is connected to tinyTILE via a FTDI cable
>      as TX & RX and a usb cable as power to the tinyTILE. It flashes fine;
>      however, when I power the board externally so that my computer and
>      tinyTILE is only connected with the FTDI cable, the application will not
>      flash. I was always under the impression that the usb cable only
>      functions as a power source, but it seems to be more than that. Only
>      when the board is connected both by the FTDI and the USB cable will the
>      zephyr application flash to my board. This means I won't be able to
>      flash my zephyr application using battery power which defeats the
>      purpose an IoT OS. I've tried the same with the arduino 101 board and it
>      still does the same thing (wouldn't flash). I must be missing something.
>      Wondering if anyone knows what I'm doing wrong. 
>
>      Thanks,
>
>      Jie  
>
>     
>
> References
>
>    Visible links
>    1. mailto:michael.r.rosen@intel.com
>    2. https://github.com/CurieBSP/bootloader
>    3. mailto:zephyr-devel-bounces@lists.zephyrproject.org
>    4. mailto:zephyr-devel-bounces@lists.zephyrproject.org
>    5. mailto:zephyr-devel@lists.zephyrproject.org

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



accelerometer/gyroscope applications

Tamra Oyama <tamrako@...>
 

Hello all,

I am trying to incorporate the accelerometer and gyroscope data into an application. I want to print the xyz values from the buffer of with other data outputs like rssi values in scan_adv so it would look like,

Device found: 1c:3d:94:52:70:b6 (random) (RSSI -79)
accel/gyroscope data

I can run each sample individually, but I cannot seem to mesh the two. Any ideas?

Thank you,
Tamrra


Re: New Defects reported by Coverity Scan for Zephyr

Jammy Zhou
 

Hi Anas,

Is there some tool to do the scan locally?

Regards,
Jammy

On 26 October 2017 at 21:27, Nashif, Anas <anas.nashif@...> wrote:


Regards,
Anas Nashif 

Begin forwarded message:

From: <scan-admin@...>
Date: October 26, 2017 at 14:29:08 GMT+2
To: <anas.nashif@...>
Subject: New Defects reported by Coverity Scan for Zephyr


Hi,

Please find the latest report on new defect(s) introduced to Zephyr found with Coverity Scan.

17 new defect(s) introduced to Zephyr found with Coverity Scan.
6 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan.

New defect(s) Reported-by: Coverity Scan
Showing 17 of 17 defect(s)


** CID 178249:  Parse warnings  (PARSE_ERROR)
/samples/mpu/mem_domain_apis_test/src/main.c: 44 in ()


________________________________________________________________________________________________________
*** CID 178249:  Parse warnings  (PARSE_ERROR)
/samples/mpu/mem_domain_apis_test/src/main.c: 44 in ()
38         &app0_parts0,
39         &app0_parts1
40     };
41     
42     K_MEM_PARTITION_DEFINE(app1_parts0, app1_buf, sizeof(app1_buf),
43                    K_MEM_PARTITION_P_RW_U_RW);
   CID 178249:  Parse warnings  (PARSE_ERROR)
   expression must be an integral constant expression
44     K_MEM_PARTITION_DEFINE(app1_parts1, app0_buf, sizeof(app0_buf),
45                    K_MEM_PARTITION_P_RW_U_RO);
46     
47     struct k_mem_partition *app1_parts[] = {
48         &app1_parts0,
49         &app1_parts1

** CID 178248:  Null pointer dereferences  (REVERSE_INULL)
/subsys/net/lib/coap/coap.c: 1233 in coap_packet_get_payload()


________________________________________________________________________________________________________
*** CID 178248:  Null pointer dereferences  (REVERSE_INULL)
/subsys/net/lib/coap/coap.c: 1233 in coap_packet_get_payload()
1227         u16_t coap_pkt_len;
1228     
1229         frag = NULL;
1230         *offset = 0xffff;
1231         *len = 0;
1232     
   CID 178248:  Null pointer dereferences  (REVERSE_INULL)
   Null-checking "offset" suggests that it may be null, but it has already been dereferenced on all paths leading to the check.
1233         if (!cpkt || !cpkt->pkt || !offset || !len) {
1234             return NULL;
1235         }
1236     
1237         coap_pkt_len = get_coap_packet_len(cpkt->pkt);
1238     

** CID 178247:  Error handling issues  (CHECKED_RETURN)
/subsys/net/lib/sockets/sockets.c: 111 in zsock_accepted_cb()


________________________________________________________________________________________________________
*** CID 178247:  Error handling issues  (CHECKED_RETURN)
/subsys/net/lib/sockets/sockets.c: 111 in zsock_accepted_cb()
105     
106     static void zsock_accepted_cb(struct net_context *new_ctx,
107                       struct sockaddr *addr, socklen_t addrlen,
108                       int status, void *user_data) {
109         struct net_context *parent = user_data;
110     
   CID 178247:  Error handling issues  (CHECKED_RETURN)
   Calling "net_context_recv" without checking return value (as is done elsewhere 21 out of 26 times).
111         net_context_recv(new_ctx, zsock_received_cb, K_NO_WAIT, NULL);
112         k_fifo_init(&new_ctx->recv_q);
113     
114         NET_DBG("parent=%p, ctx=%p, st=%d", parent, new_ctx, status);
115     
116         k_fifo_put(&parent->accept_q, new_ctx);

** CID 178246:  Error handling issues  (CHECKED_RETURN)
/subsys/net/lib/app/client.c: 479 in _app_connected()


________________________________________________________________________________________________________
*** CID 178246:  Error handling issues  (CHECKED_RETURN)
/subsys/net/lib/app/client.c: 479 in _app_connected()
473     #if defined(CONFIG_NET_APP_TLS) || defined(CONFIG_NET_APP_DTLS)
474         if (ctx->is_tls) {
475             k_sem_give(&ctx->client.connect_wait);
476         }
477     #endif
478     
   CID 178246:  Error handling issues  (CHECKED_RETURN)
   Calling "net_context_recv" without checking return value (as is done elsewhere 21 out of 26 times).
479         net_context_recv(net_ctx, ctx->recv_cb, K_NO_WAIT, ctx);
480     
481     #if defined(CONFIG_NET_APP_TLS) || defined(CONFIG_NET_APP_DTLS)
482         if (ctx->is_tls) {
483             /* If we have TLS connection, the connect cb is called
484              * after TLS handshakes are done.

** CID 178245:  Parse warnings  (PARSE_ERROR)
/samples/mpu/mem_domain_apis_test/src/main.c: 42 in ()


________________________________________________________________________________________________________
*** CID 178245:  Parse warnings  (PARSE_ERROR)
/samples/mpu/mem_domain_apis_test/src/main.c: 42 in ()
36     
37     struct k_mem_partition *app0_parts[] = {
38         &app0_parts0,
39         &app0_parts1
40     };
41     
   CID 178245:  Parse warnings  (PARSE_ERROR)
   expression must be an integral constant expression
42     K_MEM_PARTITION_DEFINE(app1_parts0, app1_buf, sizeof(app1_buf),
43                    K_MEM_PARTITION_P_RW_U_RW);
44     K_MEM_PARTITION_DEFINE(app1_parts1, app0_buf, sizeof(app0_buf),
45                    K_MEM_PARTITION_P_RW_U_RO);
46     
47     struct k_mem_partition *app1_parts[] = {

** CID 178244:  Error handling issues  (CHECKED_RETURN)
/subsys/net/lib/http/http_server.c: 800 in accept_cb()


________________________________________________________________________________________________________
*** CID 178244:  Error handling issues  (CHECKED_RETURN)
/subsys/net/lib/http/http_server.c: 800 in accept_cb()
794         }
795     
796         http_ctx->req.net_ctx = net_ctx;
797     
798         new_client(http_ctx, net_ctx, addr);
799     
   CID 178244:  Error handling issues  (CHECKED_RETURN)
   Calling "net_context_recv" without checking return value (as is done elsewhere 21 out of 26 times).
800         net_context_recv(net_ctx, http_ctx->recv_cb, K_NO_WAIT, http_ctx);
801     }
802     
803     static int set_net_ctx(struct http_server_ctx *http_ctx,
804                    struct net_context *ctx,
805                    struct sockaddr *addr,

** CID 178243:  Error handling issues  (CHECKED_RETURN)
/drivers/ethernet/eth_enc28j60.c: 88 in eth_enc28j60_read_reg()


________________________________________________________________________________________________________
*** CID 178243:  Error handling issues  (CHECKED_RETURN)
/drivers/ethernet/eth_enc28j60.c: 88 in eth_enc28j60_read_reg()
82             tx_size = 3;
83         }
84     
85         tx_buf[0] = ENC28J60_SPI_RCR | (reg_addr & 0xFF);
86         tx_buf[1] = 0x0;
87     
   CID 178243:  Error handling issues  (CHECKED_RETURN)
   Calling "spi_transceive" without checking return value (as is done elsewhere 20 out of 25 times).
88         spi_transceive(context->spi, tx_buf, tx_size, tx_buf, tx_size);
89     
90         *value = tx_buf[tx_size - 1];
91     
92         k_sem_give(&context->spi_sem);
93     }

** CID 178242:  Parse warnings  (PARSE_ERROR)
/samples/mpu/mem_domain_apis_test/src/main.c: 34 in ()


________________________________________________________________________________________________________
*** CID 178242:  Parse warnings  (PARSE_ERROR)
/samples/mpu/mem_domain_apis_test/src/main.c: 34 in ()
28     /* the start address of the MPU region needs to align with its size */
29     u8_t __aligned(32) app0_buf[32];
30     u8_t __aligned(32) app1_buf[32];
31     
32     K_MEM_PARTITION_DEFINE(app0_parts0, app0_buf, sizeof(app0_buf),
33                    K_MEM_PARTITION_P_RW_U_RW);
   CID 178242:  Parse warnings  (PARSE_ERROR)
   expression must be an integral constant expression
34     K_MEM_PARTITION_DEFINE(app0_parts1, app1_buf, sizeof(app1_buf),
35                    K_MEM_PARTITION_P_RW_U_RO);
36     
37     struct k_mem_partition *app0_parts[] = {
38         &app0_parts0,
39         &app0_parts1

** CID 178241:    (CHECKED_RETURN)
/drivers/ethernet/eth_enc28j60.c: 174 in eth_enc28j60_read_mem()
/drivers/ethernet/eth_enc28j60.c: 185 in eth_enc28j60_read_mem()


________________________________________________________________________________________________________
*** CID 178241:    (CHECKED_RETURN)
/drivers/ethernet/eth_enc28j60.c: 174 in eth_enc28j60_read_mem()
168     
169         k_sem_take(&context->spi_sem, K_FOREVER);
170     
171         for (int i = 0; i < num_segments;
172              ++i, data_buffer += MAX_BUFFER_LENGTH) {
173             context->mem_buf[0] = ENC28J60_SPI_RBM;
   CID 178241:    (CHECKED_RETURN)
   Calling "spi_transceive" without checking return value (as is done elsewhere 20 out of 25 times).
174             spi_transceive(context->spi,
175                        context->mem_buf, MAX_BUFFER_LENGTH + 1,
176                        context->mem_buf, MAX_BUFFER_LENGTH + 1);
177             if (data_buffer) {
178                 memcpy(data_buffer, context->mem_buf + 1,
179                        MAX_BUFFER_LENGTH);
/drivers/ethernet/eth_enc28j60.c: 185 in eth_enc28j60_read_mem()
179                        MAX_BUFFER_LENGTH);
180             }
181         }
182     
183         if (num_remaining > 0) {
184             context->mem_buf[0] = ENC28J60_SPI_RBM;
   CID 178241:    (CHECKED_RETURN)
   Calling "spi_transceive" without checking return value (as is done elsewhere 20 out of 25 times).
185             spi_transceive(context->spi,
186                        context->mem_buf, num_remaining + 1,
187                        context->mem_buf, num_remaining + 1);
188             if (data_buffer) {
189                 memcpy(data_buffer, context->mem_buf + 1,
190                        num_remaining);

** CID 178240:  Error handling issues  (CHECKED_RETURN)
/drivers/ethernet/eth_enc28j60.c: 46 in eth_enc28j60_set_bank()


________________________________________________________________________________________________________
*** CID 178240:  Error handling issues  (CHECKED_RETURN)
/drivers/ethernet/eth_enc28j60.c: 46 in eth_enc28j60_set_bank()
40     
41         k_sem_take(&context->spi_sem, K_FOREVER);
42     
43         tx_buf[0] = ENC28J60_SPI_RCR | ENC28J60_REG_ECON1;
44         tx_buf[1] = 0x0;
45     
   CID 178240:  Error handling issues  (CHECKED_RETURN)
   Calling "spi_transceive" without checking return value (as is done elsewhere 20 out of 25 times).
46         spi_transceive(context->spi, tx_buf, 2, tx_buf, 2);
47     
48         tx_buf[0] = ENC28J60_SPI_WCR | ENC28J60_REG_ECON1;
49         tx_buf[1] = (tx_buf[1] & 0xFC) | ((reg_addr >> 8) & 0x0F);
50     
51         spi_write(context->spi, tx_buf, 2);

** CID 178239:    (FORWARD_NULL)
/tests/net/app/src/main.c: 192 in iface_setup()
/tests/net/app/src/main.c: 202 in iface_setup()


________________________________________________________________________________________________________
*** CID 178239:    (FORWARD_NULL)
/tests/net/app/src/main.c: 192 in iface_setup()
186             DBG("Cannot add IPv6 address %s\n",
187                    net_sprint_ipv6_addr(&my_addr1));
188             zassert_not_null(ifaddr, "addr1");
189         }
190     
191         /* For testing purposes we need to set the adddresses preferred */
   CID 178239:    (FORWARD_NULL)
   Dereferencing null pointer "ifaddr".
192         ifaddr->addr_state = NET_ADDR_PREFERRED;
193     
194         ifaddr = net_if_ipv6_addr_add(iface1, &ll_addr,
195                           NET_ADDR_MANUAL, 0);
196         if (!ifaddr) {
197             DBG("Cannot add IPv6 address %s\n",
/tests/net/app/src/main.c: 202 in iface_setup()
196         if (!ifaddr) {
197             DBG("Cannot add IPv6 address %s\n",
198                    net_sprint_ipv6_addr(&ll_addr));
199             zassert_not_null(ifaddr, "ll_addr");
200         }
201     
   CID 178239:    (FORWARD_NULL)
   Dereferencing null pointer "ifaddr".
202         ifaddr->addr_state = NET_ADDR_PREFERRED;
203     
204         net_ipv6_addr_create(&in6addr_mcast, 0xff02, 0, 0, 0, 0, 0, 0, 0x0001);
205     
206         maddr = net_if_ipv6_maddr_add(iface1, &in6addr_mcast);
207         if (!maddr) {

** CID 178238:  Parse warnings  (PARSE_ERROR)
/samples/mpu/mem_domain_apis_test/src/main.c: 32 in ()


________________________________________________________________________________________________________
*** CID 178238:  Parse warnings  (PARSE_ERROR)
/samples/mpu/mem_domain_apis_test/src/main.c: 32 in ()
26     struct k_mem_domain app_domain[2];
27     
28     /* the start address of the MPU region needs to align with its size */
29     u8_t __aligned(32) app0_buf[32];
30     u8_t __aligned(32) app1_buf[32];
31     
   CID 178238:  Parse warnings  (PARSE_ERROR)
   expression must be an integral constant expression
32     K_MEM_PARTITION_DEFINE(app0_parts0, app0_buf, sizeof(app0_buf),
33                    K_MEM_PARTITION_P_RW_U_RW);
34     K_MEM_PARTITION_DEFINE(app0_parts1, app1_buf, sizeof(app1_buf),
35                    K_MEM_PARTITION_P_RW_U_RO);
36     
37     struct k_mem_partition *app0_parts[] = {

** CID 178237:  Memory - corruptions  (OVERRUN)
/drivers/ieee802154/ieee802154_mcr20a.c: 218 in _mcr20a_write_burst()


________________________________________________________________________________________________________
*** CID 178237:  Memory - corruptions  (OVERRUN)
/drivers/ieee802154/ieee802154_mcr20a.c: 218 in _mcr20a_write_burst()
212             spi->cmd_buf[0] = MCR20A_REG_WRITE | addr;
213             memcpy(&spi->cmd_buf[1], data_buf, len);
214             len += 1;
215         } else {
216             spi->cmd_buf[0] = MCR20A_IAR_INDEX | MCR20A_REG_WRITE;
217             spi->cmd_buf[1] = addr | MCR20A_REG_WRITE;
   CID 178237:  Memory - corruptions  (OVERRUN)
   Overrunning buffer pointed to by "&spi->cmd_buf[2]" of 12 bytes by passing it to a function which accesses it at byte offset 12 using argument "len" (which evaluates to 11). [Note: The source code implementation of the function has been overridden by a builtin model.]
218             memcpy(&spi->cmd_buf[2], data_buf, len);
219             len += 2;
220         }
221     
222         spi_slave_select(spi->dev, spi->slave);
223         retval = (spi_write(spi->dev, spi->cmd_buf, len) == 0);

** CID 178236:  Memory - corruptions  (OVERRUN)
/drivers/ieee802154/ieee802154_mcr20a.c: 260 in _mcr20a_read_burst()


________________________________________________________________________________________________________
*** CID 178236:  Memory - corruptions  (OVERRUN)
/drivers/ieee802154/ieee802154_mcr20a.c: 260 in _mcr20a_read_burst()
254             return 0;
255         }
256     
257         if (dreg) {
258             memcpy(data_buf, &spi->cmd_buf[1], len - 1);
259         } else {
   CID 178236:  Memory - corruptions  (OVERRUN)
   Overrunning buffer pointed to by "&spi->cmd_buf[2]" of 12 bytes by passing it to a function which accesses it at byte offset 12 using argument "len - 2" (which evaluates to 11). [Note: The source code implementation of the function has been overridden by a builtin model.]
260             memcpy(data_buf, &spi->cmd_buf[2], len - 2);
261         }
262     
263         k_sem_give(&spi->spi_sem);
264     
265         return 1;

** CID 178235:  Null pointer dereferences  (REVERSE_INULL)
/subsys/net/lib/dns/mdns_responder.c: 241 in send_response()


________________________________________________________________________________________________________
*** CID 178235:  Null pointer dereferences  (REVERSE_INULL)
/subsys/net/lib/dns/mdns_responder.c: 241 in send_response()
235     
236         } else {
237             /* TODO: support also service PTRs */
238             return -EINVAL;
239         }
240     
   CID 178235:  Null pointer dereferences  (REVERSE_INULL)
   Null-checking "reply" suggests that it may be null, but it has already been dereferenced on all paths leading to the check.
241         if (!reply) {
242             return -ENOMEM;
243         }
244     
245         ret = net_context_sendto(reply, &dst, dst_len, NULL, K_NO_WAIT,
246                      NULL, NULL);

** CID 178234:  Null pointer dereferences  (REVERSE_INULL)
/subsys/net/lib/coap/coap.c: 1233 in coap_packet_get_payload()


________________________________________________________________________________________________________
*** CID 178234:  Null pointer dereferences  (REVERSE_INULL)
/subsys/net/lib/coap/coap.c: 1233 in coap_packet_get_payload()
1227         u16_t coap_pkt_len;
1228     
1229         frag = NULL;
1230         *offset = 0xffff;
1231         *len = 0;
1232     
   CID 178234:  Null pointer dereferences  (REVERSE_INULL)
   Null-checking "len" suggests that it may be null, but it has already been dereferenced on all paths leading to the check.
1233         if (!cpkt || !cpkt->pkt || !offset || !len) {
1234             return NULL;
1235         }
1236     
1237         coap_pkt_len = get_coap_packet_len(cpkt->pkt);
1238     

** CID 178233:  Null pointer dereferences  (REVERSE_INULL)
/samples/net/echo_client/src/tcp.c: 194 in compare_tcp_data()


________________________________________________________________________________________________________
*** CID 178233:  Null pointer dereferences  (REVERSE_INULL)
/samples/net/echo_client/src/tcp.c: 194 in compare_tcp_data()
188          * length is directly the fragment len.
189          */
190         len = frag->len - (ptr - frag->data);
191     
192         start = lorem_ipsum + received_len;
193     
   CID 178233:  Null pointer dereferences  (REVERSE_INULL)
   Null-checking "frag" suggests that it may be null, but it has already been dereferenced on all paths leading to the check.
194         while (frag) {
195             if (memcmp(ptr, start + pos, len)) {
196                 NET_DBG("Invalid data received");
197                 return false;
198             }
199     


________________________________________________________________________________________________________
To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V05UPxvVjWch-2Bd2MGckcRbO5jMuM3qcdgkQ-2B8GeSLDbY-2BGxhHXRVXXhN9J-2FGl-2FrBg-3D-3D_qb0Uj4AheYo18oR3ufs7U2EqDpE-2BCuzW5lXxy9dw9-2BCYGJAjGVBvdMSEIXid9MGVLnYaCxQWNCEO6x0llsKktGNllYqBFTSj2s3BUW8QUrdvl233u8LuFGWpOgSu2rc-2BvqdYiOVm0hPLHncFd4V-2F9JHMSM1BZTFpzNZeXoef3wWEMVzKSvGT6UGq3Ro61uQfOZk28XrY3pDBluqFe6LAeaHu5vYnVkhOARe-2BxPHSkKM-3D

To manage Coverity Scan email notifications for "anas.nashif@...", click https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V05UPxvVjWch-2Bd2MGckcRbVDbis712qZDP-2FA8y06Nq4QuJ4n4mXbeIpNhS8BGwxNLHj-2BTxeFwdI3SDDdsncH-2Bz9xw1m0wMt3vy-2F0hadYzJBea4I9eUVx23T6CU82-2BIxqn54S4Kugeb6uiTfRhIn290-3D_qb0Uj4AheYo18oR3ufs7U2EqDpE-2BCuzW5lXxy9dw9-2BCYGJAjGVBvdMSEIXid9MGVJ6piO1tzXPVgJVeRiqIumtvn4xp-2FsSSqAXdL4A3zXUPunFRRDa8MYZonXqSTke1mxlt6PHAxaGm6uFhYWiI7GnJ2TrKZIQU-2Bd3wMUQD-2FpCWVJwmYlOLvhtcJ2f-2BhdG03bLQdH57Of3UzdhGrU-2B4hZzPeOMladuanpRCD-2FHbkM-2Bs-3D


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



Bluetooth bonding

Timothy <tymoteusz.kielan@...>
 

Hello,

I'm trying to get CTS GATT profile working with my android phone over BLE.

I managed to connect from "nRF Connect" app where GATT server is serving CTS.

Here are my logs:

***** BOOTING ZEPHYR OS v1.9.99 - BUILD: Nov 16 2017 19:39:37 *****
shell> [bt] [DBG] bt_conn_prepare_events: (0x200012cc) 
[bt] [DBG] bt_conn_prepare_events: (0x200012cc) 
[bt] [DBG] bt_conn_prepare_events: (0x200012cc) 
[bt] [DBG] bt_conn_prepare_events: (0x200012cc) 
[bt] [DBG] bt_conn_prepare_events: (0x200012cc) 
[bt] [DBG] bt_conn_prepare_events: (0x200012cc) 
[bt] [DBG] bt_conn_prepare_events: (0x200012cc) 
[bt] [DBG] bt_conn_prepare_events: (0x200012cc) 
[bt] [DBG] bt_conn_prepare_events: (0x200012cc) 
[bt] [DBG] bt_conn_prepare_events: (0x200012cc) 
[bt] [DBG] bt_conn_prepare_events: (0x200012cc) 
[bt] [WRN] set_flow_control: Controller to host flow control not supported
[bt] [DBG] bt_conn_prepare_events: (0x200012cc) 
[bt] [DBG] bt_conn_prepare_events: (0x200012cc) 
[bt] [DBG] bt_conn_prepare_events: (0x200012cc) 
[bt] [DBG] bt_conn_prepare_events: (0x200012cc) 
[bt] [DBG] bt_conn_prepare_events: (0x200012cc) 
[bt] [WRN] set_static_addr: Using temporary static random address
[bt] [DBG] bt_conn_prepare_events: (0x200012cc) 
[bt] [INF] show_dev_info: Identity: cd:a5:23:43:2c:d0 (random)
[bt] [INF] show_dev_info: HCI: version 4.1 (0x07) revision 0x3107, manufacturer 0x0030
[bt] [INF] show_dev_info: LMP: version 4.1 (0x07) subver 0x0023
[bt] [DBG] gatt_register: (0x20002848) attr 0x20005d48 handle 0x0001 uuid 2800 perm 0x01
[bt] [DBG] gatt_register: (0x20002848) attr 0x20005d5c handle 0x0002 uuid 2803 perm 0x01
[bt] [DBG] gatt_register: (0x20002848) attr 0x20005d70 handle 0x0003 uuid 2a00 perm 0x01
[bt] [DBG] gatt_register: (0x20002848) attr 0x20005d84 handle 0x0004 uuid 2803 perm 0x01
[bt] [DBG] gatt_register: (0x20002848) attr 0x20005d98 handle 0x0005 uuid 2a01 perm 0x01
[bt] [DBG] gatt_register: (0x20002848) attr 0x20005db8 handle 0x0006 uuid 2800 perm 0x01
[bt] [DBG] gatt_register: (0x20002848) attr 0x20005dcc handle 0x0007 uuid 2803 perm 0x01
[bt] [DBG] gatt_register: (0x20002848) attr 0x20005de0 handle 0x0008 uuid 2a05 perm 0x00
[bt] [DBG] gatt_register: (0x20002848) attr 0x20005df4 handle 0x0009 uuid 2902 perm 0x03
[bt] [DBG] bt_smp_init: (0x20002848) LE SC disabled
[bt] [WRN] bt_pub_key_gen: ECC HCI commands not available
[bt] [WRN] irk_init: Using temporary IRK
Bluetooth initialized
[bt] [DBG] gatt_register: (0x20002848) attr 0x200056b0 handle 0x000a uuid 2800 perm 0x01
[bt] [DBG] gatt_register: (0x20002848) attr 0x200056c4 handle 0x000b uuid 2803 perm 0x01
[bt] [DBG] gatt_register: (0x20002848) attr 0x200056d8 handle 0x000c uuid 2a24 perm 0x01
[bt] [DBG] gatt_register: (0x20002848) attr 0x200056ec handle 0x000d uuid 2803 perm 0x01
[bt] [DBG] gatt_register: (0x20002848) attr 0x20005700 handle 0x000e uuid 2a29 perm 0x01
[bt] [DBG] gatt_register: (0x20002848) attr 0x20005750 handle 0x000f uuid 2800 perm 0x01
[bt] [DBG] gatt_register: (0x20002848) attr 0x20005764 handle 0x0010 uuid 2803 perm 0x01
[bt] [DBG] gatt_register: (0x20002848) attr 0x20005778 handle 0x0011 uuid 2a2b perm 0x03
[bt] [DBG] gatt_register: (0x20002848) attr 0x2000578c handle 0x0012 uuid 2902 perm 0x03
[bt] [DBG] update_range: (0x20002848) start 0x000a end 0x000e new_start 0x000f new_end 0x0012
[bt] [DBG] bt_conn_prepare_events: (0x200012cc) 
[bt] [DBG] bt_conn_prepare_events: (0x200012cc) 
[bt] [DBG] bt_conn_prepare_events: (0x200012cc) 
[bt] [DBG] bt_conn_prepare_events: (0x200012cc) 
[bt] [DBG] bt_conn_prepare_events: (0x200012cc) 
Advertising successfully started
[bt] [DBG] bt_keys_find_irk: (0x20001258) 5e:a3:62:88:e1:04 (random)
[bt] [DBG] bt_keys_find_irk: (0x20001258) No IRK for 5e:a3:62:88:e1:04 (random)
[bt] [DBG] bt_conn_set_state: (0x20001258) disconnected -> connected
[bt] [DBG] bt_conn_ref: (0x20001258) handle 2049 ref 2
[bt] [DBG] bt_att_accept: (0x20001258) conn 0x200014b4 handle 2049
[bt] [DBG] bt_att_connected: (0x20001258) chan 0x20001988 cid 0x0004
[bt] [DBG] bt_gatt_connected: (0x20001258) conn 0x200014b4
[bt] [DBG] bt_smp_accept: (0x20001258) conn 0x200014b4 handle 2049
[bt] [DBG] bt_smp_connected: (0x20001258) chan 0x20001e20 cid 0x0006
Connected 5e:a3:62:88:e1:04 (random)
[bt] [DBG] bt_smp_send_security_req: (0x20001258) 
[bt] [DBG] bt_conn_send_cb: (0x20001258) conn handle 2049 buf len 6 cb 0x00000000
[bt] [DBG] bt_conn_unref: (0x20001258) handle 2049 ref 1
[bt] [DBG] bt_conn_prepare_events: (0x200012cc) 
[bt] [DBG] bt_conn_prepare_events: (0x200012cc) Adding conn 0x200014b4 to poll list
[bt] [DBG] bt_conn_process_tx: (0x200012cc) conn 0x200014b4
[bt] [DBG] send_buf: (0x200012cc) conn 0x200014b4 buf 0x20004324 len 6
[bt] [DBG] send_frag: (0x200012cc) conn 0x200014b4 buf 0x20004324 len 6 flags 0x00
[bt] [DBG] bt_conn_notify_tx: (0x200012cc) conn 0x200014b4
[bt] [DBG] add_pending_tx: (0x200012cc) conn 0x200014b4 cb 0x00000000
[bt] [DBG] bt_conn_prepare_events: (0x200012cc) 
[bt] [DBG] bt_conn_prepare_events: (0x200012cc) Adding conn 0x200014b4 to poll list
[bt] [DBG] bt_conn_ref: (0x20001258) handle 2049 ref 2
[bt] [DBG] bt_conn_unref: (0x20001258) handle 2049 ref 1
[bt] [DBG] bt_conn_ref: (0x20001258) handle 2049 ref 2
[bt] [DBG] bt_conn_unref: (0x20001258) handle 2049 ref 1
[bt] [DBG] bt_conn_le_param_update: (0x20002848) conn 0x200014b4 features 0x00 params (24-40 0 2000)
[bt] [DBG] bt_conn_ref: (0x20001258) handle 2049 ref 2
Kernel stacks:
main      (real size 1024):     unused 784      usage 240 / 1024 (23 %)
idle      (real size 256):      unused 200      usage 56 / 256 (21 %)
interrupt (real size 2048):     unused 1884     usage 164 / 2048 (8 %)
workqueue (real size 1024):     unused 316      usage 708 / 1024 (69 %)
rx stack (real size 1324):      unused 656      usage 668 / 1324 (50 %)
tx stack (real size 716):       unused 264      usage 452 / 716 (63 %)
[bt] [DBG] bt_conn_set_state: (0x20001258) connected -> disconnected
[bt] [DBG] bt_att_disconnected: (0x20001258) chan 0x20001988 cid 0x0004
[bt] [DBG] bt_gatt_disconnected: (0x20001258) conn 0x200014b4
[bt] [DBG] bt_smp_disconnected: (0x20001258) chan 0x20001e20 cid 0x0006
Disconnected from 5e:a3:62:88:e1:04 (random) (reason 19)
[bt] [DBG] bt_conn_unref: (0x20001258) handle 0 ref 1
[bt] [DBG] bt_conn_prepare_events: (0x200012cc) 
[bt] [DBG] bt_conn_notify_tx: (0x200012cc) conn 0x200014b4
[bt] [DBG] bt_conn_unref: (0x200012cc) handle 0 ref 0

Why am I seeing threads stack dump and sudden disconnect?
Where should I seek for help/information.

Please help me getting back on track.

Tim

--
Tim Kielan
Registered Linux User #239184

vim [noun] - lively or energetic spirit; enthusiasm; vitality


Re: No thread to run before main

Timothy <tymoteusz.kielan@...>
 

Hi,
Found that it was caused by some MPU fault.
Changing CONFIG_APPLICATION_MEMORY from y to n solved this strange issue.

Tim

On 15 November 2017 at 22:31, Timothy <tymoteusz.kielan@...> wrote:
Hi,

I have recently encountered weird issue.
This probably happen after rebase to zephyr 1.9.99


Before entering main() kernel stopped stating to thread to run:

0x0800c9e6 in _get_ready_q_head () at ../zephyr/kernel/sched.c:51
51 __ASSERT(!sys_dlist_is_empty(list),
(gdb) bt
#0  0x0800c9e6 in _get_ready_q_head () at ../zephyr/kernel/sched.c:51
#1  0x0800ca8a in _remove_thread_from_ready_q (thread=0x20000080 <k_sys_work_q+16>) at ../zephyr/kernel/sched.c:111
#2  0x0800ccea in _pend_current_thread (wait_q=wait_q@entry=0x20001d24 <sys_work_q_stack+932>, timeout=timeout@entry=-1) at ../zephyr/kernel/sched.c:220
#3  0x0800e814 in k_poll (events=events@entry=0x20001d5c <sys_work_q_stack+988>, num_events=num_events@entry=1, timeout=timeout@entry=-1) at ../zephyr/kernel/poll.c:249
#4  0x0800c7e2 in k_queue_poll (queue=0x20000070 <k_sys_work_q>, timeout=-1) at ../zephyr/kernel/queue.c:209
#5  0x0800c93a in k_queue_get (queue=queue@entry=0x20000070 <k_sys_work_q>, timeout=timeout@entry=-1) at ../zephyr/kernel/queue.c:250
#6  0x0800dd5c in work_q_main (work_q_ptr=0x20000070 <k_sys_work_q>, p2=<optimized out>, p3=<optimized out>) at ../zephyr/kernel/work_q.c:29
#7  0x0800d864 in _thread_entry (entry=0x800dd45 <work_q_main>, p1=<optimized out>, p2=<optimized out>, p3=<optimized out>) at ../zephyr/kernel/thread.c:194
#8  0xaaaaaaaa in ?? ()


This happen while executing

_sys_device_do_config_level(_SYS_INIT_LEVEL_POST_KERNEL);

before

_sys_device_do_config_level(_SYS_INIT_LEVEL_APPLICATION);

so app was not supposed to be started yet.

app is not the first thread to run?

thanks, Tim

--
Tim Kielan
Registered Linux User #239184

vim [noun] - lively or energetic spirit; enthusiasm; vitality



--
Tim Kielan
Registered Linux User #239184

vim [noun] - lively or energetic spirit; enthusiasm; vitality


NRF5x I2C driver and the sensor/th02 example

Arthur Mühlbeier <arthur.muehlbeier@...>
 

Hello,

I am trying to get running the example sensor/th02 with the nrf52_pca10040 or nrf51_pca10028. I disbaled the Grove LCD display in menuconfig. I configured the I2C drivers like https://imgur.com/Q6bh1XJ
I set the priority to 8 and tried also other values. I tried also different pins. This is what I get from the logic analyzer with both boards and different pins.
Time [s], Analyzer Name, Decoded Protocol Result
  • 1.631275625000000,I2C,Setup Write to ['128'] + ACK
  • 1.631315375000000,I2C,'3' + ACK
  • 1.631363125000000,I2C,'17' + ACK
  • 1.631439375000000,I2C,Setup Write to ['128'] + ACK
  • 1.631479125000000,I2C,'0' + ACK
  • 1.631538750000000,I2C,Setup Read to ['129'] + ACK
  • 1.631574625000000,I2C,'1' + NAK
  • 1.631641000000000,I2C,Setup Write to ['128'] + ACK
  • 1.631680750000000,I2C,'0' + ACK
  • 1.631740375000000,I2C,Setup Read to ['129'] + ACK
  • 1.631776125000000,I2C,'1' + NAK
  • 1.631842500000000,I2C,Setup Write to ['128'] + ACK
  • 1.631882375000000,I2C,'0' + ACK
  • 1.631942000000000,I2C,Setup Read to ['129'] + ACK
  • 1.631977750000000,I2C,'1' + NAK
  • ...
  • 1.763528625000000,I2C,Setup Write to ['128'] + ACK
  • 1.763568375000000,I2C,'0' + ACK
  • 1.763628000000000,I2C,Setup Read to ['129'] + ACK
  • 1.763663750000000,I2C,'0' + NAK
  • 1.763730250000000,I2C,Setup Write to ['128'] + ACK
  • 1.763770000000000,I2C,'1' + ACK
  • 1.763829625000000,I2C,Setup Read to ['129'] + ACK
  • 1.763865375000000,I2C,M + NAK
  • 1.763931625000000,I2C,Setup Write to ['128'] + ACK
  • 1.763971250000000,I2C,'2' + ACK
  • 1.764030875000000,I2C,Setup Read to ['129'] + ACK
  • 1.764066625000000,I2C,'160' + NAK

So it seems that there is some working I2C functionality. But it seems to not working after the read command.
I tried the sensor with the Raspberry PI to find out what the expected output is and whether the sensor is working.
Raspi Log:
  • Time [s], Analyzer Name, Decoded Protocol Result
  • 1.055657625000000,I2C,Setup Write to ['128'] + ACK
  • 1.055747625000000,I2C,'3' + ACK
  • 1.055837625000000,I2C,'17' + ACK
  • 1.558392000000000,I2C,Setup Write to ['128'] + ACK
  • 1.558482000000000,I2C,'0' + ACK
  • 1.558650875000000,I2C,Setup Read to ['129'] + ACK
  • 1.558740875000000,I2C,'0' + ACK
  • 1.558830875000000,I2C,$ + ACK
  • 1.558920875000000,I2C,'140' + NAK

I have already asked for help in the IRC channel. I know that the "wrong" sequence is received after

if (offset == 0) {
      SYS_LOG_DBG("STARTRX");
      twi->TASKS_STARTRX = 1;
} in i2c_nrf5.c     function i2c_nrf5_read

Am I miconfiguring the I2C driver or is there a bug with the driver. Any help would be greatly appreciated. Thank you and have a nice day.

Arthur



Re: Zephyr Based Bluetooth Mesh implementation on nRF52840-PDK boards

Vikrant More <vikrant8051@...>
 

It is working now !!
I run hcitool lescan on another terminal & { discover-unprovisioned on , provision dddd0000000000000000000000000000 } on messhctl terminal.

Output -->
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

[meshctl]# discover-unprovisioned on
set_scan_filter_uuids 00001827-0000-1000-8000-00805f9b34fb
SetDiscoveryFilter success
Discovery started
Adapter property changed 
[CHG] Controller F0:03:8C:B7:5A:18 Discovering: yes
Mesh Provisioning Service (00001827-0000-1000-8000-00805f9b34fb)
Device UUID: dddd0000000000000000000000000000
OOB: 0000
[NEW] Device EA:E8:05:9B:16:1D Zephyr
[meshctl]# provision dddd0000000000000000000000000000
Trying to connect Device EA:E8:05:9B:16:1D Zephyr
Adapter property changed 
[CHG] Controller F0:03:8C:B7:5A:18 Discovering: no
[Zephyr]# Connection successful
[Zephyr]# Service added /org/bluez/hci0/dev_EA_E8_05_9B_16_1D/service0006
Service added /org/bluez/hci0/dev_EA_E8_05_9B_16_1D/service000a
Char added /org/bluez/hci0/dev_EA_E8_05_9B_16_1D/service000a/char000b:
Char added /org/bluez/hci0/dev_EA_E8_05_9B_16_1D/service000a/char000d:
Services resolved yes
Found matching char: path /org/bluez/hci0/dev_EA_E8_05_9B_16_1D/service000a/char000b, uuid 00002adb-0000-1000-8000-00805f9b34fb
Found matching char: path /org/bluez/hci0/dev_EA_E8_05_9B_16_1D/service000a/char000d, uuid 00002adc-0000-1000-8000-00805f9b34fb
Start notification on /org/bluez/hci0/dev_EA_E8_05_9B_16_1D/service000a/char000d
Characteristic property changed /org/bluez/hci0/dev_EA_E8_05_9B_16_1D/service000a/char000d
Notify started
Notify for Mesh Provisioning Out Data started
Open-Node: 0x1444640
Open-Prov: 0x1446380
Open-Prov: proxy 0x144a150
GATT-TX:  03 00 10 
Attempting to write /org/bluez/hci0/dev_EA_E8_05_9B_16_1D/service000a/char000b
Initiated provisioning
Characteristic property changed /org/bluez/hci0/dev_EA_E8_05_9B_16_1D/service000a/char000d
GATT-RX: 03 01 01 00 01 00 00 04 00 08 00 00 00 
Got provisioning data (12 bytes)
01 01 00 01 00 00 04 00 08 00 00 00 
GATT-TX:  03 02 00 00 02 03 04 
Attempting to write /org/bluez/hci0/dev_EA_E8_05_9B_16_1D/service000a/char000b
GATT-TX:  03 03 a8 09 93 50 18 6f 0d 3a cb af 39 40 28 60 
GATT-TX:  9b fa 15 c9 
Attempting to write /org/bluez/hci0/dev_EA_E8_05_9B_16_1D/service000a/char000b
Characteristic property changed /org/bluez/hci0/dev_EA_E8_05_9B_16_1D/service000a/char000d
GATT-RX: 03 03 3a bd 0b 6e 8a d8 dd a9 92 22 a9 3c e4 c7 
GATT-RX: fe c3 f1 08 d9 5b ef ff 56 49 87 aa 64 ca 74 af 
GATT-RX: ed 3d 89 b9 60 9c b8 19 a3 54 16 a4 dd 12 8d 3c 
GATT-RX: f3 79 1c 18 15 2e 64 3a 4a e2 c1 34 19 c7 39 ab 
GATT-RX: 9f e3 
Got provisioning data (65 bytes)
03 3a bd 0b 6e 8a d8 dd a9 92 22 a9 3c e4 c7 fe 
c3 f1 08 d9 5b ef ff 56 49 87 aa 64 ca 74 af ed 
3d 89 b9 60 9c b8 19 a3 54 16 a4 dd 12 8d 3c f3 
79 1c 18 15 2e 64 3a 4a e2 c1 34 19 c7 39 ab 9f 
e3 
Request decimal key (0 - 9999)
[mesh] Enter Numeric key: 1234
GATT-TX:  03 05 79 75 31 d9 3c ce a3 27 2c d7 1b 5d 90 f3 
GATT-TX:  30 27 
Attempting to write /org/bluez/hci0/dev_EA_E8_05_9B_16_1D/service000a/char000b
Characteristic property changed /org/bluez/hci0/dev_EA_E8_05_9B_16_1D/service000a/char000d
GATT-RX: 03 05 eb 68 f7 99 be 18 ef 71 6e 51 10 f6 f5 05 
GATT-RX: d2 40 
Got provisioning data (17 bytes)
05 eb 68 f7 99 be 18 ef 71 6e 51 10 f6 f5 05 d2 
40 
GATT-TX:  03 06 af 78 37 46 88 64 92 8f f1 f4 9c c1 18 95 
GATT-TX:  a7 8d 
Attempting to write /org/bluez/hci0/dev_EA_E8_05_9B_16_1D/service000a/char000b
[Zephyr]#

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Now what to do next ??
I've repeat this procedure on all three board.

How to control LEDs on these board using meshctl or any android APP ??

Thank You!!



On Thu, Nov 16, 2017 at 10:10 AM, Vikrant More <vikrant8051@...> wrote:
Now I'm able to run "discover-unprovisioned on" this command & o/p is

set_scan_filter_uuids 00001827-0000-1000-8000-00805f9b34fb
SetDiscoveryFilter success
Discovery started
Adapter property changed 
[CHG] Controller F0:03:8C:B7:5A:18 Discovering: ye


But "provision dddd0000000000000000000000000000" is still giving me this o/p-

Device with UUID dddd0000000000000000000000000000 not found.
Stale services? Remove device and re-discover

I'm able to discover & connect nRF52840-PDK board via nRF connect android app.


On Wed, Nov 15, 2017 at 10:01 PM, Steve Brown <sbrown@...> wrote:
More.

If I run the old bluetoothd, I get

[NEW] Controller B8:27:EB:06:2E:57 raspberrypi [default]
[meshctl]# discover-unprovisioned on
set_scan_filter_uuids 00001827-0000-1000-8000-00805f9b34fb
SetDiscoveryFilter failed: org.bluez.Error.InvalidArguments
Discovery started
Adapter property changed
[CHG] Controller B8:27:EB:06:2E:57 Discovering: yes

The same as you.

I'm pretty sure that's your problem.

Steve


On Wed, 2017-11-15 at 21:17 +0530, Vikrant More wrote:
>
> [meshctl]# discover-unprovisioned on
> set_scan_filter_uuids 00001827-0000-1000-8000-00805f9b34fb
> SetDiscoveryFilter failed: org.bluez.Error.InvalidArguments
> Discovery started
> Adapter property changed
> [CHG] Controller F0:03:8C:B7:5A:18 Discovering: yes
>
> I built BlueZ 5.47 as per your style but I am getting same error
> which is mentioned above.
>
> On Nov 15, 2017 5:47 PM, "Steve Brown" <sbrown@...> wrote:
> > I don't recognize that repository. The one I'm using is
> >
> > https://git.kernel.org/pub/scm/bluetooth/bluez.git
> >
> > The json files are in that repository.
> >
> > I run ./bootstrap-configure, then make and sudo make install.
> >
> > You might want to remove your distribution's bluez from your system
> > so
> > there's no confusion over version.
> >
> > Lastly, are you sure that the bluetooth hardware on your computer
> > does
> > ble? If in doubt, try
> > sudo btmgmt info
> >
> > Steve
> >
> > On Wed, 2017-11-15 at 17:12 +0530, Vikrant More wrote:
> > > could you please help how to build https://github.com/hadess/blue
> > z ??
> > >
> > > since here I am not getting configure file to execute -->
> > > ./configure --prefix=/usr  --sysconfdir=/etc  --
> > localstatedir=/var
> > > --enable-library  --disable-systemd  && make
> > >
> > > On Wed, Nov 15, 2017 at 4:52 PM, Steve Brown <sbrown@...
> > >
> > > wrote:
> > > > It looks like you have some kind of problem on the bluez end.
> > > >
> > > > I get the following on the same board.
> > > >
> > > > [meshctl]# discover-unprovisioned on
> > > > set_scan_filter_uuids 00001827-0000-1000-8000-00805f9b34fb
> > > > SetDiscoveryFilter success
> > > > Discovery started
> > > > Adapter property changed
> > > > [CHG] Controller B8:27:EB:06:2E:57 Discovering: yes
> > > >                 Mesh Provisioning Service (00001827-0000-1000-
> > 8000-
> > > > 00805f9b34fb)
> > > >                         Device UUID:
> > > > dddd0000000000000000000000000000
> > > >                         OOB: 0000
> > > >
> > > >
> > > > Are you sure you have a 5.47 bluetoothd running?
> > > >
> > > > Steve
> > > >
> > > >
> > > > On Wed, 2017-11-15 at 16:29 +0530, Vikrant More wrote:
> > > > > Thank very much !!
> > > > >
> > > > > I used your suggested commands. And I got following response
> > -
> > > > >
> > > > > [meshctl]# discover-unprovisioned on
> > > > > set_scan_filter_uuids 00001827-0000-1000-8000-00805f9b34fb
> > > > > SetDiscoveryFilter failed: org.bluez.Error.InvalidArguments
> > > > > Discovery started
> > > > > Adapter property changed
> > > > > [CHG] Controller F0:03:8C:B7:5A:18 Discovering: yes
> > > > >
> > > > >
> > > > >
> > > > > meshctl]# provision dddd0000000000000000000000000000
> > > > > Device with UUID dddd0000000000000000000000000000 not found.
> > > > > Stale services? Remove device and re-discover
> > > > >
> > > > >
> > > > > On Wed, Nov 15, 2017 at 2:32 PM, Steve Brown <sbrown@cortland
> > .com
> > > > >
> > > > > wrote:
> > > > > > Hi Vikrant,
> > > > > >
> > > > > > On Wed, 2017-11-15 at 13:58 +0530, Vikrant More wrote:
> > > > > > > Hello,
> > > > > > > I to want build Zephyr based lighting system & for
> > testing I
> > > > have
> > > > > > 3
> > > > > > > nRF52840-PDK boards.
> > > > > > >
> > > > > > > I've flashed  zephyr/samples/bluetooth/mesh firmware on
> > all
> > > > three
> > > > > > > board.
> > > > > > > They are advertising themselves as any other GATT
> > peripheral
> > > > > > devices.
> > > > > > >
> > > > > > > As per my understanding they are in unprovisioned state.
> > > > > > >
> > > > > > > Using "NRF connect" Android app I can send data to
> > service
> > > > (Mesh
> > > > > > > Provisioning Service) running on it.
> > > > > > >
> > > > > > > I think this service is for provisioning purpose. Am I
> > right
> > > > ?
> > > > > > >
> > > > > > > How to do provisioning using meshctl utility (BlueZ 5.47)
> > ?
> > > > > > >
> > > > > > > When I execute meshctl on my ubuntu laptop it gives me
> > > > following
> > > > > > > error -
> > > > > > >
> > > > > > >        Local config directory not provided.
> > > > > > >    Failed to parse local node configuration file
> > > > local_node.json
> > > > > > >
> > > > > > >
> > > > > > I assume you built the bluez 5.47 from source.
> > > > > >
> > > > > > The json files live in bluez/mesh. You either have to run
> > > > meshctl
> > > > > > in
> > > > > > that directory or point to it with the "-c" option.
> > > > > >
> > > > > > Once in meshctl, the commands:
> > > > > > discover-unprovisioned on
> > > > > > provision <Device UUID>
> > > > > >
> > > > > > should get you going.
> > > > > >
> > > > > > In the mesh sample the UUID is hardwired to
> > > > > > "dddd0000000000000000000000000000"
> > > > > >
> > > > > > Steve
> > > > > >
> > > > >
> > > > >
> > >
> > >



No thread to run before main

Timothy <tymoteusz.kielan@...>
 

Hi,

I have recently encountered weird issue.
This probably happen after rebase to zephyr 1.9.99


Before entering main() kernel stopped stating to thread to run:

0x0800c9e6 in _get_ready_q_head () at ../zephyr/kernel/sched.c:51
51 __ASSERT(!sys_dlist_is_empty(list),
(gdb) bt
#0  0x0800c9e6 in _get_ready_q_head () at ../zephyr/kernel/sched.c:51
#1  0x0800ca8a in _remove_thread_from_ready_q (thread=0x20000080 <k_sys_work_q+16>) at ../zephyr/kernel/sched.c:111
#2  0x0800ccea in _pend_current_thread (wait_q=wait_q@entry=0x20001d24 <sys_work_q_stack+932>, timeout=timeout@entry=-1) at ../zephyr/kernel/sched.c:220
#3  0x0800e814 in k_poll (events=events@entry=0x20001d5c <sys_work_q_stack+988>, num_events=num_events@entry=1, timeout=timeout@entry=-1) at ../zephyr/kernel/poll.c:249
#4  0x0800c7e2 in k_queue_poll (queue=0x20000070 <k_sys_work_q>, timeout=-1) at ../zephyr/kernel/queue.c:209
#5  0x0800c93a in k_queue_get (queue=queue@entry=0x20000070 <k_sys_work_q>, timeout=timeout@entry=-1) at ../zephyr/kernel/queue.c:250
#6  0x0800dd5c in work_q_main (work_q_ptr=0x20000070 <k_sys_work_q>, p2=<optimized out>, p3=<optimized out>) at ../zephyr/kernel/work_q.c:29
#7  0x0800d864 in _thread_entry (entry=0x800dd45 <work_q_main>, p1=<optimized out>, p2=<optimized out>, p3=<optimized out>) at ../zephyr/kernel/thread.c:194
#8  0xaaaaaaaa in ?? ()


This happen while executing

_sys_device_do_config_level(_SYS_INIT_LEVEL_POST_KERNEL);

before

_sys_device_do_config_level(_SYS_INIT_LEVEL_APPLICATION);

so app was not supposed to be started yet.

app is not the first thread to run?

thanks, Tim

--
Tim Kielan
Registered Linux User #239184

vim [noun] - lively or energetic spirit; enthusiasm; vitality

4541 - 4560 of 8204