- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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”
Solved! Go to Solution.
- Labels:
-
BLE
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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