BLE EZ-Serial with host processor, problem to discover services and characteristics of a remote GATT server using “gattc_discover_services” and “gattc_discover_characteristics”

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
DaM__2104136
Level 2
Level 2
Welcome!

I am using a BLE module (CYBLE-212019-00) connected to a host processor and controlled via EZ-serial API (EZ-serial v.1.1.1 on BLE module, API library version 1.3). I try to connect the BLE module to a remote GATT server and discover the services and characteristics on this remote server. I am able to connect the BLE module, but the command for discovering services and characteristics fail with a result code 0x0108 “Operation not permitted”, although I am waiting the connection event to send the discovery command. Note that the service discovery and characteristic discovery works when I am using the text commands, but not when I send the same command (in binary) via the API.

Below are some additional details.

Thank you for the support.

David

Detail of the setup and the tests:

  • Connection between two BLE modules CYBLE-212019-00, one is the client, the other is the server.
  • Use of the default configuration without using CYSPP.
  • Factory reset between tests.
  • Pairing/bounding does not solve the problem.
  • Using different parameter value for begin/end attribute handle for the discovery command does not solve the problem.
  • Service discovery command is sent only when the connection has been established (gap_connected event received).

Test in text mode (successful):

# Factory reset

/RFAC

@R,000B,/RFAC,0000

@E,0005,RFAC

@E,003B,BOOT,E=0101011A,S=03030035,P=0103,H=05,C=05,A=00A0504219E3

@E,000E,ASC,S=01,R=03

# Start scan

/S

@R,0008,/S,0000

@E,000E,SSC,S=01,R=00

@E,0062,S,R=00,A=00A050584756,T=00,S=BF,B=00,D=020106110700A10C2000089A9EE21115A13333336507FF310100000000

# ... Multiple scan results

# Stop scan

/SX

@R,0009,/SX,0000

@E,000E,SSC,S=00,R=00

# Stop advertisement

/AX

@R,0009,/AX,0000

@E,000E,ASC,S=00,R=00

#Connection

/C,A=00A050584756,T=00,I=0006,L=0000,O=0064,V=0100,W=0100,M=000A

@R,000D,/C,0000,C=00

@E,0035,C,C=02,A=00A050584756,T=00,I=0006,L=0000,O=0064,B=00

# Service discovery

/DRS,B=0001,E=FFFF

@R,000A,/DRS,0000

@E,0029,DR,C=02,H=0001,R=0007,T=2800,P=00,U=0018

@E,0029,DR,C=02,H=0008,R=000B,T=2800,P=00,U=0118

@E,0045,DR,C=02,H=000C,R=0015,T=2800,P=00,U=00A10C2000089A9EE21115A133333365

@E,0045,DR,C=02,H=0016,R=001C,T=2800,P=00,U=00A20C2000089A9EE21115A133333365

@E,0010,RPC,C=02,R=060A

# Disconnection command

/DIS

@R,000A,/DIS,0000

@E,0010,DIS,C=02,R=0916

@E,000E,ASC,S=01,R=03

Test using API (fail):

// Connection (after scan results and advertisement stopped)

response = EZS_SEND_AND_WAIT(ezs_cmd_gap_connect(

    mac_addr.addr,

    mac_addr_type,

    0x0006, // Connection interval

    0x0000, // Slave latency

    0x0064, // Supervision timeout

    0x0100, // Scan interval

    0x0100, // Scan window

    0x000A // Scan timeout

    ), BLE_COMMAND_TIMEOUT_MS);

// ... response code is OK.

// ... wait for gap_connected event before starting service discovery

// Service discovery

response = EZS_SEND_AND_WAIT(ezs_cmd_gattc_discover_services(

    0x00,

    0x0001,

    0xFFFF

    ), BLE_COMMAND_TIMEOUT_MS);

// Result code in response packet is 0x0108 “Operation not permitted”

0 Likes
1 Solution

Dear Pratt,

Thanks for your answer and suggestions.

Did you wait for the connection complete/successful event? Just as there is an advertisement start/stop event, so should there be a connection complete/finished event to signal when the unit has finished connecting to the remote device.

Yes I wait the "gap_connected (C, ID=4/5)" event before starting the discovery process. I also verified the sequence of command/response/events by looking at the binary communication between the host processor and the BLE module (I implemented a "soft-probe" to record and display this). The command "gattc_discover_services" is sent after receiving the "gap_connected" event.

I just tried with a small waiting period AFTER the "gap_connected" event and this seems to solve the problem. The minimum period between the "gap_connected" event and the service discovery is around 4 ms (i.e. with 3 ms. waiting period, the discovery service command fails).

So, the problem seems to be solved (I still need to run additional tests with different connection parameters and a complete discovery and communication procedure). However, this required waiting period seems to be a bug as I found no mention of a required waiting time after connection in the "EZ-Serial plateform user guide". Note that, since the beginning I process all EZ-events and EZ-responses in an asynchronous manner (i.e. no EZ-serial API function is called in the "ezs_handler" function, to avoid conflicts with variables used by the "EZSerial_Parse" function).

I continue the tests and I make an update here when I am sure of the result.

Best,

David

View solution in original post

0 Likes
3 Replies
Anonymous
Not applicable

Did you wait for the connection complete/successful event? Just as there is an advertisement start/stop event, so should there be a connection complete/finished event to signal when the unit has finished connecting to the remote device.

An alternative is to try waiting a small period of time (1-5 seconds) to make sure the connection is fully up before attempting the service discovery.

0 Likes

Dear Pratt,

Thanks for your answer and suggestions.

Did you wait for the connection complete/successful event? Just as there is an advertisement start/stop event, so should there be a connection complete/finished event to signal when the unit has finished connecting to the remote device.

Yes I wait the "gap_connected (C, ID=4/5)" event before starting the discovery process. I also verified the sequence of command/response/events by looking at the binary communication between the host processor and the BLE module (I implemented a "soft-probe" to record and display this). The command "gattc_discover_services" is sent after receiving the "gap_connected" event.

I just tried with a small waiting period AFTER the "gap_connected" event and this seems to solve the problem. The minimum period between the "gap_connected" event and the service discovery is around 4 ms (i.e. with 3 ms. waiting period, the discovery service command fails).

So, the problem seems to be solved (I still need to run additional tests with different connection parameters and a complete discovery and communication procedure). However, this required waiting period seems to be a bug as I found no mention of a required waiting time after connection in the "EZ-Serial plateform user guide". Note that, since the beginning I process all EZ-events and EZ-responses in an asynchronous manner (i.e. no EZ-serial API function is called in the "ezs_handler" function, to avoid conflicts with variables used by the "EZSerial_Parse" function).

I continue the tests and I make an update here when I am sure of the result.

Best,

David

0 Likes

Hi David,

   The discovery procedure takes some time because the client device sends multiple commands internally to discover the attributes. So, if we send discovery services and characteristics command continuously it may result in an error.

Yes, you should call all the commands after receiving  response from the previous command and should not proceed the command in an asynchronous manner.

Please let me know if you have any further queries while performing the tests.

-Gyan

0 Likes