Dynamically updating Advertising data in SDK 15

RE: Dynamically updating Advertising data in SDK 15

RenanSP — Sun, 06 Aug 2023 10:25:53 GMT

Thank you very very much!, MDougherty!

RE: Dynamically updating Advertising data in SDK 15

MDougherty — Fri, 01 May 2020 20:02:04 GMT

ShannonPahl,

You sure showed me for starting with "While the original poster has likely moved on..."!

Thanks for starting this thread and helping point people to good resources :)

RE: Dynamically updating Advertising data in SDK 15

MDougherty — Fri, 01 May 2020 19:57:28 GMT

Hello Josh West,

I am glad you brought that weakness up as I almost mentioned it in my post before deciding the post was already long enough as it was ^-^

You are correct that we cannot guarantee that the BLE stack will not read the advertising data when we are in the middle of the update if we are executing our changes in a regular runtime, and this limitation is important to point out.

There may be a way to protect ourselves from this, however, by using an interrupt to dynamically update the advertising data (this could be hardware or software driven) as the BLE Soft Device uses interrupt priorities of 1,4, and 5. Particularly, it uses priorities 4 and 5 for the BLE stack (GAP, GATT) and uses priority 1 for the radio. Thus, if the dynamic update of the advertising data happens in an interrupt of priority 2 or 3 we can be certain that the advertising data will not be read until we finish writing.

