1 of 1 people found this helpful
Any problems in the code are almost certainly stemming from step 5 above.
By calling bleprofile_Discoverable to start directed advertisements, the stack starts a timer based on the specified BLE_PROFILE_CFG table (see image below). In this table you specify high and low intervals for your advertisements and for what durations to transmit them. The timer takes over and starts high interval advertisements for the specified duration and when those are complete, a timer callback starts low interval directed advertisements for the specified duration. When low intervals are complete, an advertisement stopped callback fires and the radio stops advertising.
With that said, calling bleprofile_Discoverable(HIGH_DIRECETD_DISCOVERABLE, my_addr) is all that is necessary to implement directed advertising. That is, steps 5-3 through 5-5 are unnecessary. just be sure to properly set your intervals and duration in the configuration table.
By using low level functions blecm_setAdvEnable and blecm_setAdvParam you are in direct conflict with what the stack is doing. So when you manually override what you have set in bleprofile_Discoverable using these other blecm function, the timers from bleprofile_Discoverable are still set, and when they fire will change the interval to whatever you told it to in the configuration table.
Thanks for the support.
Regarding the step 3. "The connecting device disconnects without sending Confirm", if BCM20736 successfully receives the confirmation, the transition to high -> low interval does not occur. Is this a expected behavior?
No, whether or not the client device sends an indication received ACK, this should not affect your advertising state.
Does this happen when you started advertisements using only bleprofile_Discoverable and not any of the other low-level functions? Or is this still including blecm_setAdvParam, and blecm_setAdvEnable?