Date   

Re: I2C and adc support for nRF5

Steve Brown
 

Hi Ashish,


On Tue, 2017-12-12 at 10:09 +0530, ashish.shukla@corvi.com wrote:
Hi Felipe,

Code builds successfully after making a minor change in main.c file

#define I2C_DEV CONFIG_GPIO_NRF5_P0_DEV_NAME

however, I'm working with nrf52840_pca10056 IC, running the command

$ cmake -DBOARD=nrf52_pca10056 ..

results in an error, I'm attaching snapshot in the attachment.

What needs to be done to remove this error ?




--
Warm regards,
Ashish Shukla
Jr. Embedded Engineer
Research & Development
www.corvi.com
The board name is nrf52840_pca10056

That works on my boards.

Steve


Re: I2C and adc support for nRF5

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

Hi Felipe,

Code builds successfully after making a minor change in main.c file

#define I2C_DEV CONFIG_GPIO_NRF5_P0_DEV_NAME

however, I'm working with nrf52840_pca10056 IC, running the command

$ cmake -DBOARD=nrf52_pca10056 ..

results in an error, I'm attaching snapshot in the attachment.

What needs to be done to remove this error ?




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


On Mon, Dec 11, 2017 at 5:38 PM, Felipe Neves <ryukokki.felipe@...> wrote:
Hello ashish!

The current version of Zephyr support I2C driver for nRF5, you also can find some examples in samples/ directory, the samples/drivers/i2c_fujistsu_fram  is a simple example which use both I2C write and
read functions.

To test it just setup zephyr environment then cd to this sample directory, then:

$ mkdir build
$ cd build
$ cmake -DBOARD=nrf52_pca10040 ..
$ make

You'll find the built image on build/zephyr directory.

Also you can use this sample as reference to develop your own project based on I2C bus.


About the ADC, the nrf5 currently does not support driver to it, but you can of course use it by:

- providing a driver using the zephyr infrastructure;
- use ADC controller as part of your application.

Please let me know if this information was useful to you.

Best

Felipe


2017-12-11 2:43 GMT-02:00 ashish.shukla@... <ashish.shukla@...>:
Hello everyone !!!

There is I2C support for nRF5 micro controllers, is there any sample code available to interface an I2C device with nRF5.

Also, is there adc support for nRF5 series controllers?    

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


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




--
Felipe S. Neves 
Embedded software & systems engineer
Skype: fneves1989
+55 11 96610 – 0855 


Re: Stack check failure with qemu_x86

Andy Gross
 

On 8 December 2017 at 00:08, Vakul Garg <vakul.garg@nxp.com> wrote:
Thanks.
I could resolve this issue on qemu_x86 by increasing MAIN_STACK_SIZE in the configuration.

I am not sure whether increasing stack size is required for my hardware board as well or is it only qemu_x86 which exhausted the stack and detected stack overflow.

I am debugging some issue on ARM based board (frdm-k64f) where I suspected corruption.
Does the stack check feature works on arm as well the same way as it worked over qemu_x86?
For the hardware board, zephyr/.config shows HW_STACK_PROTECTION=n.
The k64f does support stack protection. You just need to configure it
for use by setting HW_STACK_PROTECTION in your prj.conf. The QEMU ARM
target does not support MPU stack protection. Changes in both the
Zephyr ARM code and the qemu code are required (feature support and
bug fixes).


Re: Stack check failure with qemu_x86

Vakul Garg <vakul.garg@...>
 

The stack check failure shows up with only stack sentinel enabled on qemu_x86 in my case.


- Vakul


From: Boie, Andrew P <andrew.p.boie@...>
Sent: Monday, December 11, 2017 10:37:38 PM
To: Vakul Garg; zephyr-users@...
Subject: RE: Stack check failure with qemu_x86
 

There's no need to enable the stack sentinel on this target.

qemu_x86, by default, has MMU-assisted stack overflow protection enabled.

Unless you can reproduce this only when the sentinel is enabled? In which case this is a very interesting situation, please let me know.

 