That being said, this interrupt would have to be very fast to avoid any timing issues with the BLE stack (I can't find the post now, but one Nordic developer recommended a few dozen microseconds for interrupts at priorities of 2 or 3 when using the BLE Soft Device). To see how safe we would be with timing we can run some numbers and note that advertising data is a max of 31 bytes and a STR instruction on the Cortex M4 (the NRF52840 MPU) takes two clock cycles. Let's be very generous and assume each of those 31 writes to memory takes 10 cycles (due to the prep involved), and let's assume that entering and leaving the interrupt takes 100 cycles each- at 64MHz we would still complete all of those cycles in about 8 microseconds. This is well within a few dozen microseconds, with some time left over for a few more quick operations.

In fact, this is what my team did since we only updated the advertising data when a sensor value changed. We had the sensor trigger an interrupt and updated the advertising data in its interrupt service routine.

I think for many situations your multi-buffer approach may be more appropriate, is quite elegant, and it plays within the SDK (which is always a plus). I merely wanted to provide an alternative approach for those scouring the forums for potential solutions, and noted that this method hadn't been shared yet.

Glad to hear back from you :D

RE: Dynamically updating Advertising data in SDK 15

ShannonPahl — Fri, 01 May 2020 19:16:47 GMT

We are also using the double buffering approach I linked to previously, since we update more than one byte but not more frequently than 1-10 minutes.

https://devzone.nordicsemi.com/f/nordic-q-a/38056/advertising-data-update-nrf_error_invalid_addr

RE: Dynamically updating Advertising data in SDK 15

Josh West — Fri, 01 May 2020 14:54:23 GMT

Hi MD,

I do believe I initially used your idea as my solution, but ultimately felt it was flawed due to the fact that I could not guarantee that the BLE stack would not send an advertisement out while I was in the middle of updating the data. For you it may not be an issue because you seem to only be updating a single byte; this was not my case. I am sure there may be some methods to ensure the data is updated "atomically" with regards to an advertisement packet being sent, but I opted to update the adv_data pointer to a different buffer instead as this just felt more reliable, IMO.

Again, I find no issue with your solution for your particular case.

Cheers!

RE: Dynamically updating Advertising data in SDK 15

MDougherty — Thu, 30 Apr 2020 21:39:23 GMT

While the original poster has likely moved on, I am posting for others who come here with a similar issue.

My team also wanted to update the advertising data of a device dynamically. Stripping away any details that are beyond the scope of the question, our use case was a sensor which would advertise 1 when sensing an event and advertise 0 when not sensing an event.

We ran into the same problems using the SDK and API to dynamically update the advertising data as others here and in other forum posts.

We did find a working and efficient solution, however, and it is as follows:

Note the ble_gap_adv_data_t struct which holds the advertising data. When initialized it would look something like:

static uint8_t m_adv_handle = BLE_GAP_ADV_SET_HANDLE_NOT_SET;                   /**< Advertising handle used to identify an advertising set. */
static uint8_t m_enc_advdata[BLE_GAP_ADV_SET_DATA_SIZE_MAX];                    /**< Buffer for storing an encoded advertising set. */
static uint8_t m_enc_scan_response_data[BLE_GAP_ADV_SET_DATA_SIZE_MAX];         /**< Buffer for storing an encoded scan data. */

/**@brief Struct that contains pointers to the encoded advertising data. */
static ble_gap_adv_data_t m_adv_data =
{
    .adv_data =
    {
        .p_data = m_enc_advdata,
        .len    = BLE_GAP_ADV_SET_DATA_SIZE_MAX
    },
    .scan_rsp_data =
    {
        .p_data = m_enc_scan_response_data,
        .len    = BLE_GAP_ADV_SET_DATA_SIZE_MAX

    }
};

The .adv_data.p_data data field is the right place to be looking. So let's follow .adv_data.p_data through the code and see what happens...

First, let's look at the relevant bits of advertising_init()

static void advertising_init(void)
{
    .
    .
    .

    // Build and set advertising data.
    ble_advdata_t advdata;
    memset(&advdata, 0, sizeof(advdata));
    
    uint8_t data[]                      = {0xDE, 0xAD, 0xBE, 0xEF};
    manuf_data.company_identifier       = 0x0059;
    manuf_data.data.p_data              = data;
    manuf_data.data.size                = sizeof(data);
    advdata.p_manuf_specific_data       = &manuf_data;

    advdata.name_type          = BLE_ADVDATA_FULL_NAME;
    advdata.include_appearance = true;
    advdata.flags              = BLE_GAP_ADV_FLAGS_LE_ONLY_GENERAL_DISC_MODE;

    err_code = ble_advdata_encode(&advdata, m_adv_data.adv_data.p_data, &m_adv_data.adv_data.len);
    APP_ERROR_CHECK(err_code);
    
    NRF_LOG_INFO("m_adv_data.adv_data.p_data address %p", m_adv_data.adv_data.p_data);
    
    // Build and set scan response data.
    .
    .
    .

    // Build and set advertising parameters.
    ble_gap_adv_params_t adv_params;
    .
    .
    .

    err_code = sd_ble_gap_adv_set_configure(&m_adv_handle, &m_adv_data, &adv_params);
    APP_ERROR_CHECK(err_code);
}

Of important note here is that, to keep with Bluetooth standards, the ble_advdata_encode() function is used. This is because, from Source:

"...the term advertising data refers to the 0..31 byte long payload that is available for application use. (In Bluetooth Core specification this field is referred to as AdvData).

Advertising data consists of one or more Advertising Data (AD) elements. Each element is formatted as follows:

1st byte: length of the element (excluding the length byte itself)
2nd byte: AD type – specifies what data is included in the element
AD data – one or more bytes - the meaning is defined by AD type"

Which is why our dynamic advertising data is in the manufacturer-specific data field.

So we don't want to simply override the entire .adv_data.p_data or we will not be in compliance with Bluetooth standards (unless you take care to format your payload yourself).

The last call in the advertising_init() snippet was:

err_code = sd_ble_gap_adv_set_configure(&m_adv_handle, &m_adv_data, &adv_params);

which is a Soft Device call so all we can look at is the declaration of that function which can be found in ble_gap.h:

SVCALL(SD_BLE_GAP_ADV_SET_CONFIGURE, uint32_t, sd_ble_gap_adv_set_configure(uint8_t *p_adv_handle, ble_gap_adv_data_t const *p_adv_data, ble_gap_adv_params_t const *p_adv_params));

...noting that SVCALL is a macro defined in nrf_svc.h and that this whole thing really does turn into a function definition. So why did we come all this way to look at a messy function declaration? We came so we could see the parameter ble_gap_adv_data_t const *p_adv_data, and in particular note that the pointer it is looking for is a constant. Therefore, while we can't know what sd_ble_gap_adv_set_configure(...) is doing since the soft device is proprietary, we can know that it expects the pointer to the advertising data to never change, which suggests the soft device will keep looking in the same location for advertising data (testing have verified this).

And that brings us to our solution, because we defined m_adv_data, so we can directly write to its address in memory. Writing to it is easy, we just use memcpy() or something like:

m_adv_data.adv_data.p_data[your_offset] = 0x01;

The only thing you need to do is determine your_offset, which is the where in p_data we want to put our dynamically updated payload, as it is going to be different depending on what fields you have in your advertising payload. Remember, we can't just write anywhere in p_data because the format is standardized, and only certain fields are meant to convey arbitrary data.

And now you may realize why

NRF_LOG_INFO("m_adv_data.adv_data.p_data address %p", m_adv_data.adv_data.p_data);

was in the advertising_init() function, and why the manuf_data.data.p_data was set to 0xDEADBEEF... it was so we could run the debugger to find the offset we need to write directly to the manufacturer-specific data section of m_adv_data.adv_data.p_data.

Now, if we ran the debugger and look at the logs we would see the address of m_adv_data.adv_data.p_data printed. Then, we would go to the view->debug->memory option in Segger Embedded Studio and go to that address and look for 0xDEADBEEF. You count the bytes from the address of m_adv_data.adv_data.p_data to the first D in 0xDEADBEEF to get your offset.

As for my team's use case, we can now dynamically update the advertising data by writing

m_adv_data.adv_data.p_data[11] = 0x01;

when the sensor picks up an event and

m_adv_data.adv_data.p_data[11] = 0x00;

when it does not. This is a simple solution that bypasses using the advertising update functions of the SDK, and avoids other complex solutions like double buffering. It is just one line to change the advertising data dynamically.

Just be mindful, as since you are writing directly to memory nothing is error checking what you are writing. You need to make sure that you don't write more characters than your field allows, that you update the offset if you change the number of fields in the advertising payload, and that you don't write anything which breaks the Bluetooth standard (such as writing over length fields, etc).

Hope that helps.

RE: Dynamically updating Advertising data in SDK 15

ShannonPahl — Thu, 08 Aug 2019 23:31:28 GMT

This approach seems to be working efficiently and well

https://devzone.nordicsemi.com/f/nordic-q-a/38056/advertising-data-update-nrf_error_invalid_addr

RE: Dynamically updating Advertising data in SDK 15

testsweng — Sat, 06 Jul 2019 15:39:17 GMT

has anyone got the Stratosphere working? If so can you enlighten us.

Thanks

RE: Dynamically updating Advertising data in SDK 15

ilkobg — Wed, 12 Dec 2018 10:34:05 GMT

Hello Stratosphere,

Thank you for the brief explanation to your approach. I have one question; Let's assume that you define advertising data as described:

[quote userid="75719" url="~/f/nordic-q-a/32824/dynamically-updating-advertising-data-in-sdk-15/160852"]static uint8_t m_enc_advdata[BLE_GAP_ADV_SET_DATA_SIZE_MAX] =
{
03, 0x19, 0x00, 0x00, //flags
02, 0x01, 0x06, //apperance
13, 0xFF, 0x59, 0x00, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0 //manufacturer specific data
};[/quote]

I can do it also, since I know what my adv packet looks like. But how you cope with the initialization of the advertising instance? I mean, in the classic approach for the function advertising_init(), we have

ble_advertising_init_t init;


typedef struct
{
    ble_advdata_t           advdata;       /**< Advertising data: name, appearance, discovery flags, and more. */
    ble_advdata_t           srdata;        /**< Scan response data: Supplement to advertising data. */
    ble_adv_modes_config_t  config;        /**< Select which advertising modes and intervals will be utilized.*/
    ble_adv_evt_handler_t   evt_handler;   /**< Event handler that will be called upon advertising events. */
    ble_adv_error_handler_t error_handler; /**< Error handler that will propogate internal errors to the main applications. */
} ble_advertising_init_t;

structure, which holds all parameters for the advertising module. We should define the advertising data through the ble_advdata_t structure. How you cope with this?

RE: Dynamically updating Advertising data in SDK 15

Stratosphere — Sun, 09 Dec 2018 16:33:12 GMT

Hi Ranjeesh,

I am developing on nrf52840 DK, S140, SDK15.2

Assumptions: I want to update the advertisement data at every advertisement at 1.0 second interval. Assuming the data is contained within the manufacturing specific data at index 0 , right after the company identifier. I am only changing 1 byte for the sake of explanation.

Background:

The advertising_init(void) function contains the following for the advert data:

memset(&advdata, 0, sizeof(advdata));

//advdata.name_type = BLE_ADVDATA_FULL_NAME;
advdata.include_appearance = true;
advdata.flags = BLE_GAP_ADV_FLAGS_LE_ONLY_GENERAL_DISC_MODE;

adv_manuf_data.data.p_data = adv_manuf_data_data;
adv_manuf_data.data.size = sizeof(adv_manuf_data_data);
adv_manuf_data.company_identifier = 0x0059; //Nordic's company ID
advdata.p_manuf_specific_data = &adv_manuf_data;

err_code = ble_advdata_encode(&advdata, m_adv_data.adv_data.p_data, &m_adv_data.adv_data.len);
APP_ERROR_CHECK(err_code);

--------------------------------

the advertisement data is stored in m_adv_data pointer (array), which itself points to m_enc_advdata array at initialization:

static ble_gap_adv_data_t m_adv_data =
{
.adv_data =
{
.p_data = m_enc_advdata,
.len = BLE_GAP_ADV_SET_DATA_SIZE_MAX
},
.scan_rsp_data =
{
.p_data = m_enc_scan_response_data,
.len = BLE_GAP_ADV_SET_DATA_SIZE_MAX

}
};

The m_enc_advdata is defined as:

static uint8_t m_enc_advdata[BLE_GAP_ADV_SET_DATA_SIZE_MAX]

Actual part:

General rule of thumb is to avoid updating the pointer array while it is being accessed. In our case that translates to making sure the adv data is not being accessed by advertising when we update the data. To ensure this, setup radio notifications as described here:

https://devzone.nordicsemi.com/tutorials/b/software-development-kit/posts/radio-notification

Put the following code in advertising_init(void) function instead of instead of what is mentioned in the link provided above:

err_code = radio_notification_init(3, NRF_RADIO_NOTIFICATION_TYPE_INT_ON_INACTIVE, NRF_RADIO_NOTIFICATION_DISTANCE_NONE);
APP_ERROR_CHECK(err_code);

This is generate an interrupt at the end of each advertisement. Now we are safe to update adv_data as:

/**@brief Software interrupt 1 IRQ Handler, handles radio notification interrupts.
*/
void SWI1_IRQHandler(bool radio_evt)
{
if (radio_evt)
{
bsp_board_led_invert(BSP_BOARD_LED_1); //just to provide a visual indication
m_enc_advdata[11] += 1;
m_adv_data.adv_data.p_data = m_enc_advdata;
// nrf_gpio_pin_toggle(BSP_LED_2); //Toggle the status of the LED on each radio notification event
}
}

This works well for me and it is really fast. There is no need to encode the adv_data again as long as you know the index of the data byte you want to update. In my case, it is the data byte right after the company identifier, which for me is index 11 of the m_enc_advdata array.

Important

I actually defined the m_enc_advdata array as per below since I know exactly what my advertisement data looks like:

static uint8_t m_enc_advdata[BLE_GAP_ADV_SET_DATA_SIZE_MAX] =
{
03, 0x19, 0x00, 0x00, //flags
02, 0x01, 0x06, //apperance
13, 0xFF, 0x59, 0x00, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0 //manufacturer specific data
};

Then i commented out the following code in advertising_init(void) functions since I do not want to construct the advertisement data any more:

/*
//advdata.name_type = BLE_ADVDATA_FULL_NAME;
advdata.include_appearance = true;
advdata.flags = BLE_GAP_ADV_FLAGS_LE_ONLY_GENERAL_DISC_MODE;

err_code = ble_advdata_encode(&advdata, m_adv_data.adv_data.p_data, &m_adv_data.adv_data.len);
APP_ERROR_CHECK(err_code);
*/

This allows me to use only one adv_data buffer and not have to encode the data everytime i need to update it.

Hope this helps!

RE: Dynamically updating Advertising data in SDK 15

Rajneesh — Sat, 17 Nov 2018 14:08:16 GMT

Hi Jeff

Can I have your full source code?

RE: Dynamically updating Advertising data in SDK 15

Siddhesh — Fri, 27 Apr 2018 13:52:39 GMT

Updating the same init buffer in S132V6.0 works fine. The same code did not work for updating the init structure in S140V6.0. Your solution of having a second buffer works for the S140. There are still a couple more test I have to run.

RE: Dynamically updating Advertising data in SDK 15

run_ar — Thu, 26 Apr 2018 12:50:11 GMT

[quote user="spirit1"]Guys, do you have any problems with updating advertising data after bonding?[/quote]

Guess you are using another advertisement mode in that case, could the whitelist feature be enabled or something?

RE: Dynamically updating Advertising data in SDK 15

kapi — Thu, 19 Apr 2018 12:28:12 GMT

Hi,

You can consider adding following function to the ble_advertising module:

static ret_code_t ble_adv_data_update(ble_advertising_t   * const p_advertising,
                                      ble_gap_adv_data_t  * const p_new_advdata_buf,
                                      bool                        permanent)
{
    if (permanent)
    {
        memcpy(&p_advertising->adv_data, p_new_advdata_buf, sizeof(p_advertising->adv_data));
        p_advertising->p_adv_data = &p_advertising->adv_data;
    }
    else
    {
        p_advertising->p_adv_data = p_new_advdata_buf;
    }

    return sd_ble_gap_adv_set_configure(&p_advertising->adv_handle,
                                        p_advertising->p_adv_data,
                                        NULL);
}

It should help with your issue. If you set permanent parameter to true, the advertising data will be permanently updated inside the ble_advertising module. Otherwise, the old data will be restored when you get next BLE_GAP_EVT_ADV_SET_TERMINATED event.

RE: Dynamically updating Advertising data in SDK 15

ShannonPahl — Fri, 13 Apr 2018 19:38:52 GMT

no bonding here either

RE: Dynamically updating Advertising data in SDK 15

Josh West — Fri, 13 Apr 2018 19:34:37 GMT

Hi Spirit,

I am not doing any pairing/bonding at all, so I can't really help you there. Sorry.

RE: Dynamically updating Advertising data in SDK 15

Spirit — Fri, 13 Apr 2018 19:03:25 GMT

Guys, do you have any problems with updating advertising data after bonding?
For me all works. But only when I'm not bonded.
If I make a bond, the advertising data stops updating :)

