Date   

Re: [Zephyr-devel] I2C driver for nrf52840 not being compiled

Puzdrowski, Andrzej <Andrzej.Puzdrowski@...>
 

Hi.

 

For nRF52840 I2C driver is zephyr. All its option are in general i2c Kconfig file.

I attached configuration I had used to compile example you mentioned.

 

BR

 

Andrzej

 

 

From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of ashish.shukla@...
Sent: Friday, December 15, 2017 5:56 AM
To: zephyr-users@...; zephyr-devel@...
Subject: [Zephyr-devel] I2C driver for nrf52840 not being compiled

 

Hello everyone !

I'm trying to interface an I2C device with nrf52840 controller.

When I look into ../zephyr/drivers/i2c directory, there is no Kconfig file corresponding to i2c_nrf5.c 

Again in Kconfig, this driver isn't included, consequently I'm not being able to compile ../zephyr/samples/drivers/i2c_fujitsu_fram  demo for nrf52840.

what needs to be done to fix this issue?  

 

--

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: I2C driver for nrf52840 not being compiled

Chettimada, Vinayak Kariappa
 

Hi Ashish,

Did you select CONFIG_I2C_NRF5 in menuconfig or set CONFIG_I2C_NRF5=y in prj.conf file?

Also, you need to set CONFIG_I2C_NRF5_GPIO_SCA_PIN , CONFIG_I2C_NRF5_GPIO_SCA_PIN ,CONFIG_I2C_0=y, and CONFIG_I2C_0_IRQ_PRI.

Regards,
Vinayak

On 15 Dec 2017, at 05:56, ashish.shukla@corvi.com wrote:

Hello everyone !

I'm trying to interface an I2C device with nrf52840 controller.

When I look into ../zephyr/drivers/i2c directory, there is no Kconfig file corresponding to i2c_nrf5.c

Again in Kconfig, this driver isn't included, consequently I'm not being able to compile ../zephyr/samples/drivers/i2c_fujitsu_fram demo for nrf52840.

what needs to be done to fix this issue?

--
Warm regards,
Ashish Shukla
Jr. Embedded Engineer
Research & Development
www.corvi.com


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


I2C driver for nrf52840 not being compiled

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

Hello everyone !

I'm trying to interface an I2C device with nrf52840 controller.

When I look into ../zephyr/drivers/i2c directory, there is no Kconfig file corresponding to i2c_nrf5.c 

Again in Kconfig, this driver isn't included, consequently I'm not being able to compile ../zephyr/samples/drivers/i2c_fujitsu_fram  demo for nrf52840.

what needs to be done to fix this issue?  

--
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: [Zephyr-devel] Zephyr IPSP sample crashes and ble controller crashes (IPv6 over BLE)

Luiz Augusto von Dentz
 

Hi Priyanka,

Upgrading is recommended since the IPSP implementation on Linux was
broken when generating the IID, though we are preparing to deprecate
the debugfs interface as that was never meant for production.

On Tue, Dec 12, 2017 at 2:18 PM, Priyanka Rawat <priyanka.rawat@nxp.com> wrote:
Hi Luiz


I am on

$ uname -r
4.4.0-98-generic

Linux 4.4.0-98-generic #121-Ubuntu SMP Tue Oct 10 14:24:03 UTC 2017 x86_64
x86_64 x86_64 GNU/Linux

So if I enable ZEP1656 config option kconifg option in prj.conf (IPSP
sample) should it work ?

Or I should upgrade my Linux kernel version?


Thanks

Priyanka


________________________________
From: Luiz Augusto von Dentz <luiz.dentz@gmail.com>
Sent: Tuesday, December 12, 2017 5:00 PM
To: Priyanka Rawat
Cc: zephyr-users@lists.zephyrproject.org
Subject: Re: [Zephyr-devel] Zephyr IPSP sample crashes and ble controller
crashes (IPv6 over BLE)

Hi Priyanka,

Current IPSP configuration only works with Linux kernel version 4.12
or later, zephyr 1.9 used to have the infamous ZEP1656 config option
set which has been removed in 1.10.

On Tue, Dec 12, 2017 at 1:55 PM, Priyanka Rawat <priyanka.rawat@nxp.com>
wrote:
Hi Luiz


The HCI firmware hci_blackbox is from KW41Z SDK2.2.

BLE controller remains connected and bt0 does not go down if most of the
debug logs are disabled in prj.conf

As with debug logs enabled, it prints error

[bt] [ERR] read_payload: Not enough space in buffer

