Are you calling the cyble_processevents() on a timely basis? Not handling it before the next BLE window will cause issues;
Also, having an unhandled interrupt could potentially cause the chip to freeze as well.
yes, I am calling cyble_processevents() on a timely basis.
I did not get " Not handling it before the next BLE window".What does it mean?
About interrupt, Interrupt did not occur during BLE conversation.
Have you given maximum priority to the BLE interrupt?
BLE interrupt means BLE_bless_isr?
Priority is 3 to this interrupt.
BLE_bless_isr is generated & handled internally by BLE stack.
So how to detect it is not handled & if it is, what should I do?
Under the BLE component there is a connection timing setting for Minimum and Maximum connection intervals; If you don't process the BLE events with a call to processtEvents() within that time frame, then it will cause unknown behavior on the BLE hardware and will cause either a disconnect, crash, or other bad things
This is set between 7.5 ms to 10 ms by default iirc.
If you ever end up with your code sitting in an infinite loop that has a comment saying "the processor should never get here" then it is not being handled, otherwise your code will continue to run through main as normal.
The lower the number, the higher the priority iirc; So, setting the BLE_bless_isr interrupt to 0 is a good idea. (You should test with both 0 and 3 being the highest to be sure however).
The way BLE works is:
The central will connect to the peripheral device, and read the peripheral device's GATTDB server using the command CyBle_GattcReadCharacteristicValue()
However, your question refers to the function CyBle_GattsReadAttributeValue() which is used when you want to read the GATTDB value on the peripheral device USING the code running on the peripheral device. Thus, if you try to call CyBle_GattsReadAttributeValue() from the central device, it will not work as the central device is not configured/running as a peripheral device with a GATTDB server on it.
So my doubt is why this API cause hang & how without using it read operation works fine?
The reason it works fine without trying to handle the events is because the GATTDB is automatically interacting and handling read/write requests from the Central device coming to the peripheral device over the wireless channel. By default, the BLE profile/configurations will allow you to read/write to the peripheral profile from the CySmart application without any code changes. You will only need to handle the read/write events if you want additionally functionality: E.G. checking security requirements before allowing a write, changing values being returned by a read, etc.
After reading your continuation questions/replies, I feel that the paragraph above is aimed more correctly at the question you are posing in your original post. My apologies for the confusion I caused with not understanding the question on the first read.
I understand different use case of CyBle_GattsReadAttributeValue() & CyBle_GattcReadCharacteristicValue() API.
It is like if I have another development board acting as central and if it wants to read the characteristic value from a server then we can use "CyBle_Gattc" APIs. And if we want to read the characteristic values from peripheral we can use "CyBle_Gatts" APIs.
As in my case, i am reading & writing char value from CySmart App So none of above function would be used.
Thanks epr_1639216 for this long explanation.
Exactly! I think you are understanding it correctly
The CySmart App would only use the CyBle_Gatts... functions if you want the CySmart App to behave like a peripheral device, which it sounds like you are only using the CyBle_GattcReadCharacteristicValue() and CyBle_GattcWriteCharacteristicValue() APIs to have the CySmart App read and write values to a Peripheral device.
Glad I could help, good luck with your endeavors