RE: Dynamically updating Advertising data in SDK 15

Josh West — Thu, 12 Apr 2018 20:30:31 GMT

Well, I believe my error when updating the advertising data had to do with a call to sd_ble_gap_adv_set_configure() that was always passing in &gapDataSet[0], instead of a pointer to the next data set to use.

So, at this point things seem to be working fairly well. I am still utilizing a gapDataSet[] with 3 elements that I cycle through, although now that I have fix the above issue, I am thinking I should be able to use just 2 sets to accomplish the updating.

RE: Dynamically updating Advertising data in SDK 15

ShannonPahl — Thu, 12 Apr 2018 16:14:11 GMT

According to this link - The data shall be kept alive until either: ... Advertising data is changed. So, after calling sd_ble_gap_adv_set_configure with p_adv_params = null, the buffer should be released. But it seems that is not what you are observing and you have occasional errors.

RE: Dynamically updating Advertising data in SDK 15

Josh West — Thu, 12 Apr 2018 15:29:45 GMT

I did verify that I am not seeing the BLE_GAP_EVT_ADV_SET_TERMINATED event after updating my advertising data/buffers. I let it run and update about 10 times without seeing the event in my NRF_SDH_BLE_OBSERVER callback function.

RE: Dynamically updating Advertising data in SDK 15

