Problem sending indication messages from a custom service

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

cross mob
AnAs_1368766
Level 1
Level 1

Hi everyone,

   

I'm working on an application where I use the BL-A Pioner Kit with a CY8C4248LQI-BL583 module for simulate a peripheral sensor, that connects to a CySmart USB 4.1 dongle. I use CySmart 1.2 software to debug. I'm having problems with indication messages sent from a custom characteristic (which I use as a control point of the custom service). What happens is the following:

   

- From CySmart, I active the indications of that characteristic (writing 0x0002 in the associated CCCD).
- I write a value in the characteristic, my application answers with an indication.
- In the CySmart log window I check that the indication have actually been received.
- But in my application there is no CYBLE_EVT_GATTS_HANDLE_VALUE_CNF event.

   

At the beginning of my code (written from the example Running and Speed Cadence  ), I register the function that use to parse the BLE events

   

appResult = CyBle_Start(AppCallBack);

   

Where AppCallBack looks like this:

   

 

   

void AppCallBack(uint32 event, void *eventParam){

   

CYBLE_GATTS_WRITE_REQ_PARAM_T *wrReqParam;

   

switch(event) {

   

case CYBLE_EVT_GATTS_HANDLE_VALUE_CNF:

   

// This event never happen !!!!!!

   

 break;    

   

}                  

   

}

   

But, however in the function CyBle_EventHandler() of CYBLE_eventHandler.c file, when an Indication is confirmed then CYBLE_EVT_GATTS_HANDLE_VALUE_CNF event happens.

   


This seem confusing to me, any idea about what is happening?

   

Thanks,

   

Angel

0 Likes
3 Replies
Anonymous
Not applicable

Go read the BLE_Stack.h header file under the Generated_Source//PSoC4//BLE, it contains some comments/documentation with the events explaining which do/go with what.

   

My guess would be that you are initiating the indication with the CySmart? If so, then you would receive the _CNF on the CySmart application, NOT the application. If you are initiating the indication with the application, then you are right in that it should be receiving the _CNF event on the application.

   

What are you using to initiate the indication from your application to CySmart? Are you using CyBle_GattsIndication(); to send the indication? Or are you using a different function?

0 Likes
AnAs_1368766
Level 1
Level 1

e.pratt, thanks for the response,

   

I am sending the indication from my firmware to CySmart. I use this indication as a response to a previous write command sent from CySmart to a characteristic (that I use as a control point).

   

Yes, I use CyBle_GattsIndication() to send an indication from my firmware to CySmart().

   

My application includes a RSCS and several custom services. Now, I´m using debug traces (via UART) to investigate the problem, my observations are:

   

When I write (from CySmat) to a standard characteristic, my application generates a CYBLE_EVT_GATTS_WRITE_REQ in the CyBle_EventHandler() of the CYBLE_eventHandler.c file. When I write (from CySmat) to a custom characteristic, my application generates a _WRITE_REQ in the CyBle_EventHandler() of the CYBLE_eventHandler.c file and later a _WRITE_REQ in the function that I have registered as callback.

   

This seems OK. But with indications response… it is different

   

From Cysmart, I send the write command to a standard characteristic, my app processes it and I respond with an indication. CySmart ACK and a _CNF in the CyBle_EventHandler() of the CYBLE_eventHandler.c is generated.

   

But when I send a write command to a custom characteristic (and my firmware responses with an indication to CySmart) I get the _CNF event in CyBle_EventHandler(), but there is not event in my callback function.

   

At the moment I fixed this, by parsing the indication confirmation inside the CyBle_EventHandler()… but I think that it is a sloppy solution (and of course, with each new re-built it is necessary to re-write )

   

Thanks in advanced

0 Likes
Anonymous
Not applicable

Interesting. This sounds like a bug with the BLE stack. Try opening a support case with cypress and see what they say 🙂

   

PS: Let us know what you find out, I'm curious what's going on here too

0 Likes