GATTS attribute creation using ezsapi

[IG]

Hi All,

We are using CYBLE-013025 bluetooth module and communicating with it via USART interface from another microcontroller.

While using an example 19 (page 39) from Infineon-EZ-Serial_BLE_Firmware_Platform_User_Guide_V1.1.2-Software-v01_00-EN.pdf document on evaluation board using serial console it worked as expected.

Though we found that using API provided via ezsapi.c file is different from what is specified for gatts_create_attr (/CAC, ID=5/1) command at page 86 in the above document. Even the number of parameters is different.

So, on the first step we are trying to create a Customer primary service attribute with UUID =  65333333-A115-11E2-9E9A-0800200CB100   and that customer service will have type UUID = 0x2800.

Here is an example of the command that we are trying to run:

longuint8a_t payload = {.length = 0x12, .data = {0x00, 0x28, 0x00, 0xB1, 0x0C, 0x20, 0x00, 0x08, 0x9A, 0x9E, 0xE2, 0x11, 0x15, 0xA1, 0x33, 0x33, 0x33, 0x65}};
/* create new service */
if ((packet = EZS_SEND_AND_WAIT(ezs_cmd_gatts_create_attr(0, 0x01, 0x00, 0x00, 0x14, &payload), COMMAND_TIMEOUT_MS)) == 0)
{
PRINTF("Failed to create new service\n");
}
else
{
PRINTF("Created new service\n");
}

In the command above, type=0, read_permission=1, write_permission=0, char_properties=0, length=0x14 followed by data which comprises by 2 bytes length=0x12, then actual data of type UUID + service UUID.

The response is: RX: rsp_gatts_create_attr: result=020c, attr_handle=0000, valid=0000

This means it has failed as correct response would come back with an attribute handle and valid=1.

I have also compared two commands on serial wire.

Here is command sent out manually while using a terminal and it works  with CYBLE-013025 bluetooth module (all in hex):

C0 18 05 01 00 02 12 00 12 00 00 28 00 B1 0C 20 00 08 9A 9E E2 11 15 A1 33 33 33 65 89

And this is supposed to be the same command generated via ezs_cmd_gatts_create_attr() API method:
C0 1B 05 01 00 00 01 00 00 14 00 12 00 00 28 00 B1 0C 20 00 08 9A 9E E2 11 15 A1 33 33 33 65 8D

These are clearly different, so the last one doesn't work. This would indicate that ezsapi API we are using is incorrect. 

We are using Infineon-EZ-Serial_Host_API_Protocol_Library-Software-v01_00-EN.zip where inside the archive readme file indicates: "EZ-Serial BLE Firmware platform release V1.1.1. The protocol version implemented
in these files is V1.3."

Is it a correct serial host API version to use with CYBLE-013025 bluetooth module? 

Here is system query firmware version response from the module: RX: rsp_system_query_firmware_version: app=0101021f, stack=02020355, protocol=0103, hardware=b1

I would greatly appreciate if someone can help by providing an example on how to use ezs_cmd_gatts_create_attr() command from ezsapi or at least point out what is wrong with the command above?

Thank you.

[PratikshaV]

Hi @IG 

Please can you share the logs from the start so that we can understand the issue better.

Thanks & Regards

Pratiksha V

[IG]

Hi Pratiksha,

TBH there is no much logs to share.

The command: ezs_cmd_gatts_create_attr(0, 0x01, 0x00, 0x00, 0x14, &payload).

In the command above, type=0, read_permission=1, write_permission=0, char_properties=0, length=0x14 followed by data which comprises by 2 bytes length=0x12, then actual data payload of type UUID + service UUID.

The response is: RX: rsp_gatts_create_attr: result=020c, attr_handle=0000, valid=0000

The command generated via ezs_cmd_gatts_create_attr() API method:
C0 1B 05 01 00 00 01 00 00 14 00 12 00 00 28 00 B1 0C 20 00 08 9A 9E E2 11 15 A1 33 33 33 65 8D

Clearly there are discrepancies between example 19 (page 39) from Infineon-EZ-Serial_BLE_Firmware_Platform_User_Guide_V1.1.2-Software-v01_00-EN.pdf document and ezsapi from Infineon-EZ-Serial_Host_API_Protocol_Library-Software-v01_00-EN.zip.

I would appreciate if you can provide me with a working example of ezs_cmd_gatts_create_attr() command from ezsapi ?

Thanks.

GI

[Sven_Wang · Accepted solution]

Hi @IG 

Sorry for apply so late.

I used the WICED™ EZ-Serial Text-to-Binary Conversion Tool (Python):

and resend the text content for

C0 18 05 01 00 02 12 00 12 00 00 28 00 B1 0C 20 00 08 9A 9E E2 11 15 A1 33 33 33 65 89

in the WICED™ EZ-Serial BLE Firmware Platform User Guide - V1.1.2 page 39 and get the results as follows:

/CAC,T=00,P=2,L=0012,D=002800B10C2000089A9EE21115A133333365
1670404165.105: TX=> [wiced_ble.cmd_gatts_create_attr (5/1) from assembly (scope=ram), type: 0x0, permissions: 0x2, length: 0x12, data: 002800B10C2000089A9EE21115A133333365]
1670404165.106: TX=> [C0 18 05 01 00 02 12 00 12 00 00 28 00 B1 0C 20 00 08 9A 9E E2 11 15 A1 33 33 33 65 89] (b'\xc0\x18\x05\x01\x00\x02\x12\x00\x12\x00\x00(\x00\xb1\x0c \x00\x08\x9a\x9e\xe2\x11\x15\xa1333e\x89')

1670404165.127: <=RX [wiced_ble.rsp_gatts_create_attr (5/1) from binary (scope=ram), result: 0x110, attr_handle: 0x17, valid: 0x8]
1670404165.127: <=RX [C0 06 05 01 10 01 17 00 08 00 95] (b'\xc0\x06\x05\x01\x10\x01\x17\x00\x08\x00\x95')

You can find the Permission bits from the user guide in page 86. So do you need a Variable length for your permission bits?

According to the log, we can found that the permissions should be 2 rather than 1. This should be the reason for this issue.

Thanks

Sven