Date   

samples/basic/button code not working on nrf52840

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

Hi,

I'm trying to work with button interrupt available in samples/basic/button example on nrf52840. I'm unable to figure out why it isn't working.
Code compiles successfully but interrupt is never enabled. Any help would be appreciated. 


--
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: Mesh: mesh_shell: Unexplained warning from proxy.c:net_id_adv()

Johan Hedberg
 

Hi Steve,

On Mon, Dec 04, 2017, Steve Brown wrote:
If I issue an ident w/ gatt-proxy off, it completes without a warning.

If I issue an ident w/ gatt-proxy on, it completes without a warning.

If I issue an ident w/ gatt-proxy on and a connection from meshctl has
been established to the config service, it gives the warning "Failed to
advertise using Network ID (err -5)".

I've attached a fairly verbose log. The warning is at the end.

Can somebody explain what's going on?
I believe this is proxy.c trying to restart (connectable) advertising,
however since you're already maxed out at the number of supported
connections the controller throws you an error saying it can't do
connectable advertising at the moment. This should generally be a benign
warning, since the right type of advertising will be resumed eventually
when the connection gets disconnected.

Increasing CONFIG_BT_MAX_CONN should help avoid this warning coming too
easily, but the downside is increased runtime memory consumption.

Yet another option would be for proxy.c to do connection counting and
not attempt connectable advertising if it knows we're at MAX_CONN
already.

Johan


Mesh: mesh_shell: Unexplained warning from proxy.c:net_id_adv()

Steve Brown
 

If I issue an ident w/ gatt-proxy off, it completes without a warning.

If I issue an ident w/ gatt-proxy on, it completes without a warning.

If I issue an ident w/ gatt-proxy on and a connection from meshctl has
been established to the config service, it gives the warning "Failed to
advertise using Network ID (err -5)".

I've attached a fairly verbose log. The warning is at the end.

Can somebody explain what's going on?

Thanks,

Steve

