- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I'm trying to get a notification service up & going. The App I've got is unreliable in it's ability to successfully sign up for, & receive notification data.
The code I've got so far receives a 10 byte packet from another µC every second. It then tries to push that data via a Vendor Specific Notification service created by the Smart Designer. The code doesn't request or enable security. ( /*.encr_required =*/ 0, //(SECURITY_ENABLED | SECURITY_REQUEST), // data encrypted and device sends security request on every connection)
Below is an annotated trace dump showing my App unsuccessfully signing up for notifications & then retrying resulting in success.
16:18:56 - | |
16:18:56 - Pckt(10):ba00 & 4a93 | Packet received by Broadcom from MSP, size 10 bytes. |
16:18:56 - timeout:29 | |
16:18:57 - | |
16:18:57 - Pckt(10):bb00 & 4a93 | |
16:18:57 - timeout:30 | |
16:18:58 - | |
16:18:58 - Pckt(10):bc00 & 4a93 | |
16:18:58 - timeout:31 | Broadcoms 1s timer |
16:18:59 - | |
16:18:59 - Pckt(10):bd00 & 4a93 | |
16:18:59 - timeout:32 | |
16:19:00 - | |
16:19:00 - Pckt(10):be00 & 4a93 | |
16:19:00 - timeout:33 | |
16:19:01 - | |
16:19:01 - Pckt(10):bf00 & 4a93 | |
16:19:01 - timeout:34 | |
16:19:02 - | |
16:19:02 - Pckt(10):c000 & 4a93 | |
16:19:02 - timeout:35 | |
16:19:03 - | |
16:19:03 - Pckt(10):c100 & 4a93 | |
16:19:03 - timeout:36 | |
16:19:04 - | |
16:19:04 - connection_up: 78a8735dd09b h=64 | First Connection since programming. |
16:19:04 Connection is UP. | |
16:19:04 profile idle timer stop | |
16:19:04 connUp | |
16:19:04 noAdv | |
16:19:04 noAdv | |
16:19:04 - Pckt(10):c200 & 4a93 | NB: because no other messages appear here the Broadcom is not attempting to send any data because no "bonded peer" has been located. |
16:19:04 - timeout:37 | |
16:19:05 - | |
16:19:05 - Pckt(10):c300 & 4a93 | |
16:19:05 - timeout:38 | |
16:19:06 - | |
16:19:06 - Pckt(10):c400 & 4a93 | |
16:19:06 - timeout:39 | |
16:19:07 - | |
16:19:07 - Pckt(10):c500 & 4a93 | |
16:19:07 - timeout:40 | |
16:19:08 - | |
16:19:08 - Pckt(10):c600 & 4a93 | |
16:19:08 - timeout:41 | |
16:19:09 - | |
16:19:09 - Pckt(10):c700 & 4a93 | |
16:19:09 - timeout:42 | |
16:19:10 - | |
16:19:10 - Pckt(10):c800 & 4a93 | |
16:19:10 - timeout:43 | |
16:19:11 - | |
16:19:11 - Pckt(10):c900 & 4a93 | |
16:19:11 - timeout:44 | |
16:19:12 - | |
16:19:12 - Pckt(10):ca00 & 4a93 | |
16:19:12 - timeout:45 | |
16:19:13 - | |
16:19:13 - Pckt(10):cb00 & 4a93 | |
16:19:13 - timeout:46 | |
16:19:14 - | |
16:19:14 - Pckt(10):cc00 & 4a93 | |
16:19:14 - timeout:47 | |
16:19:15 - | |
16:19:15 - Pckt(10):cd00 & 4a93 | |
16:19:15 - timeout:48 | |
16:19:16 - | |
16:19:16 - Pckt(10):ce00 & 4a93 | |
16:19:16 - timeout:49 | |
16:19:17 - | |
16:19:17 - Pckt(10):cf00 & 4a93 | |
16:19:17 - timeout:50 | |
16:19:18 - | |
16:19:18 - Pckt(10):d000 & 4a93 | |
16:19:18 - timeout:51 | |
16:19:19 - | |
16:19:19 - Pckt(10):d100 & 4a93 | |
16:19:19 - timeout:52 | |
16:19:20 - | |
16:19:20 - Pckt(10):d200 & 4a93 | |
16:19:20 - timeout:53 | |
16:19:21 - | |
16:19:21 - Pckt(10):d300 & 4a93 | |
16:19:21 smp timer started 00 | First attempt to sign up for Notifications. |
16:19:21 - timeout:54 | |
16:19:21 - | |
16:19:21 SMPTmrRef | |
16:19:21 SMPTmrRef | |
16:19:22 - encryption changed 78a8735dd09b | |
16:19:22 SMPTmrRef | |
16:19:22 SMPTmrRef | |
16:19:22 SMPTmrRef | |
16:19:22 SMPTmrRef | |
16:19:22 SMPTmrRef | |
16:19:22 SMPTmrStp | |
16:19:22 - Pckt(10):d400 & 4a93 | |
16:19:22 - smp_bond_result 03 | Successful bonding |
16:19:22 - NVRAM write:0018 | Writing Bonding data to non-volatile RAM on Broadcom. |
16:19:22 - timeout:55 | |
16:19:23 - | |
16:19:23 - Pckt(10):d500 & 4a93 | |
16:19:23 - don't notify handle:811 | (This is the extra message that we didn't see earlier) Now the notification function has located a "bonded peer" but as far as it knows that peer hasn't signed up for notifications. |
16:19:23 - don't notify handle:541 | |
16:19:23 - timeout:56 | |
16:19:24 - | |
16:19:24 - Pckt(10):d600 & 4a93 | |
16:19:24 - don't notify handle:811 | |
16:19:24 - don't notify handle:541 | |
16:19:24 - timeout:57 | |
16:19:25 - | |
16:19:25 - Pckt(10):d700 & 4a93 | |
16:19:25 - don't notify handle:811 | |
16:19:25 - don't notify handle:541 | |
16:19:25 - timeout:58 | |
16:19:26 - | |
16:19:26 - Pckt(10):d800 & 4a93 | |
16:19:26 - don't notify handle:811 | |
16:19:26 - don't notify handle:541 | |
16:19:26 - timeout:59 | |
16:19:27 - | |
16:19:27 - Pckt(10):d900 & 4a93 | |
16:19:27 - don't notify handle:811 | |
16:19:27 - don't notify handle:541 | |
16:19:27 - write_handler: handle 0550 | This is where the notifications checkbox, which is ticked from the first touch is pressed again unchecking the box, i.e. writing "0" to HDLD_ALERTS_CLIENT_CONFIGURATION (0550) |
16:19:27 - handle:550 val:0000 | |
16:19:27 - NVRAM write:0018 | |
16:19:27 WriteCb: handle 0000 | |
16:19:27 - timeout:60 | |
16:19:28 - | |
16:19:28 - Pckt(10):da00 & 4a93 | |
16:19:28 - don't notify handle:811 | |
16:19:28 - don't notify handle:541 | |
16:19:28 - timeout:61 | |
16:19:29 - | |
16:19:29 - Pckt(10):db00 & 4a93 | |
16:19:29 - don't notify handle:811 | |
16:19:29 - don't notify handle:541 | |
16:19:29 - timeout:62 | |
16:19:30 - | |
16:19:30 - write_handler: handle 0550 | 2nd attempt to sign up for notifications Now the notifications checkbox on the Broadcom is pressed again, "checking" the box, writing "1" |
16:19:30 - handle:550 val:0001 | |
16:19:30 - NVRAM write:0018 | |
16:19:30 WriteCb: handle 0000 | |
16:19:30 - Pckt(10):dc00 & 4a93 | |
16:19:30 - don't notify handle:811 | |
16:19:30 - notify len:10 handle:541 | Now that a bonded peer is found & that peer has signed up for notifications, data is sent reliably between connections & disconnections. |
16:19:30 - timeout:63 | |
16:19:31 - | |
16:19:31 - Pckt(10):dd00 & 4a93 | |
16:19:31 - don't notify handle:811 | |
16:19:31 - notify len:10 handle:541 | |
16:19:31 - timeout:64 | |
16:19:32 - | |
16:19:32 - Pckt(10):de00 & 4a93 | |
16:19:32 - don't notify handle:811 | |
16:19:32 - notify len:10 handle:541 | |
16:19:32 - timeout:65 | |
16:19:33 - | |
16:19:33 - Pckt(10):df00 & 4a93 | |
16:19:33 - don't notify handle:811 | |
16:19:33 - notify len:10 handle:541 | |
16:19:33 - timeout:66 | |
16:19:34 - | |
16:19:34 - Pckt(10):e000 & 4a93 | |
16:19:34 - don't notify handle:811 | |
16:19:34 - notify len:10 handle:541 | |
16:19:34 - timeout:67 | |
16:19:35 - | |
16:19:35 - Pckt(10):e100 & 4a93 | |
16:19:35 - don't notify handle:811 | |
16:19:35 - notify len:10 handle:541 | |
16:19:35 - timeout:68 | |
16:19:36 - | |
16:19:36 - Pckt(10):e200 & 4a93 | |
16:19:36 - don't notify handle:811 | |
16:19:36 - notify len:10 handle:541 | |
16:19:36 - timeout:69 | |
16:19:38 - | |
16:19:38 - Pckt(10):e300 & 4a93 | |
16:19:38 - don't notify handle:811 | |
16:19:38 - notify len:10 handle:541 | |
16:19:38 - timeout:70 |
So it looks like the first attempt to sign up for notifications from the app resulted in a lesmp_sendSecurityRequest(). Is this expected behaviour when encr_required = 0?
Solved! Go to Solution.
- Labels:
-
SDK 2.X
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I agree with boont that you should look at what hello_sensor app is doing. Hopefully it will give you some clue. By the way, the encr_required flag is not processed anyway by the stack. The variable is completely in your control and you can use it the way you want. Similarly it is up to you if you want to send lmp_sendSecurityRequest. You should do it if you want data to be encrypted. Alternatively you can just add appropriate permission to a characteristic. For example if you add LEGATTDB_PERM_AUTH_READABLE to a characteristic, when client tries to read it, the stack will return appropriate error code, the client will setup encryption and then try reading it again.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
i couldn't pinpoint why but i would refer to the hello-sensor app as a golden reference to check against your app.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I agree with boont that you should look at what hello_sensor app is doing. Hopefully it will give you some clue. By the way, the encr_required flag is not processed anyway by the stack. The variable is completely in your control and you can use it the way you want. Similarly it is up to you if you want to send lmp_sendSecurityRequest. You should do it if you want data to be encrypted. Alternatively you can just add appropriate permission to a characteristic. For example if you add LEGATTDB_PERM_AUTH_READABLE to a characteristic, when client tries to read it, the stack will return appropriate error code, the client will setup encryption and then try reading it again.