Pan1026 in dual mode. how to restart advertising as a BLE?

I am using PAN1026 in dual mode. It first advertise as a BLE and connect with mobile app then it disconnect and start scanning as a BT classic and connect with BLT classic device and after completing task it disconnect.

Now I have to start this cycle again and again.

First I just start advertising again then also setup BLE again after that deinit spp and again init BT and BLE api and then advertise but its not working.

How can I readvertise as a BLE??

11replies Oldest first
  • Oldest first
  • Newest first
  • Active threads
  • Popular
  • Hello Ansics,

    in general BLE advertising and Bluetooth Scanning can work both at the same time.

    After a BLE disconnect, however, BLE advertising is not automatically started again, so you always have to restart advertising manually.

    How you do this depends on the environment you use. I can help you more in more detail if you share some informations about your system.

    Which host processor are you using, with Bluetooth SDK, etc.

    Best regards.

  • I am using SDK version 3.2 with IAR.

    yes I m using ble_api_peripheral_role_start function again after scanning. but device doesn't appears.

    I am using Toshiba TMPM369 with following development board.


    I also tried to reset it but no effect on it.

  • I am also having this issue.

    Why is this topic marked as "Answered" when the OP still has the problem??

  • Hi,

    after a disconnect has happened and ble_application_mng_disconnect_callback() has been received, ble_api_peripheral_role_start() can be called again to start the advertising again.

    If this is not working for you, please share more information about your setup, like if the initial advertising is working, if you were able to establish a connection at least once, the return code of ble_api_peripheral_role_start() if there was an error and if everything does not give a hint, maybe a dump of the raw UART command that shows the unsuccessful start of the advertising.

    Best regards


  • Thanks for the quick reply, Michael.

    My situation is similar to OP's, but I am not actually connecting to a BT classic device after disconnecting from BLE.  However, I have the same issue with not being able to see the BLE advertisement in scans after disconnecting. The first BLE connection is successful.

    I tried your suggestion of calling ble_api_peripheral_role_start() after the ble_application_mng_disconnect_callback() is invoked.  This returned a status of 0 (success).  However, I never receive a ble_application_slave_advertising_status_update_callback() afterwards and still cannot detect the device in scans. Do you know why the advertising start response never fires?



    EDIT:  It appears that ble_api_peripheral_role_start() will always return LE_API_SUCCESS (so long as gap_state_info.gap_state == GAP_IDLE).  So that doesn't actually tell us much.

  • I also tried doing a stop/start of advertising, but do not receive a response to calling ble_api_peripheral_role_stop() either.

  • I found a bug in the SDK!  For TC35661-501, there is apparently a need to send a request to reset SMP flags after a disconnect occurs (see ble_api_common_501.c, function loc_mem_write()). The problem with this is that this message uses the same outgoing TCU module buffer that the ble_api_peripheral_role_start() request uses later in the application's disconnect callback.  See tcu_internal.c, function tcu_handle_circular_buff_memory().  Both TCU_BT_SERVICE_MNG and TCU_BLE_SERVICE_MNG requests use the tcu_gap_buff.  When the first request's response is received, this buffer is cleared, thus clearing part of the second request.

    I addressed this conflict by allocating & using a separate buffer for TCU_BT_SERVICE_MNG frames.  I can now call ble_api_peripheral_role_start() immediately within the disconnect callback and advertising starts again properly.  Another approach would be to wait for the loc_mem_write response to be received before re-starting advertising.

    I've attached my changes to the SDK files that implement this fix.

  • Thank you very much for your investigations.

    Can you please tell me the SDK version these changes are based on?

    I will try to replicate your results, verify the fix and then forward it to Toshiba.

    Please note that there is a national holiday tomorrow and most people have a day off on Friday.

  • Michael,

    I am using SDK version 3.4.1.



  • I am sorry for the delay.

    I just want to let you know that I forwarded your request to the Toshiba engineering team and they are looking into this issue.

  • It seems likely that the solution suggested here would also address this issue.

Like Follow
  • Status Answered
  • 2 yrs agoLast active
  • 11Replies
  • 740Views
  • 4 Following