In GDB you can set a breakpoint on _SysFatalErrorHandler() to debug when issues happen, all fatal exceptions go through there.

 

Andrew

 

From: zephyr-users-bounces@... [mailto:zephyr-users-bounces@...] On Behalf Of Vakul Garg
Sent: Wednesday, December 6, 2017 11:39 PM
To: zephyr-users@...
Subject: [Zephyr-users] Stack check failure with qemu_x86

 

Hi

 

I am running IPSP sample app using qemu_86 (on master branch).

I have enabled following to detect stack corruption.

 

+CONFIG_DEBUG=y

+CONFIG_STACK_USAGE=y

+CONFIG_STACK_SENTINEL=y

 

This results in stack check error.

I tried attaching gdb, but the qemu itself terminates resulting on closure of debug connection

 

Can someone give me pointers how to debug the same?

 

***** Stack Check Fail! *****

Current thread ID = 0x004035a0

Faulting segment:address = 0x0008:0x00003f6f

eax: 0x5be0cd19, ebx: 0xa54ff53a, ecx: 0x6a09e667, edx: 0x3c6ef372

esi: 0x1f83d9ab, edi: 0x510e527f, ebp: 0x9b05688c, esp: 0x0041dff8

eflags: 0x202

Terminate emulator due to fatal kernel error

 

 

Regards

 

Vakul

 


Re: Stack check failure with qemu_x86

Boie, Andrew P
 

There's no need to enable the stack sentinel on this target.

qemu_x86, by default, has MMU-assisted stack overflow protection enabled.

Unless you can reproduce this only when the sentinel is enabled? In which case this is a very interesting situation, please let me know.

 

In GDB you can set a breakpoint on _SysFatalErrorHandler() to debug when issues happen, all fatal exceptions go through there.

 

Andrew

 

From: zephyr-users-bounces@... [mailto:zephyr-users-bounces@...] On Behalf Of Vakul Garg
Sent: Wednesday, December 6, 2017 11:39 PM
To: zephyr-users@...
Subject: [Zephyr-users] Stack check failure with qemu_x86

 

Hi

 

I am running IPSP sample app using qemu_86 (on master branch).

I have enabled following to detect stack corruption.

 

+CONFIG_DEBUG=y

+CONFIG_STACK_USAGE=y

+CONFIG_STACK_SENTINEL=y

 

This results in stack check error.

I tried attaching gdb, but the qemu itself terminates resulting on closure of debug connection

 

Can someone give me pointers how to debug the same?

 

***** Stack Check Fail! *****

Current thread ID = 0x004035a0

Faulting segment:address = 0x0008:0x00003f6f

eax: 0x5be0cd19, ebx: 0xa54ff53a, ecx: 0x6a09e667, edx: 0x3c6ef372

esi: 0x1f83d9ab, edi: 0x510e527f, ebp: 0x9b05688c, esp: 0x0041dff8

eflags: 0x202

Terminate emulator due to fatal kernel error

 

 

Regards

 

Vakul

 


Re: I2C and adc support for nRF5

Felipe Neves
 

Hello ashish!

The current version of Zephyr support I2C driver for nRF5, you also can find some examples in samples/ directory, the samples/drivers/i2c_fujistsu_fram  is a simple example which use both I2C write and
read functions.

To test it just setup zephyr environment then cd to this sample directory, then:

$ mkdir build
$ cd build
$ cmake -DBOARD=nrf52_pca10040 ..
$ make

You'll find the built image on build/zephyr directory.

Also you can use this sample as reference to develop your own project based on I2C bus.


About the ADC, the nrf5 currently does not support driver to it, but you can of course use it by:

- providing a driver using the zephyr infrastructure;
- use ADC controller as part of your application.

Please let me know if this information was useful to you.

Best

Felipe


2017-12-11 2:43 GMT-02:00 ashish.shukla@... <ashish.shukla@...>:

Hello everyone !!!

There is I2C support for nRF5 micro controllers, is there any sample code available to interface an I2C device with nRF5.

