You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@mynewt.apache.org by GitBox <gi...@apache.org> on 2020/05/27 07:47:17 UTC

[GitHub] [mynewt-nimble] deepthits opened a new issue #823: Events BLE_GAP_EVENT_DISC_COMPLETE and BLE_GAP_EVENT_ADV_COMPLETE are not received

deepthits opened a new issue #823:
URL: https://github.com/apache/mynewt-nimble/issues/823


   We have integrated nimBLE stack over Linux npl porting. nimble_port_init() and nimble_port_run() are rightly called to initialize the nimBLE stack and to process the ble_npl_event events.
   
   ble_gap_disc() and ble_gap_adv_start() are called with '**duration_ms**' parameter set to non-zero values. So, it is expected that BLE_GAP_EVENT_DISC_COMPLETE and BLE_GAP_EVENT_ADV_COMPLETE events are received after the '**duration_ms**' time elapses. But that doesn't happen and scanning/advertising goes on forever, as if '**duration_ms**' was set to BLE_HS_FOREVER.
   
   When I debugged further I understood that when ble_gap_slave_set_timer() or ble_gap_master_set_timer() is set it would just trigger a timer reset of **1 tick**  so immediately there would be a timer expiry and in the timer handler, the actual '**duration_ticks - 1**' would be set in ble_hs_timer_sched(). But, the following condition check seem to have an issue,
   
   if (!ble_npl_callout_is_active(&ble_hs_timer) ||
               ((ble_npl_stime_t)(abs_time -
                                  ble_npl_callout_get_ticks(&ble_hs_timer))) < 0) {
           ble_hs_timer_reset(ticks_from_now);
   
   ble_npl_callout_is_active() this is always **true** and (abs_time -                              ble_npl_callout_get_ticks(&ble_hs_timer))) **is always greater than 0**. Since, it has just triggered an expiry, the ble_npl_callout_get_ticks() returns the current value which will always be less than abs_time. So, timer is never reset to the correct **duration_ticks**.
   
   I checked the same scenario in btshell where the **mynewt npl** layer is used. Here,  the ble_npl_callout_is_active() is always **false**. So the condition turns to be true and timer is reset successfully. 
   
   So, this seems to be an issue in linux npl layer.
   


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



[GitHub] [mynewt-nimble] deepthits commented on issue #823: Events BLE_GAP_EVENT_DISC_COMPLETE and BLE_GAP_EVENT_ADV_COMPLETE are not received

Posted by GitBox <gi...@apache.org>.
deepthits commented on issue #823:
URL: https://github.com/apache/mynewt-nimble/issues/823#issuecomment-637545915


   bool ble_npl_callout_is_active(struct ble_npl_callout *c)
   {
       // TODO: seek native posix method to determine whether timer_t is active.
       // TODO: fix bug where one-shot timer is still active after fired.
       return c->c_active;
   }


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



[GitHub] [mynewt-nimble] deepthits edited a comment on issue #823: Events BLE_GAP_EVENT_DISC_COMPLETE and BLE_GAP_EVENT_ADV_COMPLETE are not received

Posted by GitBox <gi...@apache.org>.
deepthits edited a comment on issue #823:
URL: https://github.com/apache/mynewt-nimble/issues/823#issuecomment-637545915


   bool ble_npl_callout_is_active(struct ble_npl_callout *c)
   {
       **// TODO: seek native posix method to determine whether timer_t is active.
       // TODO: fix bug where one-shot timer is still active after fired.**
       return c->c_active;
   }
   
   I see the above comment, which means this is a known bug, so is there a solution already identified or is it being planned?
   
   In addition to the above issues wrt to Discovery and Advertising, I see another one which seem to be very crucial. In a particular usecase I am trying to connect to a device by sending ble_gap_connect(), if the device doesnt respond after 30s (default connection duration) it is suppose to timeout, but it doesnt. It tries to connect forever. This is a crucial one for us. Can someone help in resolving this one?


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org