• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 3 answers
  • Subscribers 51 subscribers
  • Views 598 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC2640R2F: Write to OAD reset characterisitics not working correctly when number of bytes is greater than 30

Arul Christopher John Britto66
Prodigy 220 points
Part Number: CC2640R2F

Hi,

I have created a project based on "simple_peripheral_oad_onchip" example project and i am using bTool to connect and start OAD.

Tools used:

SDK: SimpleLink CC2640R2 SDK version 2_30_00_28

CCS:  CCS-8.2.0.0

The device possesses OAD reset characteristics and i have a need to write 32-byte to OAD reset characteristics in order to start OAD.

In order to send 32-bytes, i perform the following with the bTool.

i. Connect to the device and send "GATT_ExchangeMTU" command to set the MTU to 251.

ii. Write a 32-byte value to the the OAD reset characteristics.

After doing so, what i could see is that only 30 bytes are properly received at the client end although the length is 32 bytes.

Am i missing something here or is there any option that need to be selected in bTool in order to send more bytes?

I have performed the same test with an android application and it works fine where 32-bytes written to OAD reset characteristics is completely available.

Fullscreen BToolLogs.txt Download 
--------------------------------------------------------------------
[199] : <Rx> - 02:06:40.782
-Type           : 0x04 (Event)
-EventCode      : 0x000E (HCI_CommandCompleteEvent)
-Data Length    : 0x06 (6) bytes(s)
 Packets        : 0x01 (1)
 OpCode         : 0x2022 (HCI_LE_SetDataLength)
 Status         : 0x00 (0) (SUCCESS)
 Handle         : 0x0000 (0)
Dump(Rx):
0000:04 0E 06 01 22 20 00 00 00                      ...." ...
--------------------------------------------------------------------
[200] : <Info> - 02:06:40.891
Device Connected
Handle = 0x0000
Addr Type = 0x00 (ADDRTYPE_PUBLIC)
BDAddr = F0:F8:F2:CB:72:6D
--------------------------------------------------------------------
[201] : <Rx> - 02:06:40.891
-Type           : 0x04 (Event)
-EventCode      : 0x003E (HCI_LE_GenericReportEvent)
-Data Length    : 0x0B (11) bytes(s)
 LE Event Code  : 0x07 (7) (HCI_LE_DataLengthChangeEvent)
 LE Event Code  : 0x07 (7) (HCI_LE_DataLengthChangeEvent)
 Handle         : 0x0000 (0)
 MaxTxOctets    : 0x00FB (251)
 MaxTxTime      : 0x0848 (2120)
 MaxRxOctets    : 0x001B (27)
 MaxRxTime      : 0x0148 (328)
Dump(Rx):
0000:04 3E 0B 07 00 00 FB 00 48 08 1B 00 48 01       .>......H...H.
--------------------------------------------------------------------
[202] : <Tx> - 02:07:10.965
-Type           : 0x01 (Command)
-OpCode         : 0xFD82 (GATT_ExchangeMTU)
-Data Length    : 0x04 (4) byte(s)
 ConnHandle     : 0x0000 (0)
 ClientRxMTU    : 0x00FB (251)
Dump(Tx):
0000:01 82 FD 04 00 00 FB 00                         ........
--------------------------------------------------------------------
[203] : <Rx> - 02:07:11.012
-Type           : 0x04 (Event)
-EventCode      : 0x00FF (HCI_LE_ExtEvent)
-Data Length    : 0x06 (6) bytes(s)
 Event          : 0x067F (1663) (GAP_HCI_ExtentionCommandStatus)
 Status         : 0x00 (0) (SUCCESS)
 OpCode         : 0xFD82 (GATT_ExchangeMTU)
 DataLength     : 0x00 (0)
Dump(Rx):
0000:04 FF 06 7F 06 00 82 FD 00                      .........
--------------------------------------------------------------------
[204] : <Rx> - 02:07:11.200
-Type           : 0x04 (Event)
-EventCode      : 0x00FF (HCI_LE_ExtEvent)
-Data Length    : 0x08 (8) bytes(s)
 Event          : 0x0503 (1283) (ATT_ExchangeMTURsp)
 Status         : 0x00 (0) (SUCCESS)
 ConnHandle     : 0x0000 (0)
 PduLen         : 0x02 (2)
 ServerRxMTU    : 0x00F7 (247)