Also, is there adc support for nRF5 series controllers?    

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


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




--
Felipe S. Neves 
Embedded software & systems engineer
Skype: fneves1989
+55 11 96610 – 0855 


BLE connection parameter settings question

Vakul Garg <vakul.garg@...>
 

Hi

 

I am looking for guidance about how to set following kernel config options.

 

CONFIG_BT_L2CAP_RX_MTU, CONFIG_BT_L2CAP_TX_MTU.

 

In build/zephyr/.config, both of these are set to 65 bytes.

 

 

From the function l2cap_chan_rx_init(), I understand that the receive mps size of the channel is capped to minimum of rx.mtu or L2CAP_MAX_LE_MPS.

L2CAP_MAX_LE_MPS is defined as equal to CONFIG_BT_L2CAP_RX_MTU.

 

But for the transmit direction, in function le_conn_req(), the tx.mps is directly set to the value as received from the peer linux (i.e. 230).

For tx.mps, why the code does not pick the minimum of CONFIG_BT_L2CAP_TX_MTU and mps value (as received from linux)?

 

I am running 6loble between zephyr and linux and facing issues while transferring bigger sized pkts across connection.

The default sized ping is successful, but specifying a size such as 1000 bytes shows up SDU length errors at linux (which I suspect are due to corruptions).

I checked that linux sends its mps value as 230 bytes. The zephyr code sets up chan->tx.mps as 230 bytes.

In this situation for 1000 bytes packets, zephyr sends l2cap packets of more than 65 bytes. SDUs seemingly get corrupt as seen as linux end.

 

Then I tried forcefully setting value of tx.mps to L2CAP_MAX_LE_MPS at zephyr. I overwrite mps value (230) received from linux.

And now ping of bigger packets started working well with no SDU errors seen.

 

I want to understand, whether zephyr l2cap stack should use mps value as-is as received from linux for segmenting l2cap frames.

Or do we need some modification in zephyr code to cap value of mps?

 

Regards

 

Vakul

 

 

 


I2C and adc support for nRF5

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

Hello everyone !!!

There is I2C support for nRF5 micro controllers, is there any sample code available to interface an I2C device with nRF5.

Also, is there adc support for nRF5 series controllers?    

--
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: QEMU + Peripherals

Nashif, Anas
 

You probably want to look at renode: https://github.com/renode/renode

Also see https://www.youtube.com/watch?v=3g3T1cXtReg

Anas

-----Original Message-----
From: zephyr-users-bounces@lists.zephyrproject.org [mailto:zephyr-users-bounces@lists.zephyrproject.org] On Behalf Of Inaki Malerba
Sent: Sunday, December 10, 2017 7:22 PM
To: zephyr-users@lists.zephyrproject.org
Subject: [Zephyr-users] QEMU + Peripherals

Hi there!

I'm wondering what would be the best way to emulate a full board with peripherals.

In this case, I'm building a quadcopter based on a stm32f401 with some sensors like an IMU, TOF, barometer, etc. which are connected via an I2C bus.

Is there any way to simulate the interaction between those chips? I mean if there's a way to write a simple code that would act as the IMU and answer to i2c commands, etc.


Thanks in advance!

--
Martin Iñaki Malerba

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


QEMU + Peripherals

Inaki Malerba
 

Hi there!

I'm wondering what would be the best way to emulate a full board with
peripherals.

In this case, I'm building a quadcopter based on a stm32f401 with some
sensors like an IMU, TOF, barometer, etc. which are connected via an I2C
bus.

Is there any way to simulate the interaction between those chips? I mean
if there's a way to write a simple code that would act as the IMU and
answer to i2c commands, etc.


Thanks in advance!

--
Martin Iñaki Malerba


QEMU + Peripherals.

Inaki Malerba <inaki@...>
 

Hi there!

I'm wondering what would be the best way to emulate a full board with
peripherals.

In this case, I'm building a quadcopter based on a stm32f401 with some
sensors like an IMU, TOF, barometer, etc. which are connected via an I2C
bus.