With my test set up k64f (zephyr IPSP)+ kw41z (ble controller), host flow
control is not enabled.


[bt] [WRN] set_flow_control: Controller to host flow control not supported


I wonder if we can enable UART flow control on frdm_k64f for HCI transport
with frdm_kw41z?

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

In addition, with recent zephyr master, I have another issue, while
testing
with sample IPSP, ping fails.

Please note I did not have this issue with zephyr-1.9.1. With same
configurations, ping worked fine with zephyr-1.9.1


Issue with IPSP sample (recent master branch) :


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 Multicast Listener Report Message V2,

Neighbor Solicitation for 2001:db8::2



zephyr

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


[bt] [WRN] set_flow_control: Controller to host flow control not supported
[bt] [WRN] hci_vs_init: Vendor HCI extensions not available
[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
[bt] [DBG] bt_l2cap_le_fixed_chan_register: (0x20001998) CID 0x0004
[bt] [DBG] bt_l2cap_le_fixed_chan_register: (0x20001998) CID 0x0006
[bt] [DBG] bt_smp_init: (0x20001998) LE SC enabled
[bt] [DBG] bt_l2cap_le_fixed_chan_register: (0x20001998) CID 0x0005
[bt] [DBG] bt_smp_pkey_ready: (0x200003b4)
[ipsp] [INF] init_app: Run IPSP sample

[ipsp] [ERR] get_context: Cannot bind IPv6 mcast (-2)
[ipsp] [ERR] listen: Cannot get network contexts

[bt] [DBG] bt_keys_find_irk: (0x200003b4) 00:60:37:00:00:16 (public)
[bt] [DBG] bt_l2cap_chan_add: (0x200003b4) conn 0x200008d4 chan 0x20000a28
[bt] [DBG] bt_smp_accept: (0x200003b4) conn 0x200008d4 handle 32


net> ping 2001:db8::2
Sent a ping to 2001:db8::2
[bt] [DBG] bt_l2cap_chan_send: (0x20001210) chan 0x20009bcc buf 0x20006e48
len 57
[bt] [DBG] l2cap_chan_create_seg: (0x20001210) ch 0x20009bcc seg
0x20006c8c
len 59
[bt] [DBG] l2cap_chan_le_send: (0x20001210) ch 0x20009bcc cid 0x0040 len
59
credits 4
[bt] [DBG] bt_l2cap_send_cb: (0x20001210) conn 0x200008d4 cid 64 len 59
[bt] [DBG] l2cap_chan_le_send_sdu: (0x20001210) ch 0x20009bcc cid 0x0040
sent 57 total_len 57
Ping timeout
net> iface

Interface 0x2000a020 (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):
ff02::1
ff02::1:ff00:1
IPv6 prefixes (max 2):
<none>
IPv6 hop limit : 64
IPv6 base reachable time : 30000
IPv6 reachable time : 17260
IPv6 retransmit timer : 0
net>

Thanks
Priyanka

________________________________
From: Luiz Augusto von Dentz <luiz.dentz@gmail.com>
Sent: Tuesday, December 5, 2017 6:23 PM
To: Priyanka Rawat
Cc: zephyr-users@lists.zephyrproject.org;
zephyr-devel@lists.zephyrproject.org
Subject: Re: [Zephyr-devel] Zephyr IPSP sample crashes and ble controller
crashes (IPv6 over BLE)

Hi Priyanka,

On Tue, Dec 5, 2017 at 5:30 PM, Priyanka Rawat <priyanka.rawat@nxp.com>
wrote:
Hello

My test set up for IPv6 over BLE is following :

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).
I assume hci_blackbox is not a zephyr based controller is it?

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


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

Issue with testing IPv6 over BLE :

Once the BLE connection is established, within few seconds BLE controller
gets disconnected.
Either zephyr (recent master branch) crashes or BLE controller crashes or
both. Often it is BLE controller that gets disconnected within few
seconds.
Restarting zephyr might enable establishing the connection once again,
but
then ble controller goes down immediately.
Im not sure if will be able to help in case the controller is not
really zephyr based in the other hand we should be able to fix the
host crash if you provide some traces when that happens.

After that, I should disconnect the boards and connect again (via usb
connection) in order to set up the ble connection again.

While on Zephyr side, it always prints connection handle 32
On Linux side, the first time connection handle is 32, afterwards it is
different (handle 65, 128 etc.,) as shown with "hcitool conn".
btmon log shows for specific handle : remote user terminated connection
or
connection terminated by local host
I guess with Zephyr the controller crashes and restart using the same
handle, while with Linux it manages to work fine, perhaps this is
because zephyr attempts to use the host flow control?