ident
[bt] [DBG] bt_mesh_proxy_identity_enable: (0x200001d4)
[bt] [DBG] bt_mesh_adv_update: (0x200001d4)
mesh> [bt] [DBG] bt_mesh_proxy_adv_stop: (0x20000abc) adv_enabled 0
[bt] [DBG] bt_mesh_proxy_adv_start: (0x20000abc)
[bt] [DBG] gatt_proxy_advertise: (0x20000abc)
[bt] [DBG] gatt_proxy_advertise: (0x20000abc) Node ID active for 20 ms, 29980 ms remaining
[bt] [DBG] node_id_adv: (0x20000abc)
[bt] [DBG] bt_hci_cmd_create: (0x20000abc) opcode 0x2008 param_len 32
[bt] [DBG] bt_hci_cmd_create: (0x20000abc) buf 0x20003084
[bt] [DBG] bt_hci_cmd_send_sync: (0x20000abc) buf 0x20003084 opcode 0x2008 len 35
[bt] [DBG] process_events: (0x20000628) count 4
[bt] [DBG] process_events: (0x20000628) ev->state 4
[bt] [DBG] send_cmd: (0x20000628) calling net_buf_get
[bt] [DBG] send_cmd: (0x20000628) calling sem_take_wait
[bt] [DBG] send_cmd: (0x20000628) Sending command 0x2008 (buf 0x20003084) to driver
[bt] [DBG] bt_send: (0x20000628) buf 0x20003084 len 35 type 0
[bt] [DBG] bt_buf_get_cmd_complete: (0x20000628) sent_cmd 0x20003084
[bt] [DBG] hci_cmd_complete: (0x20000628) opcode 0x2008
[bt] [DBG] hci_cmd_done: (0x20000628) opcode 0x2008 status 0x00 buf 0x20003084
[bt] [DBG] process_events: (0x20000628) ev->state 0
[bt] [DBG] process_events: (0x20000628) ev->state 0
[bt] [DBG] process_events: (0x20000628) ev->state 0
[bt] [DBG] bt_hci_cmd_send_sync: (0x20000abc) opcode 0x2008 status 0x00
[bt] [DBG] bt_hci_cmd_create: (0x20000abc) opcode 0x2009 param_len 32
[bt] [DBG] bt_hci_cmd_create: (0x20000abc) buf 0x20003084
[bt] [DBG] bt_hci_cmd_send_sync: (0x20000abc) buf 0x20003084 opcode 0x2009 len 35
[bt] [DBG] hci_tx_thread: (0x20000628) Calling k_poll with 4 events
[bt] [DBG] process_events: (0x20000628) count 4
[bt] [DBG] process_events: (0x20000628) ev->state 4
[bt] [DBG] send_cmd: (0x20000628) calling net_buf_get
[bt] [DBG] send_cmd: (0x20000628) calling sem_take_wait
[bt] [DBG] send_cmd: (0x20000628) Sending command 0x2009 (buf 0x20003084) to driver
[bt] [DBG] bt_send: (0x20000628) buf 0x20003084 len 35 type 0
[bt] [DBG] bt_buf_get_cmd_complete: (0x20000628) sent_cmd 0x20003084
[bt] [DBG] hci_cmd_complete: (0x20000628) opcode 0x2009
[bt] [DBG] hci_cmd_done: (0x20000628) opcode 0x2009 status 0x00 buf 0x20003084
[bt] [DBG] process_events: (0x20000628) ev->state 0
[bt] [DBG] process_events: (0x20000628) ev->state 0
[bt] [DBG] process_events: (0x20000628) ev->state 0
[bt] [DBG] bt_hci_cmd_send_sync: (0x20000abc) opcode 0x2009 status 0x00
[bt] [DBG] set_random_address: (0x20000abc) cf:f1:b8:81:59:d0
[bt] [DBG] bt_hci_cmd_create: (0x20000abc) opcode 0x2006 param_len 15
[bt] [DBG] bt_hci_cmd_create: (0x20000abc) buf 0x20003084
[bt] [DBG] bt_hci_cmd_send_sync: (0x20000abc) buf 0x20003084 opcode 0x2006 len 18
[bt] [DBG] hci_tx_thread: (0x20000628) Calling k_poll with 4 events
[bt] [DBG] process_events: (0x20000628) count 4
[bt] [DBG] process_events: (0x20000628) ev->state 4
[bt] [DBG] send_cmd: (0x20000628) calling net_buf_get
[bt] [DBG] send_cmd: (0x20000628) calling sem_take_wait
[bt] [DBG] send_cmd: (0x20000628) Sending command 0x2006 (buf 0x20003084) to driver
[bt] [DBG] bt_send: (0x20000628) buf 0x20003084 len 18 type 0
[bt] [DBG] bt_buf_get_cmd_complete: (0x20000628) sent_cmd 0x20003084
[bt] [DBG] hci_cmd_complete: (0x20000628) opcode 0x2006
[bt] [DBG] hci_cmd_done: (0x20000628) opcode 0x2006 status 0x00 buf 0x20003084
[bt] [DBG] process_events: (0x20000628) ev->state 0
[bt] [DBG] process_events: (0x20000628) ev->state 0
[bt] [DBG] process_events: (0x20000628) ev->state 0
[bt] [DBG] bt_hci_cmd_send_sync: (0x20000abc) opcode 0x2006 status 0x00
[bt] [DBG] bt_hci_cmd_create: (0x20000abc) opcode 0x200a param_len 1
[bt] [DBG] bt_hci_cmd_create: (0x20000abc) buf 0x20003084
[bt] [DBG] bt_hci_cmd_send_sync: (0x20000abc) buf 0x20003084 opcode 0x200a len 4
[bt] [DBG] hci_tx_thread: (0x20000628) Calling k_poll with 4 events
[bt] [DBG] process_events: (0x20000628) count 4
[bt] [DBG] process_events: (0x20000628) ev->state 4
[bt] [DBG] send_cmd: (0x20000628) calling net_buf_get
[bt] [DBG] send_cmd: (0x20000628) calling sem_take_wait
[bt] [DBG] send_cmd: (0x20000628) Sending command 0x200a (buf 0x20003084) to driver
[bt] [DBG] bt_send: (0x20000628) buf 0x20003084 len 4 type 0
[bt] [DBG] bt_buf_get_cmd_complete: (0x20000628) sent_cmd 0x20003084
[bt] [DBG] hci_cmd_complete: (0x20000628) opcode 0x200a
[bt] [DBG] hci_cmd_done: (0x20000628) opcode 0x200a status 0x0c buf 0x20003084
[bt] [DBG] process_events: (0x20000628) ev->state 0
[bt] [DBG] process_events: (0x20000628) ev->state 0
[bt] [DBG] process_events: (0x20000628) ev->state 0
[bt] [DBG] bt_hci_cmd_send_sync: (0x20000abc) opcode 0x200a status 0x0c
[bt] [WRN] node_id_adv: Failed to advertise using Node ID (err -5)
[bt] [DBG] adv_thread: (0x20000abc) Proxy Advertising up to 29980 ms
[bt] [DBG] hci_tx_thread: (0x20000628) Calling k_poll with 4 events
[bt] [DBG] bt_recv: (0x20001e14) buf 0x200030ec len 31
[bt] [DBG] hci_acl: (0x20001e14) buf 0x200030ec
[bt] [DBG] hci_acl: (0x20001e14) handle 0 len 27 flags 2
[bt] [DBG] bt_recv: (0x20001e14) buf 0x20003150 len 8
[bt] [DBG] hci_acl: (0x20001e14) buf 0x20003150
[bt] [DBG] hci_acl: (0x20001e14) handle 0 len 4 flags 1
[bt] [DBG] proxy_complete_pdu: (0x20001e14) Mesh Network PDU
[bt] [DBG] bt_mesh_net_recv: (0x20001e14) rssi 0 net_if 2
[bt] [DBG] bt_mesh_net_decode: (0x20001e14) 23 bytes: f418e15ba74a1cc0f37f0401171db93fea97337cd5587d
[bt] [DBG] net_find_and_decrypt: (0x20001e14)
[bt] [DBG] net_decrypt: (0x20001e14) NID 0x74 net_idx 0x0000
[bt] [DBG] net_decrypt: (0x20001e14) IVI 1 net->iv_index 0x00000005
[bt] [DBG] net_decrypt: (0x20001e14) src 0x0077
[bt] [DBG] bt_mesh_net_decode: (0x20001e14) Decryption successful. Payload len 19
[bt] [DBG] bt_mesh_net_decode: (0x20001e14) src 0x0077 dst 0x0100 ttl 10
[bt] [DBG] bt_mesh_net_decode: (0x20001e14) PDU: f40a00001b00770100007ffc1e3c7546a3093a
[bt] [DBG] bt_mesh_proxy_addr_add: (0x20001e14) filter_type 1 addr 0x0077
[bt] [DBG] filter_add: (0x20001e14) addr 0x0077
[bt] [DBG] bt_mesh_model_recv: (0x20001e14) app_idx 0xfffe src 0x0077 dst 0x0100
[bt] [DBG] bt_mesh_model_recv: (0x20001e14) len 5: 8047000000
[bt] [DBG] bt_mesh_model_recv: (0x20001e14) OpCode 0x00008047
[bt] [DBG] node_identity_set: (0x20001e14) net_idx 0x0000 app_idx 0xfffe src 0x0077 len 3: 000000
[bt] [DBG] bt_mesh_adv_update: (0x20001e14)
[bt] [DBG] model_send: (0x20001e14) net_idx 0x0000 app_idx 0xfffe dst 0x0077
[bt] [DBG] model_send: (0x20001e14) len 6: 804800000000
[bt] [DBG] bt_mesh_net_send: (0x20001e14) src 0x0100 dst 0x0077 len 11 headroom 9 tailroom 9
[bt] [DBG] bt_mesh_net_send: (0x20001e14) Payload len 11: 009b793b15c4261c475083
[bt] [DBG] bt_mesh_net_send: (0x20001e14) Seq 0x000023
[bt] [DBG] bt_mesh_net_encode: (0x20001e14) src 0x0100 dst 0x0077 ctl 0 seq 0x000023
[bt] [DBG] bt_mesh_proxy_relay: (0x20001e14) 24 bytes to dst 0x0077
[bt] [DBG] client_filter_match: (0x20001e14) filter_type 1 addr 0x0077
[bt] [DBG] proxy_segment_and_send: (0x20001e14) conn 0x200006a4 type 0x00 len 24: f44927af8c8edfd95d356567da16850701e4fb881bd0dba3
[bt] [DBG] proxy_send: (0x20001e14) 25 bytes: 00f44927af8c8edfd95d356567da16850701e4fb881bd0dba3
[bt] [DBG] gatt_notify: (0x20001e14) conn 0x200006a4 handle 0x000e
[bt] [DBG] bt_mesh_proxy_adv_stop: (0x20000abc) adv_enabled 0
[bt] [DBG] bt_mesh_proxy_adv_start: (0x20000abc)
[bt] [DBG] gatt_proxy_advertise: (0x20000abc)
[bt] [DBG] net_id_adv: (0x20000abc)
[bt] [DBG] net_id_adv: (0x20000abc) Advertising with NetId d47679433fdb104a
[bt] [DBG] bt_hci_cmd_create: (0x20000abc) opcode 0x2008 param_len 32
[bt] [DBG] bt_hci_cmd_create: (0x20000abc) buf 0x20003084
[bt] [DBG] bt_hci_cmd_send_sync: (0x20000abc) buf 0x20003084 opcode 0x2008 len 35
[bt] [DBG] process_events: (0x20000628) count 4
[bt] [DBG] process_events: (0x20000628) ev->state 4
[bt] [DBG] send_cmd: (0x20000628) calling net_buf_get
[bt] [DBG] send_cmd: (0x20000628) calling sem_take_wait
[bt] [DBG] send_cmd: (0x20000628) Sending command 0x2008 (buf 0x20003084) to driver
[bt] [DBG] bt_send: (0x20000628) buf 0x20003084 len 35 type 0
[bt] [DBG] bt_buf_get_cmd_complete: (0x20000628) sent_cmd 0x20003084
[bt] [DBG] hci_cmd_complete: (0x20000628) opcode 0x2008
[bt] [DBG] hci_cmd_done: (0x20000628) opcode 0x2008 status 0x00 buf 0x20003084
[bt] [DBG] process_events: (0x20000628) ev->state 0
[bt] [DBG] process_events: (0x20000628) ev->state 0
[bt] [DBG] process_events: (0x20000628) ev->state 4
[bt] [DBG] bt_send: (0x20000628) buf 0x20003d08 len 31 type 2
[bt] [DBG] bt_send: (0x20000628) buf 0x20003d6c len 9 type 2
[bt] [DBG] bt_hci_cmd_send_sync: (0x20000abc) opcode 0x2008 status 0x00
[bt] [DBG] bt_hci_cmd_create: (0x20000abc) opcode 0x2009 param_len 32
[bt] [DBG] bt_hci_cmd_create: (0x20000abc) buf 0x20003084
[bt] [DBG] bt_hci_cmd_send_sync: (0x20000abc) buf 0x20003084 opcode 0x2009 len 35
[bt] [DBG] hci_num_completed_packets: (0x20001e7c) num_handles 1
[bt] [DBG] hci_num_completed_packets: (0x20001e7c) handle 0 count 1
[bt] [DBG] hci_tx_thread: (0x20000628) Calling k_poll with 4 events
[bt] [DBG] process_events: (0x20000628) count 4
[bt] [DBG] process_events: (0x20000628) ev->state 4
[bt] [DBG] send_cmd: (0x20000628) calling net_buf_get
[bt] [DBG] send_cmd: (0x20000628) calling sem_take_wait
[bt] [DBG] send_cmd: (0x20000628) Sending command 0x2009 (buf 0x20003084) to driver
[bt] [DBG] bt_send: (0x20000628) buf 0x20003084 len 35 type 0
[bt] [DBG] bt_buf_get_cmd_complete: (0x20000628) sent_cmd 0x20003084
[bt] [DBG] hci_cmd_complete: (0x20000628) opcode 0x2009
[bt] [DBG] hci_cmd_done: (0x20000628) opcode 0x2009 status 0x00 buf 0x20003084
[bt] [DBG] process_events: (0x20000628) ev->state 0
[bt] [DBG] process_events: (0x20000628) ev->state 4
[bt] [DBG] process_events: (0x20000628) ev->state 0
[bt] [DBG] hci_num_completed_packets: (0x20001e7c) num_handles 1
[bt] [DBG] hci_num_completed_packets: (0x20001e7c) handle 0 count 1
[bt] [DBG] bt_hci_cmd_send_sync: (0x20000abc) opcode 0x2009 status 0x00
[bt] [DBG] set_random_address: (0x20000abc) cf:f1:b8:81:59:d0
[bt] [DBG] bt_hci_cmd_create: (0x20000abc) opcode 0x2006 param_len 15
[bt] [DBG] bt_hci_cmd_create: (0x20000abc) buf 0x20003084
[bt] [DBG] bt_hci_cmd_send_sync: (0x20000abc) buf 0x20003084 opcode 0x2006 len 18
[bt] [DBG] hci_tx_thread: (0x20000628) Calling k_poll with 4 events
[bt] [DBG] process_events: (0x20000628) count 4
[bt] [DBG] process_events: (0x20000628) ev->state 4
[bt] [DBG] send_cmd: (0x20000628) calling net_buf_get
[bt] [DBG] send_cmd: (0x20000628) calling sem_take_wait
[bt] [DBG] send_cmd: (0x20000628) Sending command 0x2006 (buf 0x20003084) to driver
[bt] [DBG] bt_send: (0x20000628) buf 0x20003084 len 18 type 0
[bt] [DBG] bt_buf_get_cmd_complete: (0x20000628) sent_cmd 0x20003084
[bt] [DBG] hci_cmd_complete: (0x20000628) opcode 0x2006
[bt] [DBG] hci_cmd_done: (0x20000628) opcode 0x2006 status 0x00 buf 0x20003084
[bt] [DBG] process_events: (0x20000628) ev->state 0
[bt] [DBG] process_events: (0x20000628) ev->state 4
[bt] [DBG] process_events: (0x20000628) ev->state 0
[bt] [DBG] bt_hci_cmd_send_sync: (0x20000abc) opcode 0x2006 status 0x00
[bt] [DBG] bt_hci_cmd_create: (0x20000abc) opcode 0x200a param_len 1
[bt] [DBG] bt_hci_cmd_create: (0x20000abc) buf 0x20003084
[bt] [DBG] bt_hci_cmd_send_sync: (0x20000abc) buf 0x20003084 opcode 0x200a len 4
[bt] [DBG] hci_tx_thread: (0x20000628) Calling k_poll with 4 events
[bt] [DBG] process_events: (0x20000628) count 4
[bt] [DBG] process_events: (0x20000628) ev->state 4
[bt] [DBG] send_cmd: (0x20000628) calling net_buf_get
[bt] [DBG] send_cmd: (0x20000628) calling sem_take_wait
[bt] [DBG] send_cmd: (0x20000628) Sending command 0x200a (buf 0x20003084) to driver
[bt] [DBG] bt_send: (0x20000628) buf 0x20003084 len 4 type 0
[bt] [DBG] bt_buf_get_cmd_complete: (0x20000628) sent_cmd 0x20003084
[bt] [DBG] hci_cmd_complete: (0x20000628) opcode 0x200a
[bt] [DBG] hci_cmd_done: (0x20000628) opcode 0x200a status 0x0c buf 0x20003084
[bt] [DBG] process_events: (0x20000628) ev->state 0
[bt] [DBG] process_events: (0x20000628) ev->state 0
[bt] [DBG] process_events: (0x20000628) ev->state 0
[bt] [DBG] bt_hci_cmd_send_sync: (0x20000abc) opcode 0x200a status 0x0c