Is there any way to simulate the interaction between those chips? I mean
if there's a way to write a simple code that would act as the IMU and
answer to i2c commands, etc.


Thanks in advance!


IPSP ping fails

Priyanka
 

Issue with IPSP sample (recent master branch) : Ping fails. 


BLE address is assigned to k64f board. bluetoothctl utility and its scan discover IPSP node.
BLE connection is up, interface bt0 is up.
On zephyr side, iface shows interface bluetooth.


Ping to k64f board fails. Ping from Zephyr side to Linux host fails.
Wireshark capture shows checksum error (checksum incorrect) for ICMPv6 packet.


$ ping6 2001:db8::1
PING 2001:db8::1(2001:db8::1) 56 data bytes
^C
--- 2001:db8::1 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 2999ms


zephyr

-----------

net> ping 2001:db8::2
Sent a ping to 2001:db8::2
Ping timeout


Test set up for IPv6 over BLE :

[Kw41z (ble controller)+ k64f (zephyr IPSP)] <---------->[Kw41z (ble controller)+Linux host]


At one end : Two boards frdm-kw41z and frdm-k64f are stacked together.
kw41z (flashed with hci_blackbox firmware) is ble controller with k64f as ble host (flashed with zephyr sample IPSP).


$ sudo minicom -s -D /dev/ttyACMx -b 115200


[bt] [WRN] set_flow_control: Controller to host flow control not supported
[bt] [INF] show_dev_info: Identity: 00:04:9f:00:00:15 (public)
[bt] [INF] show_dev_info: HCI: version 4.2 (0x08) revision 0x000b, manufacturer 0x0025
[bt] [INF] show_dev_info: LMP: version 4.2 (0x08) subver 0x0121
[ipsp] [INF] init_app: Run IPSP sample
[ipsp] [INF] listen: Starting to wait


net> iface

Interface 0x20009f40 (Bluetooth)

Link addr : 00:04:9F:00:00:15
MTU : 1280
IPv6 unicast addresses (max 3):
2001:db8::1 manual preferred infinite
fe80::4:9fff:fe00:15 autoconf preferred infinite
IPv6 multicast addresses (max 2):
ff84::2
ff02::1
IPv6 prefixes (max 2):

IPv6 hop limit : 64
IPv6 base reachable time : 30000
IPv6 reachable time : 21690
IPv6 retransmit timer : 0


net> nbr


Neighbor Interface Flags State Remain Link Address
[ 1] 0x20009418 0x20009f40 0/1/0/1 static 0 00:60:37:00:00:16 fe80::60:37ff:fe00:16


At the other end: Second kw41z (flashed with hci_blackbox firmware) is ble controller attached to Linux host.


$ sudo hciattach ttyACMy any 115200 noflow sleep (in Linux terminal)


$ sudo hcitool lecc 00:04:9f:00:00:15
Connection handle 32


$ sudo hcitool conn
Connections:
< LE 00:04:9F:00:00:15 handle 32 state 1 lm MASTER


$ sudo hcitool dev
Devices:
hci0 00:60:37:00:00:16


$ bluetoothctl
[NEW] Controller 00:60:37:00:00:16 nxa15861-1704 [default]
[NEW] Device 00:04:9F:00:00:15 Test IPSP node
[NEW] Device 00:60:37:00:00:16 Test IPSP node
[CHG] Device 00:04:9F:00:00:15 Connected: yes
[Test IPSP node]#


$ ifconfig bt0


bt0 Link encap:UNSPEC HWaddr 00-60-37-FF-FE-00-00-16-00-00-00-00-00-00-00-00
inet6 addr: fe80::260:37ff:fe00:16/64 Scope:Link
inet6 addr: 2001:db8::2/64 Scope:Global
UP POINTOPOINT RUNNING MULTICAST MTU:1280 Metric:1
RX packets:9 errors:0 dropped:0 overruns:0 frame:0
TX packets:16 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1
RX bytes:419 (419.0 B) TX bytes:882 (882.0 B)