--
Luiz Augusto von Dentz
--
Luiz Augusto von Dentz


Re: [Zephyr-devel] Zephyr IPSP sample crashes and ble controller crashes (IPv6 over BLE)

Priyanka
 

Hi Luiz


I am on

$ uname -r
4.4.0-98-generic

Linux 4.4.0-98-generic #121-Ubuntu SMP Tue Oct 10 14:24:03 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

So if I enable  ZEP1656 config option kconifg option in prj.conf (IPSP sample) should it work ?

Or I should upgrade my Linux kernel version?


Thanks

Priyanka



From: Luiz Augusto von Dentz <luiz.dentz@...>
Sent: Tuesday, December 12, 2017 5:00 PM
To: Priyanka Rawat
Cc: zephyr-users@...
Subject: Re: [Zephyr-devel] Zephyr IPSP sample crashes and ble controller crashes (IPv6 over BLE)
 
Hi Priyanka,

Current IPSP configuration only works with Linux kernel version 4.12
or later, zephyr 1.9 used to have the infamous ZEP1656 config option
set which has been removed in 1.10.

On Tue, Dec 12, 2017 at 1:55 PM, Priyanka Rawat <priyanka.rawat@...> wrote:
> Hi Luiz
>
>
> The HCI firmware hci_blackbox is from KW41Z SDK2.2.
>
> BLE controller remains connected and bt0 does not go down if most of the
> debug logs are disabled in prj.conf
>
> As with debug logs enabled, it prints error
>
> [bt] [ERR] read_payload: Not enough space in buffer
>
> With my test set up k64f (zephyr IPSP)+ kw41z (ble controller), host flow
> control is not enabled.
>
>
> [bt] [WRN] set_flow_control: Controller to host flow control not supported
>
>
> I wonder if we can enable UART flow control on frdm_k64f for HCI transport
> with frdm_kw41z?
>
>  [Kw41z  (ble controller)+ k64f (zephyr IPSP)] <---------->[Kw41z (ble
> controller)+Linux host]
>
> In addition, with recent zephyr master, I have another issue, while testing
> with sample IPSP,  ping fails.
>
> Please note I did not have this issue with zephyr-1.9.1. With same
> configurations, ping worked fine with zephyr-1.9.1
>
>
> Issue with IPSP sample (recent master branch) :
>
>
> 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 Multicast Listener Report Message V2,
>
> Neighbor Solicitation for 2001:db8::2
>
>
>
> zephyr
>
> -----------------
>
>
> [bt] [WRN] set_flow_control: Controller to host flow control not supported
> [bt] [WRN] hci_vs_init: Vendor HCI extensions not available
> [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
> [bt] [DBG] bt_l2cap_le_fixed_chan_register: (0x20001998) CID 0x0004
> [bt] [DBG] bt_l2cap_le_fixed_chan_register: (0x20001998) CID 0x0006
> [bt] [DBG] bt_smp_init: (0x20001998) LE SC enabled
> [bt] [DBG] bt_l2cap_le_fixed_chan_register: (0x20001998) CID 0x0005
> [bt] [DBG] bt_smp_pkey_ready: (0x200003b4)
> [ipsp] [INF] init_app: Run IPSP sample
>
> [ipsp] [ERR] get_context: Cannot bind IPv6 mcast (-2)
> [ipsp] [ERR] listen: Cannot get network contexts
>
> [bt] [DBG] bt_keys_find_irk: (0x200003b4) 00:60:37:00:00:16 (public)
> [bt] [DBG] bt_l2cap_chan_add: (0x200003b4) conn 0x200008d4 chan 0x20000a28
> [bt] [DBG] bt_smp_accept: (0x200003b4) conn 0x200008d4 handle 32
>
>
> net> ping 2001:db8::2
> Sent a ping to 2001:db8::2
> [bt] [DBG] bt_l2cap_chan_send: (0x20001210) chan 0x20009bcc buf 0x20006e48
> len 57
> [bt] [DBG] l2cap_chan_create_seg: (0x20001210) ch 0x20009bcc seg 0x20006c8c
> len 59
> [bt] [DBG] l2cap_chan_le_send: (0x20001210) ch 0x20009bcc cid 0x0040 len 59
> credits 4
> [bt] [DBG] bt_l2cap_send_cb: (0x20001210) conn 0x200008d4 cid 64 len 59
> [bt] [DBG] l2cap_chan_le_send_sdu: (0x20001210) ch 0x20009bcc cid 0x0040
> sent 57 total_len 57
> Ping timeout
> net> iface
>
> Interface 0x2000a020 (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):
>         ff02::1
>         ff02::1:ff00:1
> IPv6 prefixes (max 2):
>         <none>
> IPv6 hop limit           : 64
> IPv6 base reachable time : 30000
> IPv6 reachable time      : 17260
> IPv6 retransmit timer    : 0
> net>
>
> Thanks
> Priyanka
>
> ________________________________
> From: Luiz Augusto von Dentz <luiz.dentz@...>
> Sent: Tuesday, December 5, 2017 6:23 PM
> To: Priyanka Rawat
> Cc: zephyr-users@...;
> zephyr-devel@...
> Subject: Re: [Zephyr-devel] Zephyr IPSP sample crashes and ble controller
> crashes (IPv6 over BLE)
>
> Hi Priyanka,
>
> On Tue, Dec 5, 2017 at 5:30 PM, Priyanka Rawat <priyanka.rawat@...>
> wrote:
>> Hello
>>
>> My test set up for IPv6 over BLE is following :
>>
>> 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).
>
> I assume hci_blackbox is not a zephyr based controller is it?
>
>> At the other end: Second kw41z (flashed with hci_blackbox firmware) is ble
>> controller attached to Linux host.
>>
>>
>> [Kw41z  (ble controller)+ k64f (zephyr IPSP)] <---------->[Kw41z (ble
>> controller)+Linux host]
>>
>> Issue with testing IPv6 over BLE :
>>
>> Once the BLE connection is established, within few seconds BLE controller
>> gets disconnected.
>> Either zephyr (recent master branch) crashes or BLE controller crashes or
>> both. Often it is BLE controller that gets disconnected within few
>> seconds.
>> Restarting zephyr might enable establishing the connection once again, but
>> then ble controller goes down immediately.
>
> Im not sure if will be able to help in case the controller is not
> really zephyr based in the other hand we should be able to fix the
> host crash if you provide some traces when that happens.
>
>> After that, I should disconnect the boards and connect again (via usb
>> connection) in order to set up the ble connection again.
>>
>> While on Zephyr side, it always prints connection handle 32
>> On Linux side, the first time connection handle is 32, afterwards it is
>> different (handle 65, 128 etc.,) as shown with "hcitool conn".
>> btmon log shows for specific handle : remote user terminated connection or
>> connection terminated by local host
>
> I guess with Zephyr the controller crashes and restart using the same
> handle, while with Linux it manages to work fine, perhaps this is
> because zephyr attempts to use the host flow control?



