Advertising buffer is overwritten by pc-ble-driver 'ble_data_t_dec'

[Paul Bradford]

I am writing a Windows program to control an nRF52840 using pc-ble-driver, v4.1.1, with NRF_SD_BLE_API=6   

I need to do all of the following:

1. Scan

2. Create multiple simultaneous open connections, and read/write characteristics on that connection.

3. Advertise while scanning and having open connections.

Most is working well except advertising. I started with the advertising code in pc-ble-driver (v4.1.1) examples\heart_rate_monitor\main.c

When initially advertise, it works. I go through this sequence of calls repeatedly:

1. sd_ble_gap_adv_set_configure

2. sd_ble_gap_adv_start

3. sd_ble_gap_adv_stop

4. Repeat

Initially this works. I monitor the advertisement from the nRF Connect app on my phone and it is exactly what I'm trying to advertise.

Eventually the buffer with my advertising data gets overwritten. The particular buffer I mean is part of the 3rd argument to sd_ble_gap_adv_set_configure: ble_gap_adv_data_t.adv_data.p_data which is a 30-byte buffer with my advertising data.

I'm debugging and see that my buffer is referenced in 'ble_data_t_dec' (SER_CONNECTIVITY is not defined, I don't know what SER_CONNECTIVITY is, but I never saw any instructions to define it)

    p_struct->p_data = app_ble_gap_adv_buf_unregister(buf_id, true);

So this 'unregisters' my buffer and then proceeds to overwrite it. What is this code trying accomplish, and why does it think it's OK to overwrite the advertising data buffer I gave it?

[Edvin]

Hello,

Eventually the buffer with my advertising data gets overwritten.

 Why is that? Are you trying to change the advertisement using sd_ble_gap_adv_set()?

I believe SER_CONNECTIVITY is defined in your preprocessor defines if you can't find it anywhere else. 

I'm sorry, but this probably doesn't answer your question, but I am struggling to understand exactly what you mean by this buffer being overwritten.

[Paul Bradford]

I set up advertising by calling sd_ble_gap_adv_set, providing a buffer. The pc-ble-driver code I referenced previously overwrites that buffer:

    p_struct->p_data = app_ble_gap_adv_buf_unregister(buf_id, true);

After that call 'p_struct->p_data' points to the buffer I provided in sd_ble_gap_adv_set, and that code proceeds to write into that buffer. I believe the buffer I gave to sd_ble_gap_adv_set should be treated as read-only by pc-ble-driver, since it is the static content that I want to appear in advertisements. 

I understand that I could define SER_CONNECTIVITY in the preprocessor, but I have no information saying that I should do so, and I have no idea what the purpose of SER_CONNECTIVITY is.

[Edvin]

I don't think you will be able to update the advertising buffer this way. Remember that pc-ble-driver is a serialized application running commands to an nRF. It is the sd_... calls that trigger the softdevice (bluetooth stack) on the connected device to do something Bluetooth related. So you will not be able to update the advertisements by only updating the value where you initialized it earlier. 

Actually, that is the same if you didn't use pc-ble-driver, but ran the SDK directly on the nRF. The pointers are just used to pass a struct to the softdevice, and it doesn't actually use the address in the pointer after the softdevice call (sd_...()) is used. 

So whenever you want to update the advertisements, you need to call sd_ble_gap_adv_set().

I wouldn't worry too much about SER_CONNECTIVITY. I am not sure exactly what it does, but I see that it changes the header files that are used based on this define and the softdevice API version. 

[Paul Bradford]

I'll resolve this by learning the pc-ble-driver code and debugging some more. This issue can get closed (I don't see a way I can close it myself).

[Paul Bradford]

I think this was due to some thread-unsafe code of mine.