conf options addition to prj.conf


CONFIG_NET_L2_ETHERNET=n
CONFIG_ETH_MCUX=n
CONFIG_ETH_MCUX_0=n

CONFIG_BT_PRIVACY=n



Priyanka


Re: Disabling Relay feature of a node of bluetooth mesh

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

Hi Johan,

>There's something not matching up with the description of your
configuration however.
>You said that NODE1 has both Relay and GATT Proxy
states disabled

for NODE1, Proxy is enabled. This explains relaying of messages over advertising. 



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


On Fri, Dec 8, 2017 at 2:51 PM, Johan Hedberg <johan.hedberg@...> wrote:
Hi Ashish,

On Fri, Dec 08, 2017, Johan Hedberg wrote:
> On Fri, Dec 08, 2017, ashish.shukla@... wrote:
> > NODE1 does receives the messages and process it. But it relay/forward the
> > same message to network by reducing TTL value by 1.
> >
> > In my case, GATT client is mobile phone so it isn't possible to know
> > whether it receives something or not, for now.
> >
> > I'm attaching snapshot of terminal of NODE1, when it receives messages from
> > NODE2 on pressing the button.
>
> Are you concluding that the relaying happens because you see the
> "Relaying packet" log message? If so, then that's a wrong assumption,
> and the log message is indeed misleading. Please take a look at the
> bt_mesh_net_relay() function in net.c. You'll see that the log message
> is printed as soon as some basic checks are passed, but that does not
> mean that bt_mesh_adv_send() at the end of the function will get called,
> since that's still behind the relay_to_adv() check.

There's something not matching up with the description of your
configuration however. You said that NODE1 has both Relay and GATT Proxy
states disabled, however bt_mesh_net_relay() has the following test
before printing the log message that could be seen on your console:

        if (rx->net_if == BT_MESH_NET_IF_ADV &&
            bt_mesh_relay_get() != BT_MESH_RELAY_ENABLED &&
            bt_mesh_gatt_proxy_get() != BT_MESH_GATT_PROXY_ENABLED) {
                return;
        }

So the function should bail out at this point for any packet received
over advertising when neither Relay nor GATT Proxy is set to enabled.
Your logs show that the packet was received over net_if 0, which is
BT_MESH_NET_IF_ADV, so based on the fact that the code continued from
this point it seems you had either Relay or GATT Proxy enabled.

Johan


Re: Disabling Relay feature of a node of bluetooth mesh

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

Hi Johan,

Thanks for in detailed explanation, that clarified related issues.


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


On Fri, Dec 8, 2017 at 2:39 PM, Johan Hedberg <johan.hedberg@...> wrote:
Hi Ashish,

On Fri, Dec 08, 2017, ashish.shukla@... wrote:
> NODE1 does receives the messages and process it. But it relay/forward the
> same message to network by reducing TTL value by 1.
>
> In my case, GATT client is mobile phone so it isn't possible to know
> whether it receives something or not, for now.
>
> I'm attaching snapshot of terminal of NODE1, when it receives messages from
> NODE2 on pressing the button.

Are you concluding that the relaying happens because you see the
"Relaying packet" log message? If so, then that's a wrong assumption,
and the log message is indeed misleading. Please take a look at the
bt_mesh_net_relay() function in net.c. You'll see that the log message
is printed as soon as some basic checks are passed, but that does not
mean that bt_mesh_adv_send() at the end of the function will get called,
since that's still behind the relay_to_adv() check.

Johan


Re: Disabling Relay feature of a node of bluetooth mesh

Johan Hedberg
 

Hi Ashish,

On Fri, Dec 08, 2017, Johan Hedberg wrote:
On Fri, Dec 08, 2017, ashish.shukla@corvi.com wrote:
NODE1 does receives the messages and process it. But it relay/forward the
same message to network by reducing TTL value by 1.

In my case, GATT client is mobile phone so it isn't possible to know
whether it receives something or not, for now.

