CC2640R2F: Bluetooth PTS test fail (GATT/SR/UNS/BI-01-C)

Hi,

I have assigned an expert to help with your query. In the meantime, could you verify if you are able to see the same behavior in the host_test example?

Best Regards,

Jan

Hi Jan,

The result is the same using host_test and BTool (blestack), albeit with a different response to the ATT request:

+8125 ms
Receive Event:           ATT?ATT_PREPARE_WRITE_ERR_RSP{
                           lcid=0x1205,
                           attributeHandle=0xEC30,
                           result=0x0301
                         }


+8125 ms
Verdict Description:     ATT Prepare Write returned an error.


+8125 ms
Preliminary Verdict:     PASS


+8125 ms
Verdict Description:     Invalid request handle received. Expected=0x0000 Received =0xec30.

The BTool log (below) does not record the ATT request, just the PTS connect and disconnect events.

Best Regards,

Jamie

--------------------------------------------------------------------
[75] : <Rx> - 12:07:52.578
-Type           : 0x04 (Event)
-EventCode      : 0x00FF (HCI_LE_ExtEvent)
-Data Length    : 0x14 (20) bytes(s)
 Event          : 0x0605 (1541) (GAP_EstablishLink)
 Status         : 0x00 (0) (SUCCESS)
 DevAddrType    : 0x00 (0) (ADDRTYPE_PUBLIC)
 DevAddr        : C0:07:E8:7D:14:9A
 ConnHandle     : 0x0000 (0)
 ConnRole       : 0x04 (4) (
                  Peripheral)
 ConnInterval   : 0x0038 (56)
 ConnLatency    : 0x0000 (0)
 ConnTimeout    : 0x07D0 (2000)
 ClockAccuracy  : 0x07 (7)
Dump(Rx):
0000:04 FF 14 05 06 00 00 9A 14 7D E8 07 C0 00 00 04 .........}......
0010:38 00 00 00 D0 07 07                            8......
--------------------------------------------------------------------
[76] : <Tx> - 12:07:52.581
-Type           : 0x01 (Command)
-OpCode         : 0x2022 (HCI_LE_SetDataLength)
-Data Length    : 0x06 (6) byte(s)
 Handle         : 0x0000 (0)
 TxOctets       : 0x00FB (251)
 TxTime         : 0x0848 (2120)
Dump(Tx):
0000:01 22 20 06 00 00 FB 00 48 08                   ." .....H.
--------------------------------------------------------------------
[77] : <Rx> - 12:07:52.624
-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                      ...." ...
--------------------------------------------------------------------
[78] : <Info> - 12:07:52.790
Device Connected
Handle = 0x0000
Addr Type = 0x00 (ADDRTYPE_PUBLIC)
BDAddr = C0:07:E8:7D:14:9A
--------------------------------------------------------------------
[79] : <Rx> - 12:07:52.782
-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.
--------------------------------------------------------------------
[80] : <Info> - 12:07:57.051
Device Disconnected
Handle = 0x0000
Addr Type = 0x00 (ADDRTYPE_PUBLIC)
BDAddr = C0:07:E8:7D:14:9A
--------------------------------------------------------------------
[81] : <Rx> - 12:07:57.051
-Type           : 0x04 (Event)
-EventCode      : 0x00FF (HCI_LE_ExtEvent)
-Data Length    : 0x06 (6) bytes(s)
 Event          : 0x0606 (1542) (GAP_TerminateLink)
 Status         : 0x00 (0) (SUCCESS)
 ConnHandle     : 0x0000 (0)
 Reason         : 0x13 (19) (PEER_REQUESTED_TERM)
Dump(Rx):
0000:04 FF 06 06 06 00 00 00 13                      .........
--------------------------------------------------------------------

Hi,

You could consider to intercept the command in HostTestApp_handleNPIRxInterceptEvent() or modify the function processExtMsgATT() in ICallBLE/icall_hci_tl.c

Please let me know if it helps.

Bets regards,

Hi Clement,

Those references are to code specific to host_test, clearly we would like to get this working in a standalone application. Why does TI not provide a patch (e.g. to simple_peripheral) or Bluetooth compliant sample code in the first place?

Best Regards,

Jamie

Hi Jamie,

The same is applicable to simple_peripheral when using PTM.

Best regards,

Hi Clement,

The blestack simple_peripheral example of SDK 5.30 does not include a file ICallBLE/icall_hci_tl.c, nor does it include a function named *handleNPIRxInterceptEvent* anywhere in the code. 

Again, why do you not provide a solution to a non-compliance issue?

Regards,

Jamie

Hi Jamie,