#define BT_HCI_OP_LE_SET_ADV_ENABLE BT_OP(BT_OGF_LE, 0x000a)
#define BT_HCI_ERR_CMD_DISALLOWED 0x0c

[bt] [WRN] net_id_adv: Failed to advertise using Network ID (err -5)

#define EIO 5 /* I/O error */

[bt] [DBG] adv_thread: (0x20000abc) Proxy Advertising up to -1 ms
[bt] [DBG] hci_tx_thread: (0x20000628) Calling k_poll with 4 events


Re: Zephyr issue tracking system moved to Github

Carles Cufi
 

Hi Paul,

-----Original Message-----
From: zephyr-devel-bounces@lists.zephyrproject.org [mailto:zephyr-devel-
bounces@lists.zephyrproject.org] On Behalf Of Paul Sokolovsky
Sent: 04 December 2017 10:46
To: Jukka Rissanen <jukka.rissanen@linux.intel.com>
Cc: devel@lists.zephyrproject.org
Subject: Re: [Zephyr-devel] Zephyr issue tracking system moved to Github

Hello,

On Mon, 25 Sep 2017 11:57:35 +0300
Jukka Rissanen <jukka.rissanen@linux.intel.com> wrote:

Hi Anas,

This is not very user friendly atm. For example it is impossible to
find all networking related PR as if I select "area: Networking" I get
only some of the network related PR.