I'm attaching snapshot of terminal of NODE1, when it receives messages from
NODE2 on pressing the button.
Are you concluding that the relaying happens because you see the
"Relaying packet" log message? If so, then that's a wrong assumption,
and the log message is indeed misleading. Please take a look at the
bt_mesh_net_relay() function in net.c. You'll see that the log message
is printed as soon as some basic checks are passed, but that does not
mean that bt_mesh_adv_send() at the end of the function will get called,
since that's still behind the relay_to_adv() check.
There's something not matching up with the description of your
configuration however. You said that NODE1 has both Relay and GATT Proxy
states disabled, however bt_mesh_net_relay() has the following test
before printing the log message that could be seen on your console:

if (rx->net_if == BT_MESH_NET_IF_ADV &&
bt_mesh_relay_get() != BT_MESH_RELAY_ENABLED &&
bt_mesh_gatt_proxy_get() != BT_MESH_GATT_PROXY_ENABLED) {
return;
}

So the function should bail out at this point for any packet received
over advertising when neither Relay nor GATT Proxy is set to enabled.
Your logs show that the packet was received over net_if 0, which is
BT_MESH_NET_IF_ADV, so based on the fact that the code continued from
this point it seems you had either Relay or GATT Proxy enabled.

Johan


Re: Disabling Relay feature of a node of bluetooth mesh

Johan Hedberg
 

Hi Ashish,

On Fri, Dec 08, 2017, ashish.shukla@corvi.com wrote:
NODE1 does receives the messages and process it. But it relay/forward the
same message to network by reducing TTL value by 1.

In my case, GATT client is mobile phone so it isn't possible to know
whether it receives something or not, for now.

I'm attaching snapshot of terminal of NODE1, when it receives messages from
NODE2 on pressing the button.
Are you concluding that the relaying happens because you see the
"Relaying packet" log message? If so, then that's a wrong assumption,
and the log message is indeed misleading. Please take a look at the
bt_mesh_net_relay() function in net.c. You'll see that the log message
is printed as soon as some basic checks are passed, but that does not
mean that bt_mesh_adv_send() at the end of the function will get called,
since that's still behind the relay_to_adv() check.

Johan


Re: Disabling Relay feature of a node of bluetooth mesh

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

Hi Johan,

NODE1 does receives the messages and process it. But it relay/forward the same message to network by reducing TTL value by 1.

In my case, GATT client is mobile phone so it isn't possible to know whether it receives something or not, for now.

I'm attaching snapshot of terminal of NODE1, when it receives messages from NODE2 on pressing the button.







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


On Fri, Dec 8, 2017 at 12:23 PM, Johan Hedberg <johan.hedberg@...> wrote:
Hi Ashish,

On Fri, Dec 08, 2017, ashish.shukla@... wrote:
> Here is brief about my experimental setup :
>
> 1. NODE1 : Proxy enabled, Relay disabled
> 2. NODE2 : Proxy disabled, Relay disabled
>
> Now, both nodes belong to same group, which means they are subscribed to
> same group address. When I published data on the same group address over
> GATT bearer using android app, NODE1 relays data, while NODE2 doesn't. This
> is as it was expected.
>
> NODE2 is programmed for a button interrupt, which submits a task to system
> thread with callback function as below
>
> static void pub_presence(struct k_work *work)
> {
>     static unsigned char led = 0;
>     static unsigned char trans_id = 0;
>
>     int err;
>
>     bt_mesh_model_msg_init(root_models[2].pub->msg, OP_GEN_ONOFF_SET);
>     net_buf_simple_add_u8(root_models[2].pub->msg,led=led^1);
>     net_buf_simple_add_u8(root_models[2].pub->msg,trans_id++);
>
>     err = bt_mesh_model_publish(&root_models[2]);
>     if (err) {
>         printk("Error in publishing message ");
>     }
>
> }
>
> What I understand is this publishing is over advertising bearer,

Publishing is not tied to any specific bearer, rather the message is
expected to be delivered to all network interfaces the network layer is
connected to, including GATT.

