Key/encryption events not received from PAN1026 while bonding

I am working to integrate the Toshiba Bluetooth SDK into a product that utilizes the PAN1026.  During bonding, I see the paring process complete on the other device, but fail to receive expected events from the PAN1026.

For debugging, I am attempting to pair with a laptop in order to run Wireshark for visibility into the BLE communication.  The application connected to the PAN1026 provides a service as a slave with authentication mode SMP_AUTH_BONDING_ENABLED_NO_MITM and input-output capabilities TCU_MNG_NO_INPUT_NO_OUTPUT.

When I attempt a BLE connection to the PAN1026, I see a pairing request on the master (laptop).  I observe that the slave application receives and responds to PAIRING_REQUEST and PAIRING_ACCEPT from the PAN1026 as expected.  Ultimately my application receives TCU_LE_SMP_SLV_ENCRYPTION_CHANGE_EVENT from the PAN1026 indicating a status of success.  After the encryption change event, my application receives no further messages related to the pairing process.  Eventually, the slave application will receive a disconnection event from the PAN1026 when the master disconnects.

On the master (laptop), with Wireshark, I see all of the above progressing (pairing request/accept, encryption change).  I also see the entire pairing process complete, including the exchange of keys and encryption parameters.

In the PAN1026 documentation there is an SMP Message Sequence Chart (PAN1026_TC35661APL_ROM501_SMP_MSC_E_3rdOctober2013.pdf).  I see from this diagram that, after the PAN1026 sends TCU_LE_SMP_SLV_ENCRYPTION_CHANGE_EVENT, it should eventually send the following events, without any further commands from the application, assuming pairing continues as expected with the other device:

  TCU_LE_SMP_SLV_LTK_SENT_EVENT
  TCU_LE_SMP_SLV_EDIV_RAND_SENT_EVENT
  TCU_LE_SMP_SLV_LTK_RECEIVED_EVENT
  TCU_LE_SMP_SLV_EDIV_RAND_RECEIVED_EVENT
  TCU_LE_SMP_SLV_PAIRING_COMPLETED_EVENT
  TCU_LE_SMP_SLV_STORE_KEY_EVENT

Is there any reason why the PAN1026 would fail to send those events to the application?  It appears that the PAN1026 is exchanging keys with the master as expected, based on my observations with Wireshark on the master.

If you have any insight into this issue or any recommendations on where I should look, that would be appreciated.  Thank you.

3replies Oldest first
  • Oldest first
  • Newest first
  • Active threads
  • Popular
  • Please share the raw TCU events and TCU requests / responses.

    Like
  • Generating a trace of TCU events and requests/responses is somewhat difficult in my application due to resource constraints of the application processor.

    While implementing a mechanism to generate such a trace, I discovered the cause of this issue.  In certain cases, CTS was deasserted for a considerable amount of time, presumably causing the PAN1026 to drop older events or responses as new ones were
    generated.  This was not detected as UART overrun on my application processor because the PAN1026 never tried to send the events at all, due to CTS deasserted.  Clearly this is an issue in my application, which I will address.

    Is there any way to detect when or how many such events or responses are dropped by the PAN1026?  I also notice that the Toshiba Bluetooth SDK disables hardware handshaking for all examples.  Is that simply due to limitations of the hardware used for those examples, or is it recommended to avoid using hardware flow control for some reason?

    Like
  • Clearly this is an issue in my application, which I will address.

    I am glad to hear that you found this and thank you for sharing this information.

    Is there any way to detect when or how many such events or responses are dropped by the PAN1026?

    No, there is no way to find that out. To be honest it is unknown how PAN1026 exactly behaves when it is not able to send to the host for longer periods of time, i.e. if events will pile up (they certainly will to a certain extend) and what then happens later. This falls into the category of simply don't do this.

    I also notice that the Toshiba Bluetooth SDK disables hardware handshaking for all examples.  Is that simply due to limitations of the hardware used for those examples

    Hm, you are right about this. I don't know the exact reasons why this is done.

    Or is it recommended to avoid using hardware flow control for some reason?

    No, it is not recommended to disable hardware flow control.

    For newer modules like the PAN1760A Panasonic provides a Software Guide package with examples for the cable replacement use-case and all these demos have hardware flow control enabled as well.

    So it is definitely worked on PAN1026(A) as well and it is definitely recommended.

    I will mark this issue as answered. If you have more questions regarding this topic, feel free to add it. For any new question please open a new topic.

    Like
Like Follow
  • Status Answered
  • 1 yr agoLast active
  • 3Replies
  • 128Views
  • 3 Following