I suggest following change:

* There are too many networking labels, one "area: Networking" is
enough.
This RFC from Jukka never got a response, but it seems that everyone
implicitly agreed and followed it, for example:

"area: Networking Clients" has 0 labeled issues
"area: Net Protocols" had 2 issues (closed) over all this time

I seem to be able to edit labels, so unless someone responds to stop me,
I'm going to remove labels above, and leave just "area:
Networking" (183 total issues so far).
Makes sense, +1 from me. Also consistent with Bluetooth, which is a single label.

Carles


Re: Zephyr issue tracking system moved to Github

Tomasz Bursztyka
 

Hi Paul,


This RFC from Jukka never got a response, but it seems that everyone
implicitly agreed and followed it, for example:

"area: Networking Clients" has 0 labeled issues
"area: Net Protocols" had 2 issues (closed) over all this time

I seem to be able to edit labels, so unless someone responds to stop
me, I'm going to remove labels above, and leave just "area:
Networking" (183 total issues so far).
Fine by me.

Tomasz


Re: Zephyr issue tracking system moved to Github

Paul Sokolovsky
 

Hello,

On Mon, 25 Sep 2017 11:57:35 +0300
Jukka Rissanen <jukka.rissanen@linux.intel.com> wrote:

Hi Anas,

This is not very user friendly atm. For example it is impossible to
find all networking related PR as if I select "area: Networking" I get
only some of the network related PR.

I suggest following change:

* There are too many networking labels, one "area: Networking" is
enough.
This RFC from Jukka never got a response, but it seems that everyone
implicitly agreed and followed it, for example:

"area: Networking Clients" has 0 labeled issues
"area: Net Protocols" had 2 issues (closed) over all this time

I seem to be able to edit labels, so unless someone responds to stop
me, I'm going to remove labels above, and leave just "area:
Networking" (183 total issues so far).



Cheers,
Jukka


On Sat, 2017-09-23 at 22:13 +0000, Nashif, Anas wrote:
Hi,
As announced earlier this week, we now have migrated all JIRA issues
to github issues:

https://github.com/zephyrproject-rtos/zephyr/issues

under GH issues we have kept the components and consolidated some of
them to a more generic label. All components now start with: “area:
“.

Here is how issues types were migrated:
- Bugs = Bugs
- Stories = Enhancements
- Epics = Features/ Feature Requests.

We did keep the links to what used to be stories in epic type
entries and used the format available in Github to link those in.
Assignees that are active in both Jira and Github were set
accordingly.

We will need to have a mega scrub of the issues in Github and
cleanup some outdated items, but I think we do have a good start
now.
Jira ZEP project is now read-only with a link to the corresponding
GH issues entry. GH issues also have a reference to the original ZEP
entry.

Please take a look and let us know if you find any problems.