Sorry for the confusion, I thought you were using the BLE5Stack - in that case when PTM is enabled, the function simple_peripheral_handleNPIRxInterceptEvent can be found in simple_peripheral.c.

I'll check for the BLEStack.

Best regards,

Hi,

I guess you have followed the following document to enable PTM in the simple_peripheral example: https://dev.ti.com/tirex/content/simplelink_cc2640r2_sdk_5_30_00_03/docs/blestack/ble_user_guide/html/ble-stack-3.x/creating-a-custom-bluetooth-low-energy-application.html#using-production-test-mode-ptm

If you have done so, then you should have defined the function simple_peripheral_handleNPIRxInterceptEvent (as defined in one of the listings here).

Please let me know if you need more details.

Best regards,

Hi Clement,

No, I have not enabled PTM as we have the capability to run HCI and other commands through a proprietary interface on the host processor. I don't see how this is relevant, though, as the device will need to pass this Bluetooth compliance test in the field as well as in a production test environment. What are the steps in the production code to get the device to return the correct ATT response?

Best Regards,

Jamie

Hi Jamie,

Assuming the commands are sent to the host processor, you could intercept incorrect commands (such as the one causing the issue) and send back the proper event. I may be missing something here, please let me know your thoughts.

Best regards,

Hi Clement,

I think there is an assumption that the average user has a thorough knowledge of all of the code in the SDK, where in reality the SDK and associated example projects are provided to insulate users from this detail.

Can you point to a specific location in the code where I could intercept this particular ATT command and implement the response (e.g. for simple_peripheral)?

Best Regards,

Jamie

Hi Jamie,

At the moment I do not understand how the commands get executed, so it is difficult for me to answer.

I mean, it looks like you are using simple_peripheral but have not enabled PTM. As a consequence, I do not understand how the commands are inputted in the device and I cannot tell you how to intercept the command.

Best regards,

Hi Clement,

There is nothing specific to our implementation in this request. It is a straightforward non-compliance issue of the TI provided SDK with the Bluetooth SIG provided compliance process. Steps to replicate are simply:

• Load unmodified simple_peripheral project (SDK 5.30, BLEstack) onto LAUNCHXL-CC2640R2 or similar
• Open the Profile Tuning Suite from Bluetooth SIG, create a new workspace, connect to the dev board
• Import an ICS created for a Bluetooth LE peripheral (I can send this if you don't have it)
• In the workspace tool window navigate to GATT -> SR -> UNS -> BI-01-C and double click to run the test

The test GATT/SR/UNS/BI-01-C will fail and produce output similar to that included in my original post. This test is mandatory for a Bluetooth LE peripheral so failure indicates non-compliance by this implementation. 

So the simple request is for a patch/update/code change to the simple_peripheral project to enable it to pass this test in a standalone BLE implementation.

Best Regards,

Jamie

Hi Jamie,

Thank you for reporting this issue.

Our R&D teams are working to reproduce the issue and fix it in a future release.

Best regards,

Hi Clement,

We'll fix it later isn't a solution. What do we do if we need a Bluetooth compliant product now, use a different vendor?

Regards,

Jamie

Hi Jamie,

I understand your frustration. However, this device is used in hundreds of designs and has gone through certification before so it is difficult for me to justify setting this thread as our absolute priority.

To help resolution, I am looking with our R&D team on the results obtained in regression. I hope they will give me an answer by the end of the week.

In parallel, you may want to assess whether the profile qualification you are working on is mandatory in your case. Assuming you are satisfying RF-PHY certification (or is allowed to leverage our End Product Listing QDIDs) you should be allowed to use Bluetooth's name. Profile qualification can also be added at a later point in order to avoid delaying product deployment. 

I hope this will help,

Best regards,

Hi Clement,

Rather than taking the time to second guess the issue why not just run the very simple set of steps that I outlined, should take no more than 10 minutes with the correct setup.

Qualification is required as a Bluetooth End Product using the TI component QDID 176642 specific to the CC2640R2F part:

The GATT server is of course mandatory for an LE peripheral:

The resulting test plan requires GATT/SR/UNS/BI-01-C to pass due to GATT 1/2 above:

So, unless you can point out something I am missing, the current SDK/example projects are non-compliant for an LE peripheral; i.e. the vast majority of target implementations for this device.

Regards,

Jamie

Hi Clement,

Thanks, that was it. Sorry, I didn't realise using an End Product QDID for a component was even an option for Bluetooth certification - seems counterintuitive. This gets us to the next step anyway so problem solved!

Best Regards,

Jamie

Hi Jamie,

Awesome! Thank you for confirming.

Best of luck with the next steps of the project.

Regards,