Dump(Rx):
0000:04 FF 08 03 05 00 00 00 02 F7 00                ...........
--------------------------------------------------------------------
[205] : <Rx> - 02:07:11.215
-Type           : 0x04 (Event)
-EventCode      : 0x00FF (HCI_LE_ExtEvent)
-Data Length    : 0x08 (8) bytes(s)
 Event          : 0x057F (1407) (ATT_MtuUpdatedEvt)
 Status         : 0x00 (0) (SUCCESS)
 ConnHandle     : 0x0000 (0)
 PduLen         : 0x02 (2)
 MTU            : 0x00F7 (247)
Dump(Rx):
0000:04 FF 08 7F 05 00 00 00 02 F7 00                ...........
--------------------------------------------------------------------
[206] : <Tx> - 02:07:32.050
-Type           : 0x01 (Command)
-OpCode         : 0xFD96 (GATT_WriteLongCharValue)
-Data Length    : 0x26 (38) byte(s)
 ConnHandle     : 0x0000 (0)
 Handle         : 0x001E (30)
 Offset         : 0x0000 (0)
 Value          : 01:02:03:04:05:06:07:08:09:10:11:12:13:14:15:16:
                  17:18:19:20:21:22:23:24:25:26:27:28:29:30:31:32
Dump(Tx):
0000:01 96 FD 26 00 00 1E 00 00 00 01 02 03 04 05 06 ...&............
0010:07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 ............. !"
0020:23 24 25 26 27 28 29 30 31 32                   #$%&'()012
--------------------------------------------------------------------
[207] : <Rx> - 02:07:32.081
-Type           : 0x04 (Event)
-EventCode      : 0x00FF (HCI_LE_ExtEvent)
-Data Length    : 0x06 (6) bytes(s)
 Event          : 0x067F (1663) (GAP_HCI_ExtentionCommandStatus)
 Status         : 0x00 (0) (SUCCESS)
 OpCode         : 0xFD96 (GATT_WriteLongCharValue)
 DataLength     : 0x00 (0)
Dump(Rx):
0000:04 FF 06 7F 06 00 96 FD 00                      .........
--------------------------------------------------------------------
[208] : <Rx> - 02:07:52.357
-Type           : 0x04 (Event)
-EventCode      : 0x00FF (HCI_LE_ExtEvent)
-Data Length    : 0x06 (6) bytes(s)
 Event          : 0x0519 (1305) (ATT_ExecuteWriteRsp)
 Status         : 0x14 (20) (bleNotConnected)
 ConnHandle     : 0x0000 (0)
 PduLen         : 0x00 (0)
Dump(Rx):
0000:04 FF 06 19 05 14 00 00 00                      .........
--------------------------------------------------------------------

Thanks,