--
Luiz Augusto von Dentz


Re: [Zephyr-devel] Zephyr IPSP sample crashes and ble controller crashes (IPv6 over BLE)

Luiz Augusto von Dentz
 

Hi Priyanka,

Current IPSP configuration only works with Linux kernel version 4.12
or later, zephyr 1.9 used to have the infamous ZEP1656 config option
set which has been removed in 1.10.

On Tue, Dec 12, 2017 at 1:55 PM, Priyanka Rawat <priyanka.rawat@nxp.com> wrote:
Hi Luiz


The HCI firmware hci_blackbox is from KW41Z SDK2.2.

BLE controller remains connected and bt0 does not go down if most of the
debug logs are disabled in prj.conf

As with debug logs enabled, it prints error

[bt] [ERR] read_payload: Not enough space in buffer

With my test set up k64f (zephyr IPSP)+ kw41z (ble controller), host flow
control is not enabled.


[bt] [WRN] set_flow_control: Controller to host flow control not supported


I wonder if we can enable UART flow control on frdm_k64f for HCI transport
with frdm_kw41z?

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

In addition, with recent zephyr master, I have another issue, while testing
with sample IPSP, ping fails.

Please note I did not have this issue with zephyr-1.9.1. With same
configurations, ping worked fine with zephyr-1.9.1


Issue with IPSP sample (recent master branch) :


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 Multicast Listener Report Message V2,

Neighbor Solicitation for 2001:db8::2



zephyr

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