Any new issues should be filed in Github now, Jira will not accept
any new entries.

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


--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


Re: GPIO interrupt not linked using zephyr API

Tomasz Bursztyka
 

Hi,

You shouldn't have to deal with low level hardware specific code.
Zephyr provides a generic way to manipulate gpios and all.

Have a look at samples/drivers/gpio/

And to include/gpio.h as well.

Tomasz

Hello,

//-------------------------------------------------------------------
---------------------------------------------------------

#include <zephyr.h>
#include <misc/printk.h>

#include "nrf_delay.h"
#include "nrf_gpio.h"

#include "board.h"


#define SETB(x,y) (x|=(1<<y)) //for o/p
#define CLRB(x,y) (x&=(~(1<<y))) //for o/p
#define TGLB(x,y) (x^=(1<<y)) //for o/p
#define CHECKB(x,y) (x&(1<<y)) //for i/p

void GPIOTE_IRQHandler(void *arg)
{
if(NRF_GPIOTE->EVENTS_IN[0]==1)
{
NRF_GPIOTE->EVENTS_IN[0]=0;
NRF_P0->OUT ^= (1<<15); //LED3
}
}

void gpio_init(void)
{

NRF_P0->DIR |= 0x0001E000;
NRF_P0->OUTSET |= 0x0001E000;

NRF_P0->PIN_CNF[11]=0x0000000C;


NRF_GPIOTE->INTENSET |= 0x00000001;
NRF_GPIOTE->CONFIG[0] |= 0x00000001 | (11<<8) | (2<<16);

//NVIC_EnableIRQ(GPIOTE_IRQn);

IRQ_CONNECT(6,1,GPIOTE_IRQHandler,0,0);
irq_enable(6);
}

void main(void)
{
printk("Hello World! %s\n", CONFIG_ARCH);
gpio_init();

while(1)
{
NRF_P0->OUT ^= (1<<13); //LED1
nrf_delay_ms(20);

/*(Polling Method)
if(CHECKB(NRF_P0->IN,11)==0)
{

while(CHECKB(NRF_P0->IN,11)==0){}

printk("Button Pressed !!\n\r");

NRF_P0->OUT ^= (1<<16); //LED4

}
*/
}
}

//-------------------------------------------------------------------
--------------------------------------------------------------------

This is my simple code in which I want to enable button pressed
interrupt.

My board is nrf52840_pca10056.

Button1 is attached to P0.11.
Using polling method, I'm able to toggle on board LED4. But same is
not happing with interrupt.
Code gets compile without any error. But don't know why interrupt is
not working.

I've also add following config parameters in prj.conf

CONFIG_GPIO=y
CONFIG_GPIO_NRF5_P0=y
CONFIG_GPIO_NRF5_P0_DEV_NAME="SW0_GPIO_PIN"
CONFIG_GPIO_NRF5_PORT_P0_PRI=6



For reference I'm using this link -> http://docs.zephyrproject.org/ke
rnel/other/interrupts.html
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


Re: Publishing user data

Johan Hedberg
 

Hi Ashish,

On Mon, Dec 04, 2017, ashish.shukla@corvi.com wrote:
In a project, I need to publish specific data to neighboring nodes
utilizing TTL value. For this sake, I've configured all the nodes to be a
relay node and publish address for the model is set to 0xFFE, which has
been done so that it publishes to all relay nodes.Is my understanding of
address 0xFFE correct?
The "all relays" group address is 0xfffe and not 0xffe. In most cases
it's unwise (inefficient) to have all nodes of a mesh network acting as
relays, so you may want to rethink your setup. It might make more sense
to use a normal group address instead. Note that with a normal group
address, after configuring model publication, you'll also need to
configure model subscription by having your provisioner send Config
Model Subscription Add messages to your nodes.

Now, when I configured this node using android app, publish address of the
model is over-written by the app.
What do you mean that it's overwritten? The provisioner (the "android
app" in this case I suppose?) is the entity that in most normal
situations is expected to configure the model publication. I.e. the
publication address wouldn't be set to anything until the app sends a
Config Model Publication Set message to your node.

Should I modify this address to 0xFFE before using bt_mesh_model_publish()
API ?
What do you mean by "modify"? Normally it would be the provisioner that
configures the model publication with through the configuration model.

Johan


Publishing user data

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

Hi everyone !

In a project, I need to publish specific data to neighboring nodes utilizing TTL value. For this sake, I've configured all the nodes to be a relay node and publish address for the model is set to 0xFFE, which has been done so that it publishes to all relay nodes.Is my understanding of address 0xFFE correct?

Now, when I configured this node using android app, publish address of the model is over-written by the app.

Should I modify this address to 0xFFE before using bt_mesh_model_publish() API ? 


--
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: GATT proxy behavior

Johan Hedberg
 

Hi Steve,

On Sun, Dec 03, 2017, Johan Hedberg wrote:
Node 2 stops advertising its 1828 service.
Network Identity-based advertising should indeed stop, since that's
forbidden in state 0x00 as per section 7.2.2.1:

"A node that does not support the Proxy feature or has the Proxy feature
disabled shall not advertise with Network ID."

Node Identity, which is the only permitted connectable advertising type
in this state requires explicitly enabling it, either using the
configuration model, or with the bt_mesh_proxy_identity_enable() API. It
might e.g. make sense to trigger a call to this API through a button
press on your board. If you're using the mesh shell you can also do this
by issuing the "ident" command.
Just wanted to add that the node is required to advertise using Node
Identity up to 60 seconds after provisioning, to allow the initial
configuration to happen, as per section 7.2.2.2.3:

"If both PB-GATT and Mesh Proxy Service are supported, immediately after
provisioning is completed using PB-GATT (see Section 5.2.2), the Mesh
Proxy Service shall start advertising with Node Identity using the
provisioned network."

So no special explicit action is needed there. At any later time if Node
ID advertising is needed you need to explicitly enable it however.

Johan


Re: GATT proxy behavior

Johan Hedberg
 

Hi Steve,