Josh West — Wed, 11 Apr 2018 20:50:05 GMT

Hmm... that would be great if it did. I have not noticed that.. but maybe I was not looking for it and just didn't notice. I will try to verify that soon, but currently I'm working on getting the bootloader working.

RE: Dynamically updating Advertising data in SDK 15

ShannonPahl — Wed, 11 Apr 2018 20:27:50 GMT

I think that when you switch buffers, at some point, you'll get a BLE_GAP_EVT_ADV_SET_TERMINATED event to notify you when the previous buffer was released. Until then, you cant reuse that buffer. And if you are switching buffers yourself, its probably not going to work well with ble_advertising : when it transitions from fast to slow (or any transition), it will revert to using its buffers and not yours, so it will advertise old data at the new rate.

RE: Dynamically updating Advertising data in SDK 15

Josh West — Wed, 11 Apr 2018 20:23:11 GMT

I would rather not have to do stop and start because I would like to make sure the fast advertising timeout does not get reset. My advertisement data is updated roughly every 5 seconds and I have a fast adv. timeout of 60 seconds. The framework my company uses was designed around SDK 12.1 and integrates nicely with the fact that the advertising data could easily be updated on-the-fly.

I have something that does work... most of the time. I have adapted the solution I was having trouble with earlier by adding 3 buffers to cycle through. Occasionally I get an assert. All I can assume is that I must be pointing to a buffer that is currently in use and somehow my logic for advancing to the next buffer is error prone. One hypothesis I have is that I may be calling it too quickly and I advance to the in-use buffer before it had a chance to update to the last buffer requested. I have not had the time to dig into the exact issue here though.

