CC2340R5: Is it possible to tell the source of BLEAPPUTIL_ADV_END_AFTER_DISABLE event?

Shuyang Zhong

Part Number: CC2340R5

Tool/software:

I have a project using limited ADV duration, after the duration expires the BLEAPPUTIL_ADV_END_AFTER_DISABLE event will be invoked. Meanwhile when a connection is established, BLEAPPUTIL_ADV_END_AFTER_DISABLE event will also be invoked. Is there a way to tell this event is invoked because of the expiration of ADV duration or the connection establishment?

The reason I want to seperate the event is that I have different functions to call in these different cases. For example, I will call function A after ADV duration expires, and call function B after connection establishes. However since BLEAPPUTIL_ADV_END_AFTER_DISABLE event is always ahead of BLEAPPUTIL_LINK_ESTABLISHED_EVENT, function A will always be called regardlessly. What's the suggested approach to handle this use case?

Best regards,

Shuyang

1 month ago

0 Lea 1 month ago

TI__Expert 5360 points

Hi !

In the latest SDK, these are handled by two different events GAP_EVT_ADV_END_AFTER_DISABLE and GAP_EVT_ADV_SET_TERMINATED:

In the BLEAppUtil API, those events are linked respectively to BLEAPPUTIL_ADV_END_AFTER_DISABLE and BLEAPPUTIL_ADV_SET_TERMINATED.

You should be able to set those two events in the peripheral or broadcaster event handler, and then filter for those events in the event mask of the event handler

I have made these screenshots on the latest SDK. Could you share with me the version of the SDK you are using ?

Kind regards,
Maxence

0 Shuyang Zhong 1 month ago in reply to Lea

TI__Expert 4890 points

Hi Maxence,

I am using the latest SDK and I saw these events, but I found that BLEAPPUTIL_ADV_END_AFTER_DISABLE will be invoked when the advertisement is terminated due to a connection. Can you check if you see the same at your side?

Best regards,

Shuyang

0 Lea 1 month ago in reply to Shuyang Zhong

TI__Expert 5360 points

Hi,

I'll check for this and get back to you.

Kind regards,
Maxence

0 Lea 1 month ago in reply to Lea

TI__Expert 5360 points

Hi,

Can you confirm on your end that BLEAPPUTIL_ADV_SET_TERMINATED triggers correctly when a disconnection happens ?

Kind regards,
Maxence

0 Shuyang Zhong 1 month ago in reply to Lea

TI__Expert 4890 points

Hi Maxence,

At my side BLEAPPUTIL_ADV_SET_TERMINATED triggers when a connection is established(not disconnected), BLEAPPUTIL_ADV_END_AFTER_DISABLE triggers when the advertisement terminates due to duration expiration or a connection is established.

Best regards,

Shuyang

0 Lea 1 month ago in reply to Shuyang Zhong

TI__Expert 5360 points

Hi !

I think I found the issue. The events are sent correctly, the issue stems from the behavior of the basic_ble example. In app_peripheral.c, you will find the Peripheral_GAPConnEventHandler function. This function listens to GAP events, and when a connection establishes, it stops the advertising through the GapAdv_disable function. This is the function that sends the BLEAPPUTIL_ADV_END_AFTER_DISABLE event.

In your use case, instead of listening to BLEAPPUTIL_ADV_END_AFTER_DISABLE and BLEAPPUTIL_ADV_SET_TERMINATED, you may instead listen to BLEAPPUTIL_ADV_END_AFTER_DISABLE and BLEAPPUTIL_LINK_ESTABLISHED_EVENT (be careful, these events are of different type, and use two different handlers).

What you can do is change the code inside Peripheral_GAPConnEventHandler to inform the Peripheral_AdvEventHandler handler that the next BLEAPPUTIL_ADV_END_AFTER_DISABLE event is from a connection and not an actual call to GapAdv_disable.

Kind regards,
Maxence

0 Shuyang Zhong 1 month ago in reply to Lea

TI__Expert 4890 points

Hi Maxence,

I forgot to sync with you that I have already tried to comment out the GapAdv_disable in Peripheral_GAPConnEventHandler, but the BLEAPPUTIL_ADV_END_AFTER_DISABLE event is still triggered when a connection is established. I believe it is the design of the BLE stack, which does not seperate the ADV termination reason. Can you help check if this is the case?

Best regards,

Shuyang

0 Lea 1 month ago in reply to Shuyang Zhong

TI__Expert 5360 points

Hi,

I'm able to reproduce your issue even after commenting the function. I will try to find the root cause or report this as a bug, and find a workaround in the meanwhile.

Kind regards,
Maxence

+1 Lea 1 month ago in reply to Lea

TI__Expert 5360 points

Hi !

I found a solution to your issue. You can change your Peripheral advertisement handler function to the following :

void Peripheral_AdvEventHandler(uint32 event, BLEAppUtil_msgHdr_t *pMsgData)
{
    switch(event)
    {
        case BLEAPPUTIL_ADV_START_AFTER_ENABLE:
        {
            MenuModule_printf(APP_MENU_ADV_EVENT, 0, "Adv status: Started - handle: "
                              MENU_MODULE_COLOR_YELLOW "%d" MENU_MODULE_COLOR_RESET,
                              ((BLEAppUtil_AdvEventData_t *)pMsgData)->pBuf->advHandle);
            break;
        }

        case BLEAPPUTIL_ADV_END_AFTER_DISABLE:
        {
            if(linkDB_NumActive() < linkDB_NumConns())
            {
                MenuModule_printf(APP_MENU_PROFILE_STATUS_LINE, 0, "Adv status: Ended - Function A");
            }
            else 
            {
                MenuModule_printf(APP_MENU_PROFILE_STATUS_LINE1, 0, "Adv status: Ended - Function B");
            }
            break;
        }

        default:
        {
            break;
        }
    }
}

This shows you how to differentiate when the advertisement change because of a connection or because of the advertisement expired.

Kind regards,
Maxence

0 Shuyang Zhong 1 month ago in reply to Lea

TI__Expert 4890 points

Hi Maxence,

This works for my use case, thanks for the support!

Best regards,

Shuyang

Bluetooth®︎

Bluetooth forum

CC2340R5: Is it possible to tell the source of BLEAPPUTIL_ADV_END_AFTER_DISABLE event?