On Sun, Dec 03, 2017, Steve Brown wrote:
If I set the proxy state to 0x0 on the node I'm connected to (node 2),
the connection is closed and I have no access to either node.
This is according to the following text that's found in section 4.2.11:

"Upon transition from GATT Proxy state 0x01 to GATT Proxy state 0x00 the
GATT Bearer Server shall disconnect all GATT Bearer Clients."

Node 2 stops advertising its 1828 service.
Network Identity-based advertising should indeed stop, since that's
forbidden in state 0x00 as per section 7.2.2.1:

"A node that does not support the Proxy feature or has the Proxy feature
disabled shall not advertise with Network ID."

Node Identity, which is the only permitted connectable advertising type
in this state requires explicitly enabling it, either using the
configuration model, or with the bt_mesh_proxy_identity_enable() API. It
might e.g. make sense to trigger a call to this API through a button
press on your board. If you're using the mesh shell you can also do this
by issuing the "ident" command.

Johan


GATT proxy behavior

Steve Brown
 

I'd like to verify that the behavior I'm seeing is correct.

I have 2 nodes. Both are configured with proxy & relay enabled. I'm
using meshctl as a provisioning and configuration client.

Both nodes boot and start advertising GATT bearer (type 01, service
1827) and advertising bearer (type 2b) beacons.

meshctl's "discover-unprovisioned" discovers both nodes.

I provision node 1 (0100). A connection is established to the 1827
service on that node, the node is provisioned and the connection is
closed. A new connection is made to service 1828 on that node.

I do another "discover-unprovisioned" and now see only one
unprovisioned node.

I provision node 2 (0104). It goes like node 1 leaving me connected to
service 1828 on node 2.

I can now configure both nodes, node 2 via the connection to its 1828
service and node 1 presumably by proxy relay via the advertising
bearer.

If I set the proxy state to 0x0 on the node I'm connected to (node 2),
the connection is closed and I have no access to either node. Node 2
stops advertising its 1828 service.

If I issue a "connect 0", I get connected to the 1828 service on node 1
and can again configure both nodes.

If I set the proxy state on the current remaining node to 0x0, that
connection is closed and I can no longer access either node. My sniffer
sees only advertising bearer beacons (type 2b) on the air.

Thanks,

Steve


Re: mesh: relay traffic when relay state is 0x02 (not supported)

Vikrant More <vikrant8051@...>
 

Sir I'm talking about this(attached image) ON/OFF setting which available during configuration of Device.

As per my observation, whatever we set here doesn't get reflected at device side. Means if we turn off relay, NODE still relaying the received packets.

>>The GATT service should be gone. After provisioning, if you disconnect,
>>reconnect, and are still able to discover the provisioning service UUID
>>in the GATT database, then that's a bug.


After provisioning, Silicon Labs Mesh App is not able to discover the NODEs. But it get detected in nRFConnect App (App provided by Nordic Semiconductor) as unknown device (not as Zephyr). We can easily connect with it & easily access Mesh Provising Service using the same App.

When I send some random data via it, on terminal of NODE we get error as "message is too short". Means NODE accepts data from any device. 

If possible please try all my observations using SiliconLabs App & nrf52840_pca10056 board.

Correct me if I'm wrong somewhere.

Thank You !!

On Dec 3, 2017 2:00 PM, "Johan Hedberg" <johan.hedberg@...> wrote:
Hi Vikrant,

On Sun, Dec 03, 2017, Vikrant More wrote:
> If I configured Relay OFF/ Proxy Off using Silicon Labs Bluetooth Mesh App
> that does not change anything in reality.  If Relay is ON as per firmware
> then it remains ON.

What do you mean by this? That the state value remains 0x01 or that the
node keeps relaying regardless of the value? If you have GATT Proxy
enabled then you're observing the same thing as Steve reported, and this
should get fixed by my latest pull request.

> Plus even after provisioning, I can connect to #MeshProvisioningService on
> NODE using #nRFconnect App and also able to send data to it.

The GATT service should be gone. After provisioning, if you disconnect,
reconnect, and are still able to discover the provisioning service UUID
in the GATT database, then that's a bug.

Johan


Re: mesh: relay traffic when relay state is 0x02 (not supported)

Johan Hedberg
 

Hi Steve,

On Sun, Dec 03, 2017, Steve Brown wrote:
I tested the relay state patch and it prohibits changing from 0x02.

I'm still pretty fuzzy on the proxy stuff. So, if I connect to the GATT
mesh proxy service (1828) on a node, the data-in & data-out
characteristics give me access to all that mesh network's advertising
bearer traffic. Thus, if I send a message to a model of an element of
that node and the model replies, that message also gets sent to the
GATT proxy service as well as an advertising bearer message.

I tested your other 2 patches by having another node with relay
disabled, but GATT proxy service enabled. I've verified that
bt_mesh_net_relay() gets called, but bt_mesh_adv_send() doesn't. So, no
adv->adv relay.

I'm running some tests where one node has proxy enabled and the other
doesn't and will likely have some more questions. I'll start another
thread.
Ok, thanks for the update. Please keep me posted on how your testing
goes.

