Disconnect does not work on PAN 1026

Hello,

I am working on PAN1026 using SDK version 2.04. I have implemented disconnect on PAN1026 using 

enum ble_api_result ble_api_srv_disconnect(const struct ble_api_srv_profile *profile);

But sometimes it does not work and returns following status

LE_API_ERROR.

Can you please help me?

Is there any alternative that SDK provides for performing disconnect from PAN1026?

I will be really thankful to you.

Regards

19replies Oldest first
  • Oldest first
  • Newest first
  • Active threads
  • Popular
  • I have debugged and found that in the following function

    check_tcu_le_accept(uint32_t event)

    it always goes to 

    if (accept.le_accept_status != LE_SUCCESS) {
        bs_printf("invalid status %02x @ TCU_LE_ACCEPT\n", accept.le_accept_status);
        return LE_API_ERROR;
      }
    

    accept.le_accept_status == LE_MNG_PROCESSING
    I am using a dedicated ble characteristic for performing a disconnect. When android application writes a value to the characteristic PAN1026 should perform disconnect.
     

    Like
  • Can you please help me what is meaning of LE_MNG_PROCESSING status?

    Is it indicates that SDK is already processing some event? How I can forcefully stop them if it is doing some other processing?

    As the disconnect should have high priority than any other event.

    I have also experienced that during data transfer (via indication/notification) disconnect does not work at all.

    Like
  • Any help regarding this issue?

    Like
  • I have used the following function of the SDK for performing disconnect: 

    enum ble_api_result disconnect(uint8_t *bd_addr)

    But inside the following function.
     

    enum tcu_func_status TcuLeAccept(uint8_t *data, struct tcu_le_accept *event)
    {
      enum tcu_func_status status;
      uint16_t offset = CMD_ARRAY_PARAM_OFFS;
    
      /* Check if received command is matching */
      status = is_cmd_matching(data, TCU_LE_ACCEPT);
    
      if (TCU_FUNC_SUCCESS == status) {
        event->le_accept_status = (enum tcu_mng_le_accept_status)data[offset++];
        offset++;
        event->service_id = data[offset++];
        event->opcode = data[offset++];
        tcu_application_log_response(data, "TCU_LE_ACCEPT", "le_accept_status %d|service_id %d|opcode %d", event->le_accept_status, event->service_id, event->opcode);
      }
    
      return status;
    }

    event->le_accept_status always have value LE_MNG_PROCESSING = 0x04.

    Once this error comes and I try to perform disconnect, it always gives this status. It never performs disconnect even after several tries.

    Please help me to figure it out. 
    Is there any way to reset it once it occurs? So that in the next try it can perform disconnect.
     

    Like
  • As you know the Bluetooth SDK is callback-driven and I think this is making problems here.

    The usual application flow is that you receive data from the UART and call into the Bluetooth SDK from within your mainloop, so that the Bluetooth SDK can do the necessary processing.

    Now the Bluetooth SDK may do a callback into your code and provide some information to you. You may do some processing, but when your function returns, the Bluetooth SDK will continue to run and return to your mainloop later.

    The problem is that technically the Bluetooth SDK is still doing some processing when it calls your callback and that it may not be allowed to issue a new request to the Bluetooth SDK.

    For some callbacks it is ok to issue a new call to some functions of the Bluetooth SDK, for some it isn't.

    I think here the problem is that the Bluetooth SDK disconnect function cannot be called from the callback function that you are using.

    In general the correct solution for any callback processing handling is to store the information from the callback function and process it in the mainloop instead.

    So in your callback function simply note down (for example in a variable) that a disconnect is necessary, but return from the function. When the Bluetooth SDK returns to your mainloop, check the status of the variable and if necessary, call the disconnect function from the Bluetooth SDK.

    Like
  • Michael Hunold Thanks for your suggestion.

    Most of the time disconnect works. I am calling disconnect when a value is written on a characteristic.

    SDK gives callback for the write request and I call the disconnect function in that callback. After calling the disconnect, the write callback function is left by returning LE_GATT_STATUS_SUCCESS.

    PAN1024 does not send write_response in this case (as it already performed disconnect).
    Sometimes it never performs disconnect and sends write_response.

    I will try what you have suggested and will let you know the finding.

    Thanks again for your kind help.

    Regards.

    Like
  • Michael Hunold

    Is there any API function in SDK that gives information if SDK is busy/free to perform any request?

    I am thinking to send a disconnect when SDK is free and it can accept the disconnect.

    I will be waiting for your kind reply.

    Regards 

    Like
  • Michael Hunold said:
    So in your callback function simply note down (for example in a variable) that a disconnect is necessary, but return from the function. When the Bluetooth SDK returns to your mainloop, check the status of the variable and if necessary, call the disconnect function from the Bluetooth SDK.

    I have set a boolean variable on write request and then I am performing disconnect in the main loop by checking the value of the variable.

    It looks disconnect is now better before it was occurring very often.

    But still, the problem exists, I was tested on Pixels2 device and PAN1026 did not perform disconnect.

    The big problem is when disconnect fails, it never gets successful. Even after closing the android app (that breaks the connection) I reconnect then I tried to perform disconnect from PAN1026 but it was not working

    Unfortunately, to make it work again I have to restart the whole system which is not an affordable option for us.

    Can you please tell me when I should send the disconnect to make 100% that it will work?

    Is there any other possible solution to that

    It is really an important issue for us.

    I will be waiting for your kind reply.

    Like
  • So before the problem was happening very often before and now after the change it is happening less often? Is this correct?

    How do you notice that the disconnect request was not successful?

    Did you receive the corresponding disconnect callback function on your host controller?

    Do you receive any feedback on your mobile phone side? Which app are you using to communication to PAN1026?

    There are different sources of possible errors here.

    In order to find out if the disconnect request leaves PAN1026 a capture log from a Bluetooth Low Energy sniffer would be great.

    Alternatively a full log of the UART communication between your device and PAN1026 when this problem occurs would help for further analysis.

    You can attach text files to this communication easily.

    Like
  • Michael Hunold said:
    So before the problem was happening very often before and now after the change it is happening less often? Is this correct?

     Yes, it is correct.

     

    Michael Hunold said:
    How do you notice that the disconnect request was not successful?

     Yes, I can see on BLE sniffer and on my android device also UART logs of PAN1026.

    Michael Hunold said:
    Did you receive the corresponding disconnect callback function on your host controller?

     No, I am not getting disconnect callback.

    Michael Hunold said:
    Do you receive any feedback on your mobile phone side? Which app are you using to communication to PAN1026?

     No, I am not getting any feedback on the mobile side. We have developed our own app for testing. But I also tested with the nrf_connect app and BLE scanner.

    Currently, I am trying to perform a disconnect when ble_api_event_handler  will return success.

    if it will not work then I will provide you logs when the problem will occur.

    Thanks for your help.
     

    Like
  • Michael Hunold

    Following are logs from UART:

    tcu_le_gatt_ser_write_char_val_event_handler(): 
    TCU_LE_GATT_SER_WRITE_CHAR_VAL_EVENT: 
    TCU_LE_GATT_SDB_UPD_CHAR_ELE_REQ: 
    TCU_LE_GATT_SDB_UPD_CHAR_ELE_RESP: status 0
    TCU_LE_GATT_SER_WRITE_CHAR_VAL_ACCEPT_REQ: 
    TCU_LE_GATT_SER_WRITE_CHAR_VAL_ACCEPT_RESP: gatt_status 0|connection_handle 1 
    BLE: ble_comm_disconnect -- Performing disconnect
    disconnect(): 
    TCU_MNG_LE_DISCONNECT_REQ: 
    TCU_LE_ACCEPT: le_accept_status 4|service_id 209|opcode 19
    check_tcu_le_accept(): invalid status 04 @ TCU_LE_ACCEPT
    disconnect(): check_tcu_le_accept() @ TCU_MNG_LE_DISCONNECT_REQ failed
    ble_api_srv_disconnect(): disconnect() failed


    Can you please have a look?

    Like
  • Michael Hunold

    Following are the logs from the UART:

    tcu_le_gatt_ser_write_char_val_event_handler(): 
    TCU_LE_GATT_SER_WRITE_CHAR_VAL_EVENT: 
    TCU_LE_GATT_SDB_UPD_CHAR_ELE_REQ: 
    TCU_LE_GATT_SDB_UPD_CHAR_ELE_RESP: status 0
    TCU_LE_GATT_SER_WRITE_CHAR_VAL_ACCEPT_REQ: 
    TCU_LE_GATT_SER_WRITE_CHAR_VAL_ACCEPT_RESP: gatt_status 0|connection_handle 1 
    disconnect(): 
    TCU_MNG_LE_DISCONNECT_REQ: 
    TCU_LE_ACCEPT: le_accept_status 0|service_id 209|opcode 19
    tcu_receive_any_message(): uart_application_receive_receive_bytes() @ msg_len failed
    tcu_wait_for_specific_event(): tcu_receive_any_message() failed
    disconnect(): tcu_wait_for_specific_event() failed
    ble_api_srv_disconnect(): disconnect() failed
    BLE: Disconnect failed, ble_api_srv_disconnect returned 1

    Once I get the above-mentioned logs from SDK, it never performs disconnect. From the above-shown logs, it looks that there is some problem in UART module. Is it correct?

    After getting the above-mentioned logs when i try to perform a disconnect,
    it always gives the following logs

    TCU_MNG_LE_DISCONNECT_REQ: 
    TCU_LE_ACCEPT: le_accept_status 4|service_id 209|opcode 19
    check_tcu_le_accept(): invalid status 04 @ TCU_LE_ACCEPT
    disconnect(): check_tcu_le_accept() @ TCU_MNG_LE_DISCONNECT_REQ failed
    ble_api_srv_disconnect(): disconnect() failed

    I have also attached a file with complete logs.

    Can you please have a look and suggest any possible solution?
     

    I will be waiting for your kind reply.
     

    Like
  • Michael Hunold

    Today I have done some debugging and I came to know that the UART is getting timeout while waiting for check_tcu_le_accept when a disconnect is performed.

    In the function check_tcu_le_accept(uint32_t event) the following is returing non zero value.

      ret = tcu_wait_for_specific_event(GET_CMD_SERVICE_ID(TCU_LE_ACCEPT), GET_CMD_OPCODE(TCU_LE_ACCEPT), TCU_MNG_LE_DEFAULT_CMD_TIMEOUT, tcu_buffer, tcu_buffer_len);
      if (ret) {
        bs_printf("tcu_wait_for_specific_event() failed\n");
        return LE_API_ERR_DRV;
      }
    
    

    That means the UART is getting a timeout.
    I am wondering when UART gets timeout after that why PAN1026 never accepts the disconnect request and always return the following status

    check_tcu_le_accept(): invalid status 04 @ TCU_LE_ACCEPT

    Would it be possible to somehow reset the buffer (that stores the UART data) ? or can i increase the timeout value so that it can wait for a little longer?

    Or there any other way to overcome the problem?

    I will be waiting for your kind reply.

    Like
  • Michael Hunold

    As you can see in the attached logs

    TCU_MNG_LE_DISCONNECT_EVENT: connection_handle 0x0001|status 0x00|reason 0x22

    Reason 0x22 = BT_HCI_ERR_LL_RESP_TIMEOUT

    That means the HCI is getting a timeout.
    Then why it never accepts the disconnect anymore after a timeout?.

    Is it intended behavior that it should not accept any disconnect request and always return status LE_MNG_PROCESSING?

    What I should do if BT_HCI_ERR_LL_RESP_TIMEOUT  error occurs??

    Like
  • I have also attached a file with complete logs.

    Thank you very much, this is very helpful.

    From the above-shown logs, it looks that there is some problem in UART module.

    No, I think the UART communication is working fine, because you receive the disconnect event after the disconnect command has failed.

    Is it intended behavior that it should not accept any disconnect request and always return status LE_MNG_PROCESSING?

    That is a very good question.

    At this point I'd like to forward your problem to the Toshiba support people, because it looks like some handling gets screwed up.

    However, you are using a very old version of the Toshiba Bluetooth SDK.

    Probably the first proposal will be to update to a newer version of the SDK.

    The main reason is that for older devices with known problems, workarounds and bugfixes are executed by the Toshiba Bluetooth SDK automatically. The Bluetooth SDK contains fixes and special handling for TC35661-501 which is used in PAN1026.

    So I hate to say it, but please update to the newest version of the Bluetooth SDK and try to reproduce the problem.

    Like
  • Thank you for your reply.

    Michael Hunold said:
    At this point I'd like to forward your problem to the Toshiba support people, because it looks like some handling gets screwed up.

     How long it will take to investigate the issue?

    Michael Hunold said:
    Probably the first proposal will be to update to a newer version of the SDK.

     I will try with SDK version BT_SDK_v_4_2_0 and see if it is still occurring.

    Thanks a lot. 

    Like
  • Michael Hunold 

    Any response from Toshiba support team about the issue?
    This is a very priority task.

    I tried to use SDK 4.2.1 but looks nightmare to get it properly working with PAN1026.

    It will be really nice if we get the solution for the current version.

    Like
  • Please contact Panasonic via wireless@eu.panasonic.com so we can support you better.

    Like
  • I tried to use SDK 4.2.1 but looks nightmare to get it properly working with PAN1026.

    Please see my other reply. PAN1026 is working fine with SDK 4.2.1.

    It will be really nice if we get the solution for the current version.

    I can understand your desire, but I am afraid that the SDK version 2.0.4 is simply too old to support.

    Any response from Toshiba support team about the issue?

    I did not forward your request yet, because the problem must be reproducible on one of the more recent SDK versions.

    So I took the BMSKTOPASM369BT(kc) evaluation platform for PAN1026 and used the project from software\host_mode_deployment\projects\TMPM369BT\TC35661_501\project.eww and tried to replicate your use-case.

    The sample application supports disconnect via a command that is triggered by the on-board joystick and is executed in the main loop.

    This disconnect worked fine, advertising can be started again and the remote device can connect again.

    I also integrated a call to ble_api_disconnect() directly into the spp_over_ble_receive_callback() function, so that whenever something is received from the remote device, a disconnect is executed immediately during Bluetooth processing.

    This disconnect  also worked fine, advertising can be started again and the remote device can connect again.

    So from that perspective it looks like your use case can be implemented successfully with PAN1026 using the Bluetooth SDK 4.2.1.

    I am afraid that there is some different kind of error in your application that prevents this from working on your side.

    Like
Like1 Follow
  • 1 Likes
  • 11 mths agoLast active
  • 19Replies
  • 104Views
  • 4 Following