> and NODE1 should not be relaying this packet. But NODE1 relays this
> packet as well.

What exactly do you mean by relaying? If NODE2 publishes the message
over advertising and NODE1 receives it over advertising, then NODE1
should at least process the message (since it's subscribed to the group
address). However upon receiving the message NODE1 should not forward
the message to any of its GATT clients or relay it back to the
advertising bearer. If you're seeing any of these last two things
happening, then I'd like to see the debug logs with ADV and NET debugs
enabled.

Also note that since NODE2 is subscribed to the same group address the
message will also be delivered locally to NODE2.

Johan


Re: Disabling Relay feature of a node of bluetooth mesh

Johan Hedberg
 

Hi Ashish,

On Fri, Dec 08, 2017, ashish.shukla@corvi.com wrote:
Here is brief about my experimental setup :

1. NODE1 : Proxy enabled, Relay disabled
2. NODE2 : Proxy disabled, Relay disabled

Now, both nodes belong to same group, which means they are subscribed to
same group address. When I published data on the same group address over
GATT bearer using android app, NODE1 relays data, while NODE2 doesn't. This
is as it was expected.

NODE2 is programmed for a button interrupt, which submits a task to system
thread with callback function as below

static void pub_presence(struct k_work *work)
{
static unsigned char led = 0;
static unsigned char trans_id = 0;

int err;

bt_mesh_model_msg_init(root_models[2].pub->msg, OP_GEN_ONOFF_SET);
net_buf_simple_add_u8(root_models[2].pub->msg,led=led^1);
net_buf_simple_add_u8(root_models[2].pub->msg,trans_id++);

err = bt_mesh_model_publish(&root_models[2]);
if (err) {
printk("Error in publishing message ");
}

}

What I understand is this publishing is over advertising bearer,
Publishing is not tied to any specific bearer, rather the message is
expected to be delivered to all network interfaces the network layer is
connected to, including GATT.

and NODE1 should not be relaying this packet. But NODE1 relays this
packet as well.
What exactly do you mean by relaying? If NODE2 publishes the message
over advertising and NODE1 receives it over advertising, then NODE1
should at least process the message (since it's subscribed to the group
address). However upon receiving the message NODE1 should not forward
the message to any of its GATT clients or relay it back to the
advertising bearer. If you're seeing any of these last two things
happening, then I'd like to see the debug logs with ADV and NET debugs
enabled.

Also note that since NODE2 is subscribed to the same group address the
message will also be delivered locally to NODE2.

Johan


Re: Stack check failure with qemu_x86

Vakul Garg <vakul.garg@...>
 

Thanks.
I could resolve this issue on qemu_x86 by increasing MAIN_STACK_SIZE in the configuration.

I am not sure whether increasing stack size is required for my hardware board as well or is it only qemu_x86 which exhausted the stack and detected stack overflow.

I am debugging some issue on ARM based board (frdm-k64f) where I suspected corruption.
Does the stack check feature works on arm as well the same way as it worked over qemu_x86?
For the hardware board, zephyr/.config shows HW_STACK_PROTECTION=n.

-----Original Message-----
From: Luiz Augusto von Dentz [mailto:luiz.dentz@gmail.com]
Sent: Thursday, December 07, 2017 7:15 PM
To: Vakul Garg <vakul.garg@nxp.com>
Cc: zephyr-users@lists.zephyrproject.org
Subject: Re: [Zephyr-users] Stack check failure with qemu_x86

Hi Vakul,

On Thu, Dec 7, 2017 at 5:38 AM, Vakul Garg <vakul.garg@nxp.com> wrote:
Hi



I am running IPSP sample app using qemu_86 (on master branch).

I have enabled following to detect stack corruption.



+CONFIG_DEBUG=y

+CONFIG_STACK_USAGE=y

+CONFIG_STACK_SENTINEL=y



This results in stack check error.

I tried attaching gdb, but the qemu itself terminates resulting on
closure of debug connection