[bt] [WRN] set_flow_control: Controller to host flow control not supported
[bt] [WRN] hci_vs_init: Vendor HCI extensions not available
[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
[bt] [DBG] bt_l2cap_le_fixed_chan_register: (0x20001998) CID 0x0004
[bt] [DBG] bt_l2cap_le_fixed_chan_register: (0x20001998) CID 0x0006
[bt] [DBG] bt_smp_init: (0x20001998) LE SC enabled
[bt] [DBG] bt_l2cap_le_fixed_chan_register: (0x20001998) CID 0x0005
[bt] [DBG] bt_smp_pkey_ready: (0x200003b4)
[ipsp] [INF] init_app: Run IPSP sample

[ipsp] [ERR] get_context: Cannot bind IPv6 mcast (-2)
[ipsp] [ERR] listen: Cannot get network contexts

[bt] [DBG] bt_keys_find_irk: (0x200003b4) 00:60:37:00:00:16 (public)
[bt] [DBG] bt_l2cap_chan_add: (0x200003b4) conn 0x200008d4 chan 0x20000a28
[bt] [DBG] bt_smp_accept: (0x200003b4) conn 0x200008d4 handle 32


net> ping 2001:db8::2
Sent a ping to 2001:db8::2
[bt] [DBG] bt_l2cap_chan_send: (0x20001210) chan 0x20009bcc buf 0x20006e48
len 57
[bt] [DBG] l2cap_chan_create_seg: (0x20001210) ch 0x20009bcc seg 0x20006c8c
len 59
[bt] [DBG] l2cap_chan_le_send: (0x20001210) ch 0x20009bcc cid 0x0040 len 59
credits 4
[bt] [DBG] bt_l2cap_send_cb: (0x20001210) conn 0x200008d4 cid 64 len 59
[bt] [DBG] l2cap_chan_le_send_sdu: (0x20001210) ch 0x20009bcc cid 0x0040
sent 57 total_len 57
Ping timeout
net> iface

Interface 0x2000a020 (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):
ff02::1
ff02::1:ff00:1
IPv6 prefixes (max 2):
<none>
IPv6 hop limit : 64
IPv6 base reachable time : 30000
IPv6 reachable time : 17260
IPv6 retransmit timer : 0
net>

Thanks
Priyanka

________________________________
From: Luiz Augusto von Dentz <luiz.dentz@gmail.com>
Sent: Tuesday, December 5, 2017 6:23 PM
To: Priyanka Rawat
Cc: zephyr-users@lists.zephyrproject.org;
zephyr-devel@lists.zephyrproject.org
Subject: Re: [Zephyr-devel] Zephyr IPSP sample crashes and ble controller
crashes (IPv6 over BLE)

Hi Priyanka,

On Tue, Dec 5, 2017 at 5:30 PM, Priyanka Rawat <priyanka.rawat@nxp.com>
wrote:
Hello

My test set up for IPv6 over BLE is following :

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).
I assume hci_blackbox is not a zephyr based controller is it?

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


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

Issue with testing IPv6 over BLE :

Once the BLE connection is established, within few seconds BLE controller
gets disconnected.
Either zephyr (recent master branch) crashes or BLE controller crashes or
both. Often it is BLE controller that gets disconnected within few
seconds.
Restarting zephyr might enable establishing the connection once again, but
then ble controller goes down immediately.
Im not sure if will be able to help in case the controller is not
really zephyr based in the other hand we should be able to fix the
host crash if you provide some traces when that happens.

After that, I should disconnect the boards and connect again (via usb
connection) in order to set up the ble connection again.

While on Zephyr side, it always prints connection handle 32
On Linux side, the first time connection handle is 32, afterwards it is
different (handle 65, 128 etc.,) as shown with "hcitool conn".
btmon log shows for specific handle : remote user terminated connection or
connection terminated by local host
I guess with Zephyr the controller crashes and restart using the same
handle, while with Linux it manages to work fine, perhaps this is
because zephyr attempts to use the host flow control?
--
Luiz Augusto von Dentz


Re: [Zephyr-devel] Zephyr IPSP sample crashes and ble controller crashes (IPv6 over BLE)

Priyanka
 

Hi Luiz


The HCI firmware hci_blackbox is from KW41Z SDK2.2.

BLE controller remains connected and bt0 does not go down if most of the debug logs are disabled in prj.conf

As with debug logs enabled, it prints error

[bt] [ERR] read_payload: Not enough space in buffer

With my test set up k64f (zephyr IPSP)+ kw41z (ble controller), host flow control is not enabled.


[bt] [WRN] set_flow_control: Controller to host flow control not supported


I wonder if we can enable UART flow control on frdm_k64f for HCI transport with frdm_kw41z? 

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

In addition, with recent zephyr master, I have another issue, while testing with sample IPSP,  ping fails.

