You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mynewt.apache.org by Jacob Rosenthal <ja...@gmail.com> on 2016/12/27 21:37:01 UTC
ble_gattc_disc_svc_by_uuid problems
Hey all, been working with mynewt for a week or so now, trying to
understand the code and slim the nimble stack down for nrf51822qfaa
targets. Playing with central role now (modified blecent), and Im having
some trouble searching for a single svc by uuid (to save peer struct
memory, rather than indexing them all)
Either I dont understand ble_gattc_disc_svc_by_uuid or it has problems.
Its returning successfully but with a different uuid than I would expect
and weird handles
2357:[ts=18414036ssb, mod=4 level=1] GATT procedure initiated: discover
service by uuid; uuid=0000180d-0000-1000-800000805f9b34fb
2360:[ts=18437472ssb, mod=4 level=0] host tx hci data; handle=1 length=27
2361:[ts=18445284ssb, mod=4 level=0] ble_hs_hci_acl_tx(): 0x01 0x00 0x1b
0x00 0x17 0x00 0x04 0x00 0x06 0x01 0x00 0xff 0xff 0x00 0x28 0xfb 0x34 0x9b
0x5f 0x80 0x00 0x00 0x80 0x00 0x10 0x00 0x00 0x0d 0x18 0x00 0x00
2364:[ts=18468720ssb, mod=4 level=0] txed att command: find type value req;
conn=1 start_handle=0x0001 end_handle=0xffff attr_type=10240
2372:[ts=18531216ssb, mod=4 level=0] Number of Completed Packets:
num_handles=1
2374:[ts=18546840ssb, mod=4 level=0] handle:1 pkts:1
2379:[ts=18585900ssb, mod=4 level=0] ble_hs_hci_evt_acl_process(): handle=1
pb=2 len=9 data=0x05 0x00 0x04 0x00 0x01 0x06 0x01 0x00 0x0a
2382:[ts=18609336ssb, mod=4 level=0] rxed att command: error rsp; conn=1
req_op=6 handle=0x0001 error_code=10
2384:[ts=18624960ssb, mod=64 level=3] Service discovery complete; status=0
conn_handle=1
(gdb) p (peer->svcs)->slh_first->svc
$4 = {
start_handle = 16384,
end_handle = 8192,
uuid128 = "\365\r\000\000U\016\000\000U\016\000\000\000\000\000"
}
(gdb)
b blecent_on_svc_disc_complete
b blecent_on_chr_disc_complete
If I instead use ble_gattc_disc_all_svcs like the demo I get 3 services
found, and the one Im looking to find looks like:
839:[ts=6554652ssb, mod=4 level=1] GATT procedure initiated: discover all
services
841:[ts=6570276ssb, mod=4 level=0] host tx hci data; handle=1 length=11
843:[ts=6585900ssb, mod=4 level=0] ble_hs_hci_acl_tx(): 0x01 0x00 0x0b 0x00
0x07 0x00 0x04 0x00 0x10 0x01 0x00 0xff 0xff 0x00 0x28
845:[ts=6601524ssb, mod=4 level=0] txed att command: read group type req;
conn=1 start_handle=0x0001 end_handle=0xffff
853:[ts=6664020ssb, mod=4 level=0] Number of Completed Packets:
num_handles=1
854:[ts=6671832ssb, mod=4 level=0] handle:1 pkts:1
859:[ts=6710892ssb, mod=4 level=0] ble_hs_hci_evt_acl_process(): handle=1
pb=2 len=24 data=0x14 0x00 0x04 0x00 0x11 0x06 0x01 0x00 0x0b 0x00 0x00
0x18 0x0c 0x00 0x0e 0x00 0x01 0x18 0x0f 0x00 0x14 0x00 0x0d 0x18
863:[ts=6742140ssb, mod=4 level=0] rxed att command: read group type rsp;
conn=1 length=6
865:[ts=6757764ssb, mod=4 level=0] host tx hci data; handle=1 length=11
866:[ts=6765576ssb, mod=4 level=0] ble_hs_hci_acl_tx(): 0x01 0x00 0x0b 0x00
0x07 0x00 0x04 0x00 0x10 0x15 0x00 0xff 0xff 0x00 0x28
868:[ts=6781200ssb, mod=4 level=0] txed att command: read group type req;
conn=1 start_handle=0x0015 end_handle=0xffff
872:[ts=6812448ssb, mod=4 level=0] Number of Completed Packets:
num_handles=1
873:[ts=6820260ssb, mod=4 level=0] handle:1 pkts:1
878:[ts=6859320ssb, mod=4 level=0] ble_hs_hci_evt_acl_process(): handle=1
pb=2 len=18 data=0x0e 0x00 0x04 0x00 0x11 0x06 0x15 0x00 0x23 0x00 0x0a
0x18 0x24 0x00 0x26 0x00 0x0f 0x18
882:[ts=6890568ssb, mod=4 level=0] rxed att command: read group type rsp;
conn=1 length=6
884:[ts=6906192ssb, mod=4 level=0] host tx hci data; handle=1 length=11
885:[ts=6914004ssb, mod=4 level=0] ble_hs_hci_acl_tx(): 0x01 0x00 0x0b 0x00
0x07 0x00 0x04 0x00 0x10 0x27 0x00 0xff 0xff 0x00 0x28
887:[ts=6929628ssb, mod=4 level=0] txed att command: read group type req;
conn=1 start_handle=0x0027 end_handle=0xffff
891:[ts=6960876ssb, mod=4 level=0] Number of Completed Packets:
num_handles=1
893:[ts=6976500ssb, mod=4 level=0] handle:1 pkts:1
897:[ts=7007812ssb, mod=4 level=0] ble_hs_hci_evt_acl_process(): handle=1
pb=2 len=26 data=0x16 0x00 0x04 0x00 0x11 0x14 0x27 0x00 0xff 0xff 0xa9
0x0b 0x97 0x06 0x6a 0x01 0xcf 0xee 0x7e 0x54 0x7b 0xac 0x49 0xff 0x17 0x62
901:[ts=7039060ssb, mod=4 level=0] rxed att command: read group type rsp;
conn=1 length=20
904:[ts=7062496ssb, mod=64 level=3] Service discovery complete; status=0
conn_handle=1
(gdb) p (peer->svcs)->slh_first->svc
$1 = {start_handle = 1, end_handle = 11, uuid128 =
"\373\064\233_\200\000\000\200\000\020\000\000\000\030\000"}
(gdb)
I dont know if its helpful, but I noticed ble_gattc_disc_svc_by_uuid is
using the find api (ble_att_clt_tx_find_type_value) instead of a read api
(ble_att_clt_tx_read_group_type in the case of ble_gattc_disc_all_svcs)
Im trying to understand hci packets now to see what those differences are,
but in the mean time I thought Id post.
Thanks for the stack and for any thoughts.
Re: ble_gattc_disc_svc_by_uuid problems
Posted by Jacob Rosenthal <ja...@gmail.com>.
Yes that did it. And it looks like that patch is upstreamed in there. Sadly
looks like flash and ram grew a good bit and Im going to have to fight that
for a while again.
On Tue, Dec 27, 2016 at 10:02 PM, Christopher Collins <cc...@apache.org>
wrote:
> Hi Jacob,
>
> You will need to upgrade newt as well. You can do that as follows:
>
> cd $GOPATH &&
> git checkout develop &&
> git pull &&
> go install
>
> Hopefully that fixes the compile problem. Please report back if you
> encounter any issues.
>
> Thanks,
> Chris
>
>
> On Tue, Dec 27, 2016 at 04:40:34PM -0700, Jacob Rosenthal wrote:
> > Thanks for the quick replies. I changed to
> > repository.apache-mynewt-core:
> > type: github
> > vers: 0-latest
> > user: apache
> > repo: incubator-mynewt-core
> >
> > Jacobs-MacBook-Air:mynewt-hr-observer jacobrosenthal$ newt run
> > nrf51822xxaa_blecenthr 0.0.0
> > Compiling main.c
> > Compiling misc.c
> > Compiling peer.c
> > Archiving blecenthr.a
> > Error: In file included from aes.c:29:0:
> > /Users/jacobrosenthal/Downloads/mynewt-hr-observer/
> repos/apache-mynewt-core/
> > crypto/mbedtls/include/mbedtls/config.h:2522:10: error: #include expects
> > "FILENAME" or <FILENAME>
> > #include MBEDTLS_USER_CONFIG_FILE
> >
> >
> > Is upstream dev broken atm? or is there some quick config file fix? Or
> > whats another quick way to move to something other than latest? Id just
> > apply that one patch but looks like its based on a bunch of changes I
> dont
> > have in latest.
> >
> >
> > Hrm.. also I cant find that in the github mirror.. It was closed there
> not
> > merged, does that mean it was merged somewhere on the apache side?
> >
> > @Andrzej Kaczmarek Ah, I see that error in the logs, though it looks like
> > (this older) version of ble_gattc_disc_svc_by_uuid calls back (once)
> > to BLE_HS_EDONE,
> > even though the error exists. But who cares what this version does, out
> > with the old.
> >
> >
> >
> >
> >
> > On Tue, Dec 27, 2016 at 3:28 PM, Christopher Collins <
> ccollins@apache.org>
> > wrote:
> >
> > >
> > > Could you show the code you are using? I haven't noticed any issues
> > > with the discover primary services by UUID operation.
> > >
> > > > 2357:[ts=18414036ss
>
Re: ble_gattc_disc_svc_by_uuid problems
Posted by Christopher Collins <cc...@apache.org>.
Hi Jacob,
You will need to upgrade newt as well. You can do that as follows:
cd $GOPATH &&
git checkout develop &&
git pull &&
go install
Hopefully that fixes the compile problem. Please report back if you
encounter any issues.
Thanks,
Chris
On Tue, Dec 27, 2016 at 04:40:34PM -0700, Jacob Rosenthal wrote:
> Thanks for the quick replies. I changed to
> repository.apache-mynewt-core:
> type: github
> vers: 0-latest
> user: apache
> repo: incubator-mynewt-core
>
> Jacobs-MacBook-Air:mynewt-hr-observer jacobrosenthal$ newt run
> nrf51822xxaa_blecenthr 0.0.0
> Compiling main.c
> Compiling misc.c
> Compiling peer.c
> Archiving blecenthr.a
> Error: In file included from aes.c:29:0:
> /Users/jacobrosenthal/Downloads/mynewt-hr-observer/repos/apache-mynewt-core/
> crypto/mbedtls/include/mbedtls/config.h:2522:10: error: #include expects
> "FILENAME" or <FILENAME>
> #include MBEDTLS_USER_CONFIG_FILE
>
>
> Is upstream dev broken atm? or is there some quick config file fix? Or
> whats another quick way to move to something other than latest? Id just
> apply that one patch but looks like its based on a bunch of changes I dont
> have in latest.
>
>
> Hrm.. also I cant find that in the github mirror.. It was closed there not
> merged, does that mean it was merged somewhere on the apache side?
>
> @Andrzej Kaczmarek Ah, I see that error in the logs, though it looks like
> (this older) version of ble_gattc_disc_svc_by_uuid calls back (once)
> to BLE_HS_EDONE,
> even though the error exists. But who cares what this version does, out
> with the old.
>
>
>
>
>
> On Tue, Dec 27, 2016 at 3:28 PM, Christopher Collins <cc...@apache.org>
> wrote:
>
> >
> > Could you show the code you are using? I haven't noticed any issues
> > with the discover primary services by UUID operation.
> >
> > > 2357:[ts=18414036ss
Re: ble_gattc_disc_svc_by_uuid problems
Posted by Jacob Rosenthal <ja...@gmail.com>.
Thanks for the quick replies. I changed to
repository.apache-mynewt-core:
type: github
vers: 0-latest
user: apache
repo: incubator-mynewt-core
Jacobs-MacBook-Air:mynewt-hr-observer jacobrosenthal$ newt run
nrf51822xxaa_blecenthr 0.0.0
Compiling main.c
Compiling misc.c
Compiling peer.c
Archiving blecenthr.a
Error: In file included from aes.c:29:0:
/Users/jacobrosenthal/Downloads/mynewt-hr-observer/repos/apache-mynewt-core/
crypto/mbedtls/include/mbedtls/config.h:2522:10: error: #include expects
"FILENAME" or <FILENAME>
#include MBEDTLS_USER_CONFIG_FILE
Is upstream dev broken atm? or is there some quick config file fix? Or
whats another quick way to move to something other than latest? Id just
apply that one patch but looks like its based on a bunch of changes I dont
have in latest.
Hrm.. also I cant find that in the github mirror.. It was closed there not
merged, does that mean it was merged somewhere on the apache side?
@Andrzej Kaczmarek Ah, I see that error in the logs, though it looks like
(this older) version of ble_gattc_disc_svc_by_uuid calls back (once)
to BLE_HS_EDONE,
even though the error exists. But who cares what this version does, out
with the old.
On Tue, Dec 27, 2016 at 3:28 PM, Christopher Collins <cc...@apache.org>
wrote:
>
> Could you show the code you are using? I haven't noticed any issues
> with the discover primary services by UUID operation.
>
> > 2357:[ts=18414036ss
Re: ble_gattc_disc_svc_by_uuid problems
Posted by Christopher Collins <cc...@apache.org>.
Hi Jacob,
On Tue, Dec 27, 2016 at 02:37:01PM -0700, Jacob Rosenthal wrote:
> Hey all, been working with mynewt for a week or so now, trying to
> understand the code and slim the nimble stack down for nrf51822qfaa
> targets. Playing with central role now (modified blecent), and Im having
> some trouble searching for a single svc by uuid (to save peer struct
> memory, rather than indexing them all)
>
> Either I dont understand ble_gattc_disc_svc_by_uuid or it has problems.
>
> Its returning successfully but with a different uuid than I would expect
> and weird handles
Could you show the code you are using? I haven't noticed any issues
with the discover primary services by UUID operation.
> 2357:[ts=18414036ssb, mod=4 level=1] GATT procedure initiated: discover
> service by uuid; uuid=0000180d-0000-1000-800000805f9b34fb
> 2360:[ts=18437472ssb, mod=4 level=0] host tx hci data; handle=1 length=27
> 2361:[ts=18445284ssb, mod=4 level=0] ble_hs_hci_acl_tx(): 0x01 0x00 0x1b
> 0x00 0x17 0x00 0x04 0x00 0x06 0x01 0x00 0xff 0xff 0x00 0x28 0xfb 0x34 0x9b
> 0x5f 0x80 0x00 0x00 0x80 0x00 0x10 0x00 0x00 0x0d 0x18 0x00 0x00
> 2364:[ts=18468720ssb, mod=4 level=0] txed att command: find type value req;
> conn=1 start_handle=0x0001 end_handle=0xffff attr_type=10240
> 2372:[ts=18531216ssb, mod=4 level=0] Number of Completed Packets:
> num_handles=1
> 2374:[ts=18546840ssb, mod=4 level=0] handle:1 pkts:1
> 2379:[ts=18585900ssb, mod=4 level=0] ble_hs_hci_evt_acl_process(): handle=1
> pb=2 len=9 data=0x05 0x00 0x04 0x00 0x01 0x06 0x01 0x00 0x0a
> 2382:[ts=18609336ssb, mod=4 level=0] rxed att command: error rsp; conn=1
> req_op=6 handle=0x0001 error_code=10
> 2384:[ts=18624960ssb, mod=64 level=3] Service discovery complete; status=0
> conn_handle=1
It looks like the peer is reporting that it doesn't support the service
being requested (heart rate). The peer responds to the Find By Type
Value Request with an error response (status=10; attribute not found).
One thing to be careful about: be sure to check the status parameter in
your GATT callback. If the status is not zero, then the service data is
not valid. In this case, I would expect the status to be equal to 14
(BLE_HS_EDONE). I believe this explains why you are seeing weird
handle and UUID values.
The Discover Primary Service by UUID API is not obvious. The callback
may get called multiple times; the last time it gets called, the status
will be nonzero (BLE_HS_EDONE on successful completion). This probably
seems weird, since you are only trying to discover a single service.
The reason for the strange semantics is that a device is allowed to have
multiple services with the same UUID; this API is hampered to allow for
this obscure scenario.
Unfortunately, I'm not sure why the device is reporting that it doesn't
support that service. Is the peer a Mynewt device?
One thing that looks strange is that your device is trying to discover
the heart rate service's 128-bit UUID. If a UUID can be represented in
16 bits, then the Nimble host should specify the shorter UUID. This is
something that the host does automatically as long as the application
specifies the UUID correctly. From the log, the 128-bit UUID looks
correct, so I am not sure why all 128 bits are being transmitted.
This is just an optimization; the 128-bit UUID should work also. This
might be a clue, though.
[...]
> I dont know if its helpful, but I noticed ble_gattc_disc_svc_by_uuid is
> using the find api (ble_att_clt_tx_find_type_value) instead of a read api
> (ble_att_clt_tx_read_group_type in the case of ble_gattc_disc_all_svcs)
That is OK; the Discover Primary Service by Service UUID GATT procedure
uses the Find By Type Value Request ATT command. Section 3.G.4.4.2 in
the 4.2 spec contains a sequence diagram illustrating this (I just
mention this in case you are interested).
> Im trying to understand hci packets now to see what those differences are,
> but in the mean time I thought Id post.
>
> Thanks for the stack and for any thoughts.
If you don't mind sharing the code which calls
ble_gattc_disc_svc_by_uuid(), and also the callback, I would be happy to
take a look.
Thanks,
Chris
Re: ble_gattc_disc_svc_by_uuid problems
Posted by Andrzej Kaczmarek <an...@codecoup.pl>.
Hi Jacob,
On Tue, Dec 27, 2016 at 10:37 PM, Jacob Rosenthal <ja...@gmail.com>
wrote:
> Hey all, been working with mynewt for a week or so now, trying to
> understand the code and slim the nimble stack down for nrf51822qfaa
> targets. Playing with central role now (modified blecent), and Im having
> some trouble searching for a single svc by uuid (to save peer struct
> memory, rather than indexing them all)
>
> Either I dont understand ble_gattc_disc_svc_by_uuid or it has problems.
>
> Its returning successfully but with a different uuid than I would expect
> and weird handles
>
> 2357:[ts=18414036ssb, mod=4 level=1] GATT procedure initiated: discover
> service by uuid; uuid=0000180d-0000-1000-800000805f9b34fb
> 2360:[ts=18437472ssb, mod=4 level=0] host tx hci data; handle=1 length=27
> 2361:[ts=18445284ssb, mod=4 level=0] ble_hs_hci_acl_tx(): 0x01 0x00 0x1b
> 0x00 0x17 0x00 0x04 0x00 0x06 0x01 0x00 0xff 0xff 0x00 0x28 0xfb 0x34 0x9b
> 0x5f 0x80 0x00 0x00 0x80 0x00 0x10 0x00 0x00 0x0d 0x18 0x00 0x00
>
So here's the problem: UUID you're searching for is a 16-bit UUID (0x180d)
and it shall be transmitted this way in a request, i.e. it cannot be sent
as 128-bit UUID which is what Nimble does. This problem should be already
fixed on develop branch by this pull request: https://github.com/apache/
incubator-mynewt-core/pull/140 (commit a9968542).
> 2364:[ts=18468720ssb, mod=4 level=0] txed att command: find type value req;
> conn=1 start_handle=0x0001 end_handle=0xffff attr_type=10240
> 2372:[ts=18531216ssb, mod=4 level=0] Number of Completed Packets:
> num_handles=1
> 2374:[ts=18546840ssb, mod=4 level=0] handle:1 pkts:1
> 2379:[ts=18585900ssb, mod=4 level=0] ble_hs_hci_evt_acl_process(): handle=1
> pb=2 len=9 data=0x05 0x00 0x04 0x00 0x01 0x06 0x01 0x00 0x0a
> 2382:[ts=18609336ssb, mod=4 level=0] rxed att command: error rsp; conn=1
> req_op=6 handle=0x0001 error_code=10
>
Here you receive response with 0x0a code which means that attribute was not
found due to the above issue, which means your request did not return any
valid service. Invalid data you see below are most likely from invalid
NULL-pointer dereference.
> 2384:[ts=18624960ssb, mod=64 level=3] Service discovery complete; status=0
> conn_handle=1
>
>
> (gdb) p (peer->svcs)->slh_first->svc
> $4 = {
> start_handle = 16384,
> end_handle = 8192,
> uuid128 = "\365\r\000\000U\016\000\000U\016\000\000\000\000\000"
> }
> (gdb)
> b blecent_on_svc_disc_complete
> b blecent_on_chr_disc_complete
>
<snip>
BR,
Andrzej