Can someone give me pointers how to debug the same?



***** Stack Check Fail! *****

Current thread ID = 0x004035a0

Faulting segment:address = 0x0008:0x00003f6f

eax: 0x5be0cd19, ebx: 0xa54ff53a, ecx: 0x6a09e667, edx: 0x3c6ef372

esi: 0x1f83d9ab, edi: 0x510e527f, ebp: 0x9b05688c, esp: 0x0041dff8

eflags: 0x202

Terminate emulator due to fatal kernel error
addr2line -e zephyr/zephyr.elf 0x00003f6f
/home/vudentz/git/zephyr-
github/ext/lib/crypto/tinycrypt/source/hmac_prng.c:187

This is with samples/bluetooth/ipsp sample build with -DBOARD=qemu_x86





Regards



Vakul




_______________________________________________
Zephyr-users mailing list
Zephyr-users@lists.zephyrproject.org
https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flis
ts.zephyrproject.org%2Fmailman%2Flistinfo%2Fzephyr-
users&data=02%7C01%
7Cvakul.garg%40nxp.com%7C20e3ff6b7a5f4e6bc3dd08d53d78aa01%7C68
6ea1d3bc
2b4c6fa92cd99c5c301635%7C0%7C0%7C636482510819985701&sdata=M
ZDhH8jJ73tT
ie6npumV7caNM3jtDFJoG1WA9gZtLIY%3D&reserved=0


--
Luiz Augusto von Dentz


Re: Disabling Relay feature of a node of bluetooth mesh

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

Hi Johan,

Here is brief about my experimental setup :

1. NODE1 : Proxy enabled, Relay disabled
2. NODE2 : Proxy disabled, Relay disabled

Now, both nodes belong to same group, which means they are subscribed to same group address. When I published data on the same group address over GATT bearer using android app, NODE1 relays data, while NODE2 doesn't. This is as it was expected.

NODE2 is programmed for a button interrupt, which submits a task to system thread with callback function as below

static void pub_presence(struct k_work *work)

    static unsigned char led = 0;
    static unsigned char trans_id = 0;
   
    int err;    

    bt_mesh_model_msg_init(root_models[2].pub->msg, OP_GEN_ONOFF_SET);
    net_buf_simple_add_u8(root_models[2].pub->msg,led=led^1);
    net_buf_simple_add_u8(root_models[2].pub->msg,trans_id++);

    err = bt_mesh_model_publish(&root_models[2]);
    if (err) {
        printk("Error in publishing message ");
    }   
 


What I understand is this publishing is over advertising bearer, and NODE1 should not be relaying this packet. But NODE1 relays this packet as well.

 

 


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


On Thu, Dec 7, 2017 at 6:05 PM, Johan Hedberg <johan.hedberg@...> wrote:
Hi Ashish,

On Thu, Dec 07, 2017, ashish.shukla@... wrote:
> I was not understanding meaning of *CONFIG_BT_MESH_RELAY=n*  correctly.
> Thanks for clarification.
>
> However, when I enabled the proxy feature of a node, and disabled its relay
> feature, it relays messages from mesh network as well. I'm using latest
> version  zephyr-1.10.0-rc3.

As I said earlier, when the Proxy feature is enabled, the proxy *should*
be relaying messages from the network to any connected GATT client,
regardless of the Relay feature being enabled or not. If you don't want
your GATT Client to see network traffic, i.e. to only have access to
elements on the GATT Proxy itself, then you should disable the GATT
Proxy feature (have CONFIG_BT_MESH_GATT_PROXY=y but set cfg.gatt_proxy
to BT_MESH_GATT_PROXY_DISABLED).

If you're really seeing advertising to advertising relaying with rc3
(which does have all the latest fixes) there's something very strange
going on, since the logic for this is now quite simple in the code. You
can check this yourself by looking at the bt_mesh_net_relay() function
and the relay_to_adv() helper function that it uses. Both are found in
subsys/bluetooth/host/mesh/net.c.

Johan

2341 - 2360 of 2712