One thing to note about the GATT Proxy state: even if GATT Proxy is
disabled (state value 0x00) the idea is that GATT Clients can still
access local elements on the GATT Proxy node. The reasoning is that a
provisioner may want to provision a device over PB-GATT, and then
immediately connect as GATT Client to configure the node. This is a
particularly common scenario you'll see with low power nodes, since
talking to them over GATT consumes considerably less power than through
advertising (as long as they're not in an established Friendship).

Johan


Re: mesh: relay traffic when relay state is 0x02 (not supported)

Steve Brown
 

Hi Johan,

On Sun, 2017-12-03 at 10:11 +0200, Johan Hedberg wrote:
Hi Steve,

On Sun, Dec 03, 2017, Johan Hedberg wrote:
On Sat, Dec 02, 2017, Steve Brown wrote:
Another relay-related question. In testing, cfg_srv.c:relay_set()
allows changing the relay state even if it's "unsupported"
(0x02). Spec
4.2.8 Relay seems to prohibit changing it if it is 0x02.
That's a good observation. I'll create a fix for it.
The following pull request should fix both of the issues you
reported:

https://github.com/zephyrproject-rtos/zephyr/pull/5243

Could you let me know if that works for you?

A little clarification regarding bt_mesh_net_relay(): You might
initially wonder why it's being called without first checking the
Relay
state. The reason is that the Relay state only applies to relaying
from
the Advertising bearer to the Advertising bearer, whereas the GATT
Proxy
state is what controls relaying to/from the GATT Proxy bearer (only
exception is locally originated packets). The bt_mesh_net_relay()
function tries to cover all of these use cases.

Johan
I tested the relay state patch and it prohibits changing from 0x02.

I'm still pretty fuzzy on the proxy stuff. So, if I connect to the GATT
mesh proxy service (1828) on a node, the data-in & data-out
characteristics give me access to all that mesh network's advertising
bearer traffic. Thus, if I send a message to a model of an element of
that node and the model replies, that message also gets sent to the
GATT proxy service as well as an advertising bearer message.

I tested your other 2 patches by having another node with relay
disabled, but GATT proxy service enabled. I've verified that
bt_mesh_net_relay() gets called, but bt_mesh_adv_send() doesn't. So, no
adv->adv relay.

I'm running some tests where one node has proxy enabled and the other
doesn't and will likely have some more questions. I'll start another
thread.

Thanks again for your patience,

Steve


Re: mesh: relay traffic when relay state is 0x02 (not supported)

Johan Hedberg
 

Hi Steve,

On Sun, Dec 03, 2017, Johan Hedberg wrote:
On Sat, Dec 02, 2017, Steve Brown wrote:
Another relay-related question. In testing, cfg_srv.c:relay_set()
allows changing the relay state even if it's "unsupported" (0x02). Spec
4.2.8 Relay seems to prohibit changing it if it is 0x02.
That's a good observation. I'll create a fix for it.
The following pull request should fix both of the issues you reported:

https://github.com/zephyrproject-rtos/zephyr/pull/5243

Could you let me know if that works for you?

A little clarification regarding bt_mesh_net_relay(): You might
initially wonder why it's being called without first checking the Relay
state. The reason is that the Relay state only applies to relaying from
the Advertising bearer to the Advertising bearer, whereas the GATT Proxy
state is what controls relaying to/from the GATT Proxy bearer (only
exception is locally originated packets). The bt_mesh_net_relay()
function tries to cover all of these use cases.

Johan


Re: mesh: relay traffic when relay state is 0x02 (not supported)

Johan Hedberg
 

Hi Steve,

On Sat, Dec 02, 2017, Steve Brown wrote:
Another relay-related question. In testing, cfg_srv.c:relay_set()
allows changing the relay state even if it's "unsupported" (0x02). Spec
4.2.8 Relay seems to prohibit changing it if it is 0x02.
That's a good observation. I'll create a fix for it.

Johan


Re: mesh: relay traffic when relay state is 0x02 (not supported)

Steve Brown
 

Hi Johan,

On Sat, 2017-12-02 at 23:20 +0200, Johan Hedberg wrote:
Hi Steve,

On Sat, Dec 02, 2017, Steve Brown wrote:
Don't know why I'm seeing relay traffic.

The build for both nodes is identical and has a config of
"# CONFIG_BT_MESH_RELAY is not set"

I use meshctl to send a get-relay command to node 0100. The log
shows
it calls bt_mesh_proxy_relay(). However, get_relay() logs the relay
state as 0x02 (not supported).

Node 0104 also relays it.

Is the test in net.c:bt_mesh_net_send() prior to the call to
bt_mesh_proxy_relay() sufficient?
bt_mesh_proxy_relay() has several more tests to determine whether
relaying should happen or not. It's possible that something might not
be
completely right there, e.g. I suspect that having GATT proxy enabled
might cause relaying to the advertising bearer to be happening as
well.

Johan
Another relay-related question. In testing, cfg_srv.c:relay_set()
allows changing the relay state even if it's "unsupported" (0x02). Spec
4.2.8 Relay seems to prohibit changing it if it is 0x02.

Steve


Re: mesh: relay traffic when relay state is 0x02 (not supported)

Johan Hedberg
 

Hi Steve,

On Sat, Dec 02, 2017, Steve Brown wrote:
Don't know why I'm seeing relay traffic.

The build for both nodes is identical and has a config of
"# CONFIG_BT_MESH_RELAY is not set"

I use meshctl to send a get-relay command to node 0100. The log shows
it calls bt_mesh_proxy_relay(). However, get_relay() logs the relay
state as 0x02 (not supported).

Node 0104 also relays it.

Is the test in net.c:bt_mesh_net_send() prior to the call to
bt_mesh_proxy_relay() sufficient?
bt_mesh_proxy_relay() has several more tests to determine whether
relaying should happen or not. It's possible that something might not be
completely right there, e.g. I suspect that having GATT proxy enabled
might cause relaying to the advertising bearer to be happening as well.

Johan


mesh: relay traffic when relay state is 0x02 (not supported)

Steve Brown
 

Don't know why I'm seeing relay traffic.

The build for both nodes is identical and has a config of
"# CONFIG_BT_MESH_RELAY is not set"

I use meshctl to send a get-relay command to node 0100. The log shows
it calls bt_mesh_proxy_relay(). However, get_relay() logs the relay
state as 0x02 (not supported).

Node 0104 also relays it.

Is the test in net.c:bt_mesh_net_send() prior to the call to
bt_mesh_proxy_relay() sufficient?

Steve


NODE 0100
[bt] [DBG] bt_mesh_net_recv: (0x20002de0) rssi -23 net_if 0
[bt] [DBG] bt_mesh_net_decode: (0x20002de0) 20 bytes: f4a534a3f1669d68d1422b729f8321022fc6cb8d
[bt] [DBG] net_find_and_decrypt: (0x20002de0)
[bt] [DBG] net_decrypt: (0x20002de0) NID 0x74 net_idx 0x0000
[bt] [DBG] net_decrypt: (0x20002de0) IVI 1 net->iv_index 0x00000005
[bt] [DBG] net_decrypt: (0x20002de0) src 0x0077
[bt] [DBG] bt_mesh_net_decode: (0x20002de0) Decryption successful. Payload len 16
[bt] [DBG] bt_mesh_net_decode: (0x20002de0) src 0x0077 dst 0x0100 ttl 9
[bt] [DBG] bt_mesh_net_decode: (0x20002de0) PDU: f40900000a0077010000ec693489396a
[bt] [DBG] bt_mesh_model_recv: (0x20002de0) app_idx 0xfffe src 0x0077 dst 0x0100
[bt] [DBG] bt_mesh_model_recv: (0x20002de0) len 2: 8026
[bt] [DBG] bt_mesh_model_recv: (0x20002de0) OpCode 0x00008026
[bt] [DBG] relay_get: (0x20002de0) net_idx 0x0000 app_idx 0xfffe src 0x0077 len 0:
[bt] [DBG] model_send: (0x20002de0) net_idx 0x0000 app_idx 0xfffe dst 0x0077
[bt] [DBG] model_send: (0x20002de0) len 4: 8028020a
[bt] [DBG] bt_mesh_net_send: (0x20002de0) src 0x0100 dst 0x0077 len 9 headroom 9 tailroom 11
[bt] [DBG] bt_mesh_net_send: (0x20002de0) Payload len 9: 00a1630a34df88b25a
[bt] [DBG] bt_mesh_net_send: (0x20002de0) Seq 0x000009
[bt] [DBG] bt_mesh_net_encode: (0x20002de0) src 0x0100 dst 0x0077 ctl 0 seq 0x000009
[bt] [DBG] bt_mesh_proxy_relay: (0x20002de0) 22 bytes to dst 0x0077
[bt] [DBG] bt_mesh_proxy_adv_stop: (0x20001188) adv_enabled 1
[bt] [DBG] bt_mesh_proxy_adv_start: (0x20001188)
[bt] [DBG] gatt_proxy_advertise: (0x20001188)
[bt] [DBG] net_id_adv: (0x20001188)
[bt] [DBG] net_id_adv: (0x20001188) Advertising with NetId d47679433fdb104a

NODE 0104
[bt] [DBG] proxy_complete_pdu: (0x20002de0) Mesh Network PDU
[bt] [DBG] bt_mesh_net_recv: (0x20002de0) rssi 0 net_if 2
[bt] [DBG] bt_mesh_net_decode: (0x20002de0) 20 bytes: f43c138ba035eb5e6031896919655ced3144e90a
[bt] [DBG] net_find_and_decrypt: (0x20002de0)
[bt] [DBG] net_decrypt: (0x20002de0) NID 0x74 net_idx 0x0000
[bt] [DBG] net_decrypt: (0x20002de0) IVI 1 net->iv_index 0x00000005
[bt] [DBG] net_decrypt: (0x20002de0) src 0x0077
[bt] [DBG] bt_mesh_net_decode: (0x20002de0) Decryption successful. Payload len 16
[bt] [DBG] bt_mesh_net_decode: (0x20002de0) src 0x0077 dst 0x0100 ttl 10
[bt] [DBG] bt_mesh_net_decode: (0x20002de0) PDU: f40a00000a0077010000ec693489396a
[bt] [DBG] bt_mesh_proxy_addr_add: (0x20002de0) filter_type 1 addr 0x0077
[bt] [DBG] filter_add: (0x20002de0) addr 0x0077
[bt] [DBG] bt_mesh_net_relay: (0x20002de0) TTL 10 CTL 0 dst 0x0100
[bt] [DBG] bt_mesh_net_relay: (0x20002de0) Relaying packet. TTL is now 9
[bt] [DBG] bt_mesh_proxy_relay: (0x20002de0) 20 bytes to dst 0x0100
[bt] [DBG] client_filter_match: (0x20002de0) filter_type 1 addr 0x0100
[bt] [DBG] bt_mesh_proxy_adv_stop: (0x20001188) adv_enabled 1
[bt] [DBG] bt_mesh_proxy_adv_start: (0x20001188)
[bt] [DBG] gatt_proxy_advertise: (0x20001188)
[bt] [DBG] net_id_adv: (0x20001188)
[bt] [DBG] net_id_adv: (0x20001188) Advertising with NetId d47679433fdb104a
[bt] [DBG] bt_mesh_net_recv: (0x20002de0) rssi -21 net_if 0
[bt] [DBG] bt_mesh_net_decode: (0x20002de0) 22 bytes: f494b55c5d4add3e6882c9ec22cf8641b07d574e0d9e
[bt] [DBG] net_find_and_decrypt: (0x20002de0)
[bt] [DBG] net_decrypt: (0x20002de0) NID 0x74 net_idx 0x0000
[bt] [DBG] net_decrypt: (0x20002de0) IVI 1 net->iv_index 0x00000005
[bt] [DBG] net_decrypt: (0x20002de0) src 0x0100
[bt] [DBG] bt_mesh_net_decode: (0x20002de0) Decryption successful. Payload len 18
[bt] [DBG] bt_mesh_net_decode: (0x20002de0) src 0x0100 dst 0x0077 ttl 7
[bt] [DBG] bt_mesh_net_decode: (0x20002de0) PDU: f4070000090100007700a1630a34df88b25a
[bt] [DBG] bt_mesh_net_relay: (0x20002de0) TTL 7 CTL 0 dst 0x0077
[bt] [DBG] bt_mesh_net_relay: (0x20002de0) Relaying packet. TTL is now 6
[bt] [DBG] bt_mesh_proxy_relay: (0x20002de0) 22 bytes to dst 0x0077
[bt] [DBG] client_filter_match: (0x20002de0) filter_type 1 addr 0x0077
[bt] [DBG] proxy_segment_and_send: (0x20002de0) conn 0x20000514 type 0x00 len 22: f427ca3a40dde0258273f12a8e51aa01dbc6fe21abc6
[bt] [DBG] proxy_send: (0x20002de0) 23 bytes: 00f427ca3a40dde0258273f12a8e51aa01dbc6fe21abc6

4281 - 4300 of 8046