This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC2640R2F: GATT_Notification Hang on Multiple Notifications

Part Number: CC2640R2F
Other Parts Discussed in Thread: SYSCONFIG, CC2340R5

Tool/software:

I am working on a BLE data collection sensor based on the simple peripheral OAD off chip example.

I am trying to increase my data throughput for a BLE sensor and am running into an issue where it seems the GATT buffer for one of the Notifying Characteristics fills up faster than it is emptied. My fw application is hanging within the gattServApp_SendNotiInd() function at the call to GATT_Notification().

I am trying to send a buffer of records that is about 32 KB in size. Previously, I was sending a single data record and header with total payload of 18 bytes per notification transmission. Theoretically I should be able to send 15 records and a header per notification with a payload totaling 242 bytes as this is less than MAX_PDU_SIZE (251). However, when I increase the notification to just include 4 records (66 bytes total) the application hangs at GATT_Notification() after it returns a value of 4 after sending 10 notifications in a row.

It seems an older post had a similar issue but the efforts to resolve were taken off the forum in order to share the project. Can someone share with me the resolution?

e2e.ti.com/.../4537051

  • Hi Sam !

    I will ask the expert that handled this case 2 years ago what the resolution was. In the meanwhile, can you try using ROV (user guide link) to see what is the available space you have in RAM before and after running GATT_Notificaiton ? This would help to see if you are lacking memory, or if you have a memory leak, or something else.

    Kind regards,
    Maxence

  • Surprisingly, the stackPeak of the gapRole_taskFxn & our application taskFxn do not seem to hit their stackSizes after calling GATT_Notification. Though the Application task's stackPeak does climb. This does not seem as much like a memory leak as I originally assumed but it does not shed any light on why the communications seem to fail with a larger packet size.

    Any update on your end?

  • Hi !

    I did not receive any update on my end. I delved deeper into your issue, and error code 4 for the GATT_Notification function is associated to MSG_BUFFER_NOT_AVAIL. This error happens when there is no HCI Buffers available anymore for the BLE Stack to allocate space for a notification.

    You can increase the amount of total buffers used for BLE by increasing the "Max number of PDUs" in sysconfig here : 

    Kind regards,
    Maxence

  • Maxence:

    I tried a few different values for the MAX_NUM_PDU: 5, 10, & 15 and there was no change in behavior. I do not have the same GUI to make those adjustments. What tool are you using there?

    Sam

  • Hi,

    I'm using SysConfig, which is a tool developped to easily configure the board that you are using, but in the picture I was in a CC2340R5 project and not a CC2640R2 project. This tool is not available of the CC2640R2, my mistake.

    For your initial issue, changing the max number of PDU is not as simple as changing the define in ble_user_config.h under ICallBLE. You also need to follow the instructions at the top of the file to include your custom configuration, which require additional steps :

                To change the default values of configurable variables:
                  - Include the followings in your application main.c file:
                    #ifndef USE_DEFAULT_USER_CFG

                    #include "ble_user_config.h"

                    // BLE user defined configuration
                    bleUserCfg_t user0Cfg = BLE_USER_CFG;

                    #endif // USE_DEFAULT_USER_CFG
                  - Set the preprocessor symbol MAX_NUM_BLE_CONNS, MAX_NUM_PDU,
                    MAX_PDU_SIZE, L2CAP_NUM_PSM or L2CAP_NUM_CO_CHANNELS
                    to a desired value in your application project.
                  - Include "ble_user_config.h" in your stack OSAL_ICallBle.c
                    file.
                  - Call setBleUserConfig at the start of stack_main. Actually,
                    it is okay to set the variables anywhere in stack_main as
                    long as it is BEFORE osal_init_system, but best to set at
                    the very start of stack_main.

                Note: User configurable variables are only used during the
                      initialization of the Controller and Host. Changing
                      the values of these variables after this will have no
                      effect.

                Note: To use the default user configurable variables, define
                      the preprocessor symbol USE_DEFAULT_USER_CFG in your
                      application project.

                For example:
                  - In your application main.c, include:
                    #ifndef USE_DEFAULT_USER_CFG

                    #include "bleUserConfig.h"

                    // BLE user defined configuration
                    bleUserCfg_t user0Cfg = BLE_USER_CFG;
                    #endif // USE_DEFAULT_USER_CFG
                  - In your application project, set the preprocessor symbol
                    MAX_NUM_BLE_CONNS to 1 to change the maximum number of BLE
                    connections to 1 from the default value of 3.
                  - In your stack OSAL_ICallBle.c file, call setBleUserCfg to
                    update the user configuration variables:
                    #include "bleUserConfig.h"
                    :
                    int stack_main( void *arg )
                    {
                      setBleUserConfig( (bleUserCfg_t *)arg );
                      :
                    }

    Kind regards,
    Maxence