RE: Dynamically updating Advertising data in SDK 15

Jeff Seaman — Wed, 11 Apr 2018 20:09:24 GMT

I have been working on this with SDK13.

We want to advertise sensor data using the nRF52840 so I need to use SDK15.

I have been trying what you suggested and here is what works for me.

I set the advertising interval to the same as my update interval.

then in the timer function I call advertisement_update()

#define NON_CONNECTABLE_ADV_INTERVAL    MSEC_TO_UNITS(2000, UNIT_0_625_MS) 
APP_TIMER_DEF(m_update_timer_id);
#define UPDATE_TIMER_INTERVAL			APP_TIMER_TICKS(2000)

void update_timer_handler(void * p_context){
	


	NRF_LOG_INFO("timer handler\r\n");
 
	advertisement_update();
	
	
}

uint8_t sensor_data = 0;


static void advertisement_update(void){
 ret_code_t err_code = sd_ble_gap_adv_stop(m_adv_handle);
  raw_adv_data_buffer1[7] = 0x23;
  raw_adv_data_buffer1[8] = sensor_data;
  ++ sensor_data;
    err_code = sd_ble_gap_adv_set_configure(&m_adv_handle, &adv_data1, &m_adv_params);
    APP_ERROR_CHECK(err_code);
     err_code = sd_ble_gap_adv_start(m_adv_handle, APP_BLE_CONN_CFG_TAG);
    APP_ERROR_CHECK(err_code);
  }

If you need more code I can clean up what I am working with and post the whole thing. But that would be In a day or two

RE: Dynamically updating Advertising data in SDK 15

Josh West — Thu, 05 Apr 2018 12:53:12 GMT

There is mention of this in the s140 v6.0.0 migration document under the 'Configuring advertising parameters for an advertising set' section.

"ble_gap_adv_params_t::timeout has been renamed ble_gap_adv_params_t::duration and is now measured in 10 ms units."