Please note I did not have this issue with zephyr-1.9.1. With same configurations, ping worked fine with zephyr-1.9.1


Issue with IPSP sample (recent master branch) :


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 Multicast Listener Report Message V2,

Neighbor Solicitation for 2001:db8::2



zephyr

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


[bt] [WRN] set_flow_control: Controller to host flow control not supported
[bt] [WRN] hci_vs_init: Vendor HCI extensions not available
[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
[bt] [DBG] bt_l2cap_le_fixed_chan_register: (0x20001998) CID 0x0004
[bt] [DBG] bt_l2cap_le_fixed_chan_register: (0x20001998) CID 0x0006
[bt] [DBG] bt_smp_init: (0x20001998) LE SC enabled
[bt] [DBG] bt_l2cap_le_fixed_chan_register: (0x20001998) CID 0x0005
[bt] [DBG] bt_smp_pkey_ready: (0x200003b4)
[ipsp] [INF] init_app: Run IPSP sample

[ipsp] [ERR] get_context: Cannot bind IPv6 mcast (-2)
[ipsp] [ERR] listen: Cannot get network contexts

[bt] [DBG] bt_keys_find_irk: (0x200003b4) 00:60:37:00:00:16 (public)
[bt] [DBG] bt_l2cap_chan_add: (0x200003b4) conn 0x200008d4 chan 0x20000a28
[bt] [DBG] bt_smp_accept: (0x200003b4) conn 0x200008d4 handle 32


net> ping 2001:db8::2
Sent a ping to 2001:db8::2
[bt] [DBG] bt_l2cap_chan_send: (0x20001210) chan 0x20009bcc buf 0x20006e48 len 57
[bt] [DBG] l2cap_chan_create_seg: (0x20001210) ch 0x20009bcc seg 0x20006c8c len 59
[bt] [DBG] l2cap_chan_le_send: (0x20001210) ch 0x20009bcc cid 0x0040 len 59 credits 4
[bt] [DBG] bt_l2cap_send_cb: (0x20001210) conn 0x200008d4 cid 64 len 59
[bt] [DBG] l2cap_chan_le_send_sdu: (0x20001210) ch 0x20009bcc cid 0x0040 sent 57 total_len 57
Ping timeout
net> iface

Interface 0x2000a020 (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):
        ff02::1
        ff02::1:ff00:1
IPv6 prefixes (max 2):
        <none>
IPv6 hop limit           : 64
IPv6 base reachable time : 30000
IPv6 reachable time      : 17260
IPv6 retransmit timer    : 0
net>

Thanks
Priyanka


From: Luiz Augusto von Dentz <luiz.dentz@...>
Sent: Tuesday, December 5, 2017 6:23 PM
To: Priyanka Rawat
Cc: zephyr-users@...; zephyr-devel@...
Subject: Re: [Zephyr-devel] Zephyr IPSP sample crashes and ble controller crashes (IPv6 over BLE)
 
Hi Priyanka,

On Tue, Dec 5, 2017 at 5:30 PM, Priyanka Rawat <priyanka.rawat@...> wrote:
> Hello
>
> My test set up for IPv6 over BLE is following :
>
> 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).

I assume hci_blackbox is not a zephyr based controller is it?

> At the other end: Second kw41z (flashed with hci_blackbox firmware) is ble
> controller attached to Linux host.
>
>
> [Kw41z  (ble controller)+ k64f (zephyr IPSP)] <---------->[Kw41z (ble
> controller)+Linux host]
>
> Issue with testing IPv6 over BLE :
>
> Once the BLE connection is established, within few seconds BLE controller
> gets disconnected.
> Either zephyr (recent master branch) crashes or BLE controller crashes or
> both. Often it is BLE controller that gets disconnected within few seconds.
> Restarting zephyr might enable establishing the connection once again, but
> then ble controller goes down immediately.

Im not sure if will be able to help in case the controller is not
really zephyr based in the other hand we should be able to fix the
host crash if you provide some traces when that happens.

> After that, I should disconnect the boards and connect again (via usb
> connection) in order to set up the ble connection again.
>
> While on Zephyr side, it always prints connection handle 32
> On Linux side, the first time connection handle is 32, afterwards it is
> different (handle 65, 128 etc.,) as shown with "hcitool conn".
> btmon log shows for specific handle : remote user terminated connection or
> connection terminated by local host

I guess with Zephyr the controller crashes and restart using the same
handle, while with Linux it manages to work fine, perhaps this is
because zephyr attempts to use the host flow control?


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

2281 - 2300 of 2659