What if there is no TCU_SPP_DATA_SEND_EVENT?

We have a mobile headset device using PAN1026 passing via SPP around 15KB of data per second to a PC USB device, with PAN1026 also. RF patches are applied to both, both running essentially same BT firmware although one on MSP430, other on ARM7.

For the intended use, it is critical that we have this constant flow of data. While the distance between devices is around 2-3 meters, all is well and we have good transmission for 10h+ without connection breaks and limited data loss.

Typically we send a 59 byte package every 4ms with TCU_SPP_DATA_TRANSFER_REQ and wait for the TCU_ACCEPT, then TCU_SPP_DATA_SEND_EVENT. If the TCU_SPP_DATA_SEND_EVENT is not received until 4ms expire, we join packages (e.g. to 2*59=118 bytes) for the next TCU_SPP_DATA_TRANSFER_REQ.

The log might look like this:

<-- TCU_SPP_DATA_TRANSFER_REQ  [68 bytes] :  44 00 00 E5 08 3D 00 3B 00 56 55 3B 5B 00 A7 01 90 00 28 00 F8 FF 02 00 DB FF 04 00 E3 FE 3F FF ... 4D 01 90 01 72 01 41 01 88 00 8A 01 51 01 74 01 25 FE 35 01 4A 01 49 01 D6 94 78 F7 88 83 00 F4 
--> TCU_ACCEPT  [10 bytes] :  0A 00 00 E1 F1 03 00 00 E5 08 
--> TCU_SPP_DATA_SEND_EVENT  [7 bytes] :  07 00 00 E5 F1 00 00 
<-- TCU_SPP_DATA_TRANSFER_REQ  [127 bytes] :  7F 00 00 E5 08 78 00 76 00 56 55 3C 4E 00 78 01 75 00 1D 00 FB FF FD FF D6 FF FD FF D0 FE 30 FF ... 4A FF AB FF 7E FF 33 FF 0B FE 7D 00 4A 00 6A 00 A4 FC EC FF 63 00 42 00 D6 94 78 F7 8A 83 EA C1 
--> TCU_ACCEPT  [10 bytes] :  0A 00 00 E1 F1 03 00 00 E5 08 
--> TCU_SPP_DATA_SEND_EVENT  [7 bytes] :  07 00 00 E5 F1 00 00 

 

But, if the distance is raised to 4-5m we very often run into problems, although both devices are stationary and within sight. Same happens when mobile headset moves, even at shorter distances. We might experience BT connection loss once per hour or more often on some devices.

In better cases we will receive the TCU_SPP_DISCONNECT_EVENT  event:

 <-- TCU_SPP_DATA_TRANSFER_REQ  [363 bytes] :  6B 01 00 E5 08 64 01 62 01 56 55 34 24 00 F6 FF 25 00 2B 00 18 00 B5 FF C0 FF C1 FF FF 00 56 00 ... 23 F9 28 F9 49 F9 3D F9 05 F8 17 F9 60 F9 61 F9 19 FF 02 F9 4F F9 2E F9 BF B8 F6 F1 21 F3 00 84 
--> TCU_ACCEPT  [10 bytes] :  0A 00 00 E1 F1 03 00 46 E5 08 
--> TCU_MNG_CONNECTION_STATUS_EVENT  [15 bytes] :  0F 00 00 E1 47 08 00 00 00 13 43 50 02 90 01 
--> TCU_SPP_DATA_SEND_EVENT  [7 bytes] :  07 00 00 E5 F1 00 00 
--> TCU_SPP_DISCONNECT_EVENT  [15 bytes] :  0F 00 00 E5 44 08 00 00 00 13 43 50 02 90 04 

 

But, what is troubling is that we very often miss the TCU_SPP_DATA_SEND_EVENT:

<-- TCU_SPP_DATA_TRANSFER_REQ  [127 bytes] :  7F 00 00 E5 08 78 00 76 00 56 55 3C 06 00 58 01 99 00 EF FF DE FF 71 00 13 00 6D 00 67 FF 6E FF ... 82 F8 31 F8 39 F8 56 F8 6F F8 ED F6 0F F7 CA F6 7B 02 10 F7 D6 F6 E9 F6 BE BC F6 F1 7E D2 08 10 
--> TCU_ACCEPT  [10 bytes] :  0A 00 00 E1 F1 03 00 00 E5 08 
--> TCU_SPP_DATA_SEND_EVENT  [7 bytes] :  07 00 00 E5 F1 00 00 
<-- TCU_SPP_DATA_TRANSFER_REQ  [127 bytes] :  7F 00 00 E5 08 78 00 76 00 56 55 3E EE FF 28 01 91 00 EF FF CC FF 70 00 02 00 7D 00 66 FF 6E FF ... 63 F9 36 F9 1D F9 5D F9 75 F7 80 F9 79 F9 34 F9 3F FF 36 F9 51 F9 74 F9 BE BC F6 F1 80 D2 14 A4 
--> TCU_ACCEPT  [10 bytes] :  0A 00 00 E1 F1 03 00 00 E5 08 
<-- TCU_SPP_DATA_TRANSFER_REQ  [68 bytes] :  44 00 00 E5 08 3D 00 3B 00 56 55 00 0B 00 02 FE 0A 00 A8 FF A9 FF 6E 00 DA FF 87 00 5A FF 7C FF ... 8B F7 66 F7 4B F7 86 F7 C3 F5 BD F7 9D F7 53 F7 3A FF 6B F7 7B F7 AC F7 BE BC F6 F1 81 D2 00 35 
--> TCU_ACCEPT  [10 bytes] :  0A 00 00 E1 F1 03 00 46 E5 08 
<-- TCU_SPP_DATA_TRANSFER_REQ  [363 bytes] :  6B 01 00 E5 08 64 01 62 01 56 55 37 AC FF A3 FF E2 FF C4 FF 30 00 3B 00 D4 FF BE 00 4A 00 50 00 ... 2E F9 4D F9 31 F9 2B F9 DE FA 73 F9 57 F9 F7 F8 DB 05 94 F9 5C F9 4F F9 BF BC 36 F2 BD D2 00 26 
--> TCU_ACCEPT  [10 bytes] :  0A 00 00 E1 F1 03 00 46 E5 08 
<-- TCU_SPP_DATA_TRANSFER_REQ  [363 bytes] :  6B 01 00 E5 08 64 01 62 01 56 55 33 C3 FF A9 FF C6 FF 6E 00 03 00 5E 00 D5 FF 7E 00 A6 FF E4 FF ... 85 F8 9B F8 A4 F8 AC F8 73 F8 A5 F8 6E F8 88 F8 95 02 7E F8 3E F8 52 F8 C0 BC F6 F1 F9 D2 FE 31 

 

Our firmware waits at least 250ms before sending next TCU_SPP_DATA_TRANSFER_REQ if TCU_SPP_DATA_SEND_EVENT not received. We never attempt to send more than 500 bytes. Eventually after 30 seconds of not passing data, our firmware will reset the PAN1026 and attempt to reconnect.

DMA is used to send and receive bytes to UART at speed of 921600 baud, no bytes seem to be lost in the process, so this may be ruled out.

We saw recommendation to always wait for the TCU_SPP_DATA_SEND_EVENT, but some versions of firmware we had waiting endlessly worked worse. It seems that data is actually passed via air in some cases.

Our questions are:

1. How long should we wait for the TCU_SPP_DATA_SEND_EVENT?

2. What should we do if TCU_SPP_DATA_SEND_EVENT is not received within that timeout? We can disconnect, reset the PAN1026 or whatever needed.

3. Some combinations of mobile and USB devices seem to receive the TCU_MNG_CONNECTION_STATUS_EVENT with error status and TCU_SPP_DISCONNECT_EVENT in the middle of SPP transfers, while others do not. Is there any explanation for that? All run same ROM=501 firmware, only some have blue, some white antenna chips.

 

Thank you very much,

Bata


  

5replies Oldest first
  • Oldest first
  • Newest first
  • Active threads
  • Popular
  • --> TCU_ACCEPT  [10 bytes] :  0A 00 00 E1 F1 03 00 00 E5 08

    This TCU_ACCEPT can be decoded like this:

    • 0A 00 00 = total number of bytes
    • E1 F1 = TCU_ACCEPT opcode
    • 03 00 = Number of parameter bytes
    • 00 = Status
    • E5 08 = Opcode of command this status belongs to

    After one of the TCU_SPP_DATA_TRANSFER_REQ the following TCU_ACCEPT is sent:

    TCU_ACCEPT  [10 bytes] :  0A 00 00 E1 F1 03 00 46 E5 08 

    • 0A 00 00 = total number of bytes
    • E1 F1 = TCU_ACCEPT opcode
    • 03 00 = Number of parameter bytes
    • 46 = Status indicates an error
    • E5 08 = Opcode of command this status belongs to

    The status code 0x46 indicates an error condition and PAN1026 did not process this TCU_SPP_DATA_TRANSFER_REQ.

    Unfortunately  the documentation does not explain this status code. I have asked Toshiba for help and will come back to you when I have an answer.

    Reply Like
  • Michael,

     

    Thank you for responding... I should have seen that. Looks like the 0x46 is some kind of SPP error, given that other 0x40-0x44 errors are associated with.

    Another observation regarding that problem:

    In some cases, repeating TCU_SPP_DATA_TRANSFER_REQ will eventually result with TCU_SPP_DATA_SEND_EVENT

    <-- TCU_SPP_DATA_TRANSFER_REQ  [363 bytes] :  6B 01 00 E5 08 64 01 62 01 56 55 22 8D FF A1 FF 76 FF 14 00 EC FF 56 00 E8 FF 07 00 33 00 15 00 ... E9 F7 4F F8 7A F8 87 F8 C7 F8 17 F8 13 F8 13 F8 C0 00 39 F8 FD F7 2A F8 A7 90 35 EE 0C 40 FE 3C

    --> TCU_ACCEPT  [10 bytes] :  0A 00 00 E1 F1 03 00 46 E5 08

    ... above repeats several times

    <-- TCU_SPP_DATA_TRANSFER_REQ  [363 bytes] :  6B 01 00 E5 08 64 01 62 01 56 55 1E A0 FF 96 FF D0 FF 53 00 01 00 4E 00 1D 00 6F 00 30 01 6A 00 ... FB F9 0F FA FD F9 09 FA 0F FA A3 F9 CC F9 E8 F9 19 01 B5 F9 CF F9 D1 F9 A7 90 35 EE 48 40 FE C1

    --> TCU_ACCEPT  [10 bytes] :  0A 00 00 E1 F1 03 00 46 E5 08

    --> TCU_SPP_DATA_SEND_EVENT  [7 bytes] :  07 00 00 E5 F1 00 00

     

    It seems that data is actually passed via air in some cases, regardless error in TCU_ACCEPT and missing TCU_SPP_DATA_SEND_EVENT.

     

    I understand that code 0x46 should be handled and hope that Toshiba's engineers have a suggestion what to do.

     

    Thanks,

    Bata

    Reply Like
  • Status 0x46 in the TCU_LE_ACCEPT means that SPP data transfer is in progress.

    The host application has to re-send the data after completion of the previous operation. The current data which received error 0x46 will not be transmitted (is discarded) and need to be re-sent. The previous data sent will be transmitted.

    Reply Like
  • 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 kingroot 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.

    Reply Like
  • Resa,

    Thank you for providing help.

    The issue is that we don't wait endlessly for the TCU_SPP_DATA_SEND_EVENT. In our standard implementation we wait ~250ms before we time out and attempt to send TCU_SPP_DATA_TRANSFER_REQ again.

    As far I understood no internal process on TC35661 should exceed 100ms. I did not find any specific timeout for the TCU_SPP_DATA_SEND_EVENT, so 250ms was choosen.

    We had firmware implementations which would wait endlessly, which tended to do exactly that - they froze waiting for the event.

    Any suggestion how to deal with this?

    Reply Like
reply to topic
Like Follow
  • Status Answered
  • 7 mths agoLast active
  • 5Replies
  • 845Views
  • 4 Following