Arul Christopher

  • 0
    TI__Mastermind 25810 points
    Hey Arul,

    I tested your use case with Project Zero, and it looks like everything's being done correctly. I was able to similarly write 40 characters.

    You mentioned successfully reading all the data on the application side when writing 32 bytes via a phone application, correct? I would double check your project code and make sure the service has been set up correctly to handle long characteristic writes (via the write and read callbacks).

    If you can provide a sniffer log of the connection events, we can narrow down what's happening over the air. You may be setting the MAX_PDU in host_test, but your peripheral device may be responding with something different.
  • 0 in reply to Ammar N
    Prodigy 220 points

    Hi Ammar,

    I tested the same scenario with "simple_peripheral_oad_onchip" example project. (v2.30.00.28\simplelink_cc2640r2_sdk_2_30_00_28\examples\rtos\CC2640R2_LAUNCHXL\blestack\simple_peripheral_oad_onchip)

    Here i am trying to write 32-bytes to "OAD reset characteristic" from BTool. As i mentioned in the previous post, 30-bytes are received correctly although the received length is 32 bytes.

    In order to send 32-bytes, i perform the following with the bTool.

    i. Connect to the device and send "GATT_ExchangeMTU" command to set the MTU to 251.

    ii. Write a 32-byte value to the the OAD reset characteristics.

    Do i need to make any changes while setting up OAD reset characteristics?

    Attached the sniffer logs: (Refer P.nbr: 908, P.nbr: 1717)BTool_OAD_Reset_Characteristic_Write_32Bytes.psd

    The same has been tested with nRFConnect android application where all the 32-bytes are received. However there are few differences in sniffer logs where the packet is splitted and sent as two seperate packets. (Refer P.nbr: 5334 ...) 

    nRFConnect_OAD_Reset_Characteristic_Write_32Bytes.psd

    Thanks,

    Arul Christopher

  • 0 in reply to Arul Christopher John Britto66
    TI__Mastermind 25810 points

    Hey Arul,

    I did take a look at the sniffer files, and I'm not sure why the write response has corrupted data. I will investigate this further and report back.

    In the meantime, I would suggest trying the following to enable long writes to the oad reset characteristic.

    In the oad_reset_service.c file, you'll need to change the resetCharVal to an array type as follows:

    static uint8_t resetCharVal[resetCharVal_LEN] = {0};

    Following that, you'll need to edit the attribute table to reflect that change (simply remove the '&' from '&resetCharVal').

    Finally, you'll need to edit the write callback function for that characteristic to handle storing the data. I haven't had a chance to test this fully, but I believe the ResetWriteAttrCB() function is where these changes need to be made.

    I would take a look at the data_service.c file from project_zero to see how it's implemented there.

  • 0 in reply to Ammar N
    Prodigy 220 points

    Hi Ammar,

    I did not make any modifications to oad_reset_service.c file (neither the resetCharVal nor ResetWriteAttrCB()). Instead i modified the application callback similar to function "user_enqueueCharDataMsg" in project_zero.c file of Project Zero. Here i am copying the characteristic value (pValue) to another memory before switching from stack task to application task.

    =============================================================================================================

    static void user_enqueueCharDataMsg( app_msg_types_t appMsgType,

                                        uint16_t connHandle,

                                        uint16_t serviceUUID, uint8_t paramID,

                                        uint8_t *pValue, uint16_t len )

    {

     // Called in Stack's Task context, so can't do processing here.

     // Send message to application message queue about received data.

     uint16_t readLen = len; // How much data was written to the attribute

     // Allocate memory for the message.

     // Note: The pCharData message doesn't have to contain the data itself, as

     //       that's stored in a variable in the service implementation.

     //

     //       However, to prevent data loss if a new value is received before the

     //       service's container is read out via the GetParameter API is called,

     //       we copy the characteristic's data now.

     app_msg_t *pMsg = ICall_malloc( sizeof(app_msg_t) + sizeof(char_data_t) +

                                     readLen );

     if (pMsg != NULL)

     {

       pMsg->type = appMsgType;

       char_data_t *pCharData = (char_data_t *)pMsg->pdu;

       pCharData->svcUUID = serviceUUID; // Use 16-bit part of UUID.

       pCharData->paramID = paramID;

       // Copy data from service now.

       memcpy(pCharData->data, pValue, readLen);

       // Update pCharData with how much data we received.

       pCharData->dataLen = readLen;

       // Enqueue the message using pointer to queue node element.

       Queue_enqueue(hApplicationMsgQ, &pMsg->_elem);

     // Let application know there's a message.

     Event_post(syncEvent, PRZ_APP_MSG_EVT);

     }

    }

    =============================================================================================================

    The memory "pValue" and the Attribute Value "resetCharVal" seems to be different which i found during debugging and this is the reason why i did not make any changes to "resetCharVal".

    Now i see that the bytes are getting received properly without corruption.

    Thanks,

    Arul Christopher

  • 0 in reply to Arul Christopher John Britto66
    TI__Mastermind 25810 points

    That's great! Make sure to hit the 'Resolved Button' on your reply so that others may benefit from this as well.