You are here

PSOC 4 BLE Number of notifications sent | Cypress Semiconductor

PSOC 4 BLE Number of notifications sent

Summary: 2 Replies, Latest post by Marian-Emanuel Ionascu on 09 Oct 2016 03:32 AM PDT
Verified Answers: 0
Last post
Log in to post new comments.
ionascu.marianemanuel_1654946's picture
29 posts

Hello everybody,

I have notice some strange behavior when trying to send some bursts of notifications over BLE. I will explain a little what I am doing.  I compute some data after my device will be first connected to another client(dongle, smartphone app, etc). After the client disconnects my device I will continue to save data in RAM until the RAM is full, then transfer all the bytes from RAM to FLASH and so one, until both FLASH and RAM are full if no connection is done. Once a connection is establish and the notification of my characteristic is enabled by the client I intend to empty both FLASH and RAM by bursting a number of notification with size 17.(if Both flash and ram is full I have about 180 kB of data).

What I observed is that the BLE sends 10 such burst notifications and stops sending them even if the code still sends notifications.

My call: /* Notify the phone that the values are update */
    CyBle_GattsNotification(cyBle_connHandle,  &tempHandle);


This happens not only when I try to sent that 180kB but also if I only try 11 notifications.

So my questions:

Does PSOC 4 have the same Credit behavior like Nordic Chips, if someone worked with such thing? The credit behavior is like this: you have a number of bytes that can be sent and if you run out of credit you should put a while(delay, etc) until you will receive more or your data will not be sent.

Should I do other approach to overcome this problem?

I should mention that my code did not break even if the 180kB will introduce some Delay. The data from RAM, FLASH is correct and the code for sure calls the GattsNotification function for a lot of times. I have the same problem also in some status characteristics that should send 11 notifications once in a while. We developed another code for a Nordic nRF8001 chip with credit behavior and it sends even hundreds of notification without a problem. I have CY8C4248LQI-BL583 chip with 256 kB Flash/32 kB RAM.

Thank you!

mady's picture
Cypress Employee
964 posts


Please make sure that your connection interval is small enough such that sending notification at these high rates is feasible. Keep your connection interval as low as possible.

Check if the GattsNotification API returns any error code. Also, it is not recommended to use CyDelay in your code. Please use WDT timers if you want to introduce delays.


- Madhu Sudhan

ionascu.marianemanuel_1654946's picture
29 posts

Hello Madhu,

Thanks for your input it is very valuable. Regarding the connection interval on the device I have 7.5-10(min max connection) and the supervision timeout at 100 ms. Of course as I know this parameters will depend on iOS and Android devices at the end but for the device I keep the smallest possible.

I did this for a characteristic that has only Notification attribute active( no read and write can be performed on it):

        /* Process BLE Events */
        /* retry until successful */
    }while( u8ConnectionFlag &&
            /* Notify the phone that the values are update */
            (CyBle_GattsNotification(cyBle_connHandle,  &tempHandle) != CYBLE_ERROR_OK)

And now I was able to receive hundreds of notifications. I also deleted the delay since I suppose the BLE stack and link should do the job. As I know in one connection interval there is 4-6 packages exchanges depending on the client. It seems ok.

Then again I have another problem with another characteristic that have also read attribute. This characteristic should only send 11 notifications every time. Of course without the above code I only receive 10 notifications. With the above code I only receive 2 notifications and the BLE is dead. I receive timeout on read, and furthermore even if I disconnect from the device it wont react. Without a reset it is dead.

So I think maybe the read attribute cause this. Maybe you have an idea what can be the problem. I need to mention that BLE has 0 interrupt priority(highest) and also I have WTD 0 active, WDT 2 active, SW pin interrupt therefore I except the code should not be frozen in the do while loop and some interrupts should jump in.

Thank you!


Log in to post new comments.