PAN1026, unspecified TCU_ACCEPT command status 0x46

I have a developed a host application for PAN1026 SPP communication. After sending SPP data using TCU_SPP_DATA_TRANSFER_REQ_MESSAGE I normally get a TCU_ACCEPT event with a successfull status 0x00 as expected. Occasionally I get a TCU_ACCEPT with status of 0x46 which is not specified in the documentation, it only goes up to 0x44. What is this unknown status? 

Sam

6replies Oldest first
  • Oldest first
  • Newest first
  • Active threads
  • Popular
  • Hello Sam,

    can you please tell me which documentation you are referring to?

    Anyway, the return code 0x46 means "SPP data transfer in progress".

    Please note that data sending must be done in a specific way. First, the data must be send using TCU_SPP_DATA_TRANSFER_REQ and TCU_ACCEPT must be waited for, the return code should be 0x00.

    Next you must wait for the TCU_SPP_DATA_SEND_EVENT. This event indicates that the internal data processing has been completed and the next TCU_SPP_DATA_TRANSFER_REQ can be send.

    Please note that TCU_SPP_DATA_SEND_EVENT does not mean that the data has been actually send to the remote device, PAN1026 will buffer the data internally as well.

    The reason that you are getting the return code 0x46 probably means that you have not waited for TCU_SPP_DATA_SEND_EVENT correctly.

    Please check your sending logic carefully and make sure that you always wait for TCU_SPP_DATA_SEND_EVENT after using TCU_SPP_DATA_TRANSFER_REQ.

    Best regards

    Michael.

    Reply Like
  • Thanks Michael,

    I was refering to the doc 'PAN1026_TC35661APL_MNG_E_26thJuly_1.pdf' section 1.1.45 TCU_ACCEPT. In the Parameters table it doesn't list 0x46.

    Whilst I was waiting for the TCU_ACCEPT before using TCU_SPP_DATA_TRANSFER_REQ again, I wasn't handling the 0x46 and this was causing problems in my state machine.

    Also I wasn't waiting for TCU_SPP_DATA_SEND_EVENT, and what appears to be happening is that when I walk the two connected devices out of range, at a point I continue to get the TCU_ACCEPT, but not the TCU_SPP_DATA_SEND EVENT. Then after I send a TCU_SPP_DATA_TRANSFER_REQ , then next TCU_ACCEPT has a status of 0x46.


    Here's my log

    100000E54809000700FF0202020000FA TCU_SPP_DATA_RECEIVE_EVENT

    100000E50809000700FF0102020000FB TCU_SPP_DATA_SEND_EVENT

    0A0000E1F1030000E508 TCU_ACCEPT

    070000E5F10000 TCU_SPP_DATA_SEND EVENT

     

    100000E54809000700FF0202020000FA TCU_SPP_DATA_RECEIVE_EVENT

    100000E50809000700FF0102020000FB TCU_SPP_DATA_SEND_EVENT

    0A0000E1F1030000E508 TCU_ACCEPT

     

    100000E54809000700FF0204000000FA TCU_SPP_DATA_RECEIVE_EVENT

    100000E50809000700FF010400008972 TCU_SPP_DATA_SEND_EVENT

    0A0000E1F1030046E508 TCU_ACCEPT

     

    100000E54809000700FF0204040000F6 TCU_SPP_DATA_RECEIVE_EVENT

    100000E50809000700FF0104040000F7 TCU_SPP_DATA_SEND_EVENT

    0A0000E1F1030046E508 TCU_ACCEPT

    070000E5F10000 TCU_SPP_DATA_SEND EVENT

     

    0F0000E1470800007C8265464C6E01 TCU_MNG_CONNECTION_STATUS_EVENT

    0F0000E5440800007C8265464C6E02 TCU_SPP_DISCONNECT_EVENT

    Reply Like
  • Hello Sam,

    what your describe is entirely plausible. When your remote device gets out of range the messages will pile up inside PAN1026. When it cannot deliver the messages any more, you will receive an error 0x46 sooner or later.

    In any case you should wait for TCU_SPP_DATA_SEND EVENT in order to find out that a message has been delivered to your remote device.

    As you know the TCU command layer is a very low-level layer that directly communicates with the chip on the PAN1026 module.

    This puts the burden of special handling (for example the handling with TCU_SPP_DATA_SEND EVENT) entirely on the customer application.

    Luckily a more sophisticated API is included in the so-called "Bluetooth SDK" which gives you a nice C API to access the functionality of PAN1026 without having to worry about special handling and hand-crafting TCU messages.

    The direct usage of TCU commands is discouraged; the document that you have is outdated and is not updated any more.

    So I suggest to register using https://apps.toshiba.de/web/SDKRegistration/ and download and use the latest Bluetooth SDK v3.1 in your project.

    Best regards

    Michael.

    Reply Like
  • Hi Michael,

    I am getting a few more unspecified commands. This time it is a TCU_MNG_SPP_INFO_EVENT with unspecified Command OP codes 0x34 and 0x35:

    0F 00 00 E1 7D 08 00 34 06 E6 80 65 46 EA 32

    0F 00 00 E1 7D 08 00 35 06 E6 80 65 46 EA 32

    Can you please explain what these are?

    Reply Like
  • I meant TCU_MNG_SSP_INFO_EVENT.

    Reply Like
  • For PAN1026 these TCU_MNG_SSP_INFO_EVENTs directly resemble the events from the Bluetooth Core Specification.

    0x34 is the User Passkey Request Event.

    0x35 is the Remote OOB Data Request.

    If in doubt, please refer to the Bluetooth Core Specification for details about these events and how to handle them.

    In the Bluetooth Core Specification 4.2 the User Passkey Request Event can be found on page 1213 / 2772.

    The same is true for TCU_MNG_SSP_SET_REQ and TCU_MNG_SSP_SET_RESP which will just wrap the events as described in the Bluetooth Core Specification.

    Reply Like
reply to topic
Like Follow
  • Status Answered
  • 5 mths agoLast active
  • 6Replies
  • 809Views
  • 3 Following