CCCD change not written to flash after BLE Write (Server)

RE: CCCD change not written to flash after BLE Write (Server)

KonstantinK — Tue, 03 Jan 2023 09:44:19 GMT

UPDATE: I could solve my issue, I did something wrong with my ram management (start address and size). As well as a mistake with sd_ble_gatts_value_set(). Thanks for your help and I am going to close this thread :)

RE: CCCD change not written to flash after BLE Write (Server)

KonstantinK — Mon, 02 Jan 2023 14:24:15 GMT

I changed the location of the characteristic to BLE_GATTS_VLOC_STACK and can add the 9 characteristics with size 510 bytes each with sd_ble_gatts_characteristic_add and I can successfully read and notify from the characteristics. But as soon as I am writing to them, there is again the issue with bonding. When the size of each characteristic is 201 bytes, everythin works well. Are there any other limitations which I should take care of. Or am I fine with memory when sd_ble_gatts_characteristic_add returns NRF_SUCCESS for each characteristic. Or should I take care of something else, even tho sd_ble_gatts_characteristic_add returns NRF_SUCCESS? Thanks for the support

RE: CCCD change not written to flash after BLE Write (Server)

Vidar Berg — Mon, 02 Jan 2023 10:54:38 GMT

Thanks. The max. table size is only limited by how much RAM you have to spare.

RE: CCCD change not written to flash after BLE Write (Server)

KonstantinK — Mon, 02 Jan 2023 10:52:01 GMT

Alright, I will try with BLE_GATTS_VLOC_STACK. Me too haha. Is there a maximum value for NRF_SDH_BLE_GATTS_ATTR_TAB_SIZE, except the limitation of the ram?

RE: CCCD change not written to flash after BLE Write (Server)

Vidar Berg — Mon, 02 Jan 2023 10:48:53 GMT

Hello,

Would you mind trying with BLE_GATTS_VLOC_STACK instead? The BLE_GATTS_VLOC_USER option was more relevant before when the attribute table size was not configurable.

[quote userid="116619" url="~/f/nordic-q-a/95084/cccd-change-not-written-to-flash-after-ble-write-server/402765"]But as soon as I configure them with a size of 202 bytes, it is not working anymore. When I increase the NRF_SDH_BLE_GATTS_ATTR_TAB_SIZE to 1700 bytes for example it is also working with a size of 202 bytes each[/quote]

I am surprised it helped to increase the NRF_SDH_BLE_GATTS_ATTR_TAB_SIZE, to be honest. I would have expected the table size to remain unchanged since the attribute values are kept in the application memory.

RE: CCCD change not written to flash after BLE Write (Server)

KonstantinK — Mon, 02 Jan 2023 09:24:33 GMT

Hello, thanks for your answer. I did some more research and debugging and discovered following:

I have 9 characteristic with a size of 510 bytes each. I have configured them with BLE_GATTS_VLOC_USER and it is not working (initializing and advertising works but writing to the characteristic causes problems with bonding data). When I configure them with a size of 201 bytes each (with NRF_SDH_BLE_GATTS_ATTR_TAB_SIZE 1608), everything works fine (initializing, advertising and writing+bonding works). But as soon as I configure them with a size of 202 bytes, it is not working anymore. When I increase the NRF_SDH_BLE_GATTS_ATTR_TAB_SIZE to 1700 bytes for example it is also working with a size of 202 bytes each. So the issue should be somewhere with my memory management and the size of NRF_SDH_BLE_GATTS_ATTR_TAB_SIZE. My question is, when I am using the BLE_GATTS_VLOC_USER flag, why is the size of the characteristic still depending on the softdevice stack? And which NRF_SDH_BLE_GATTS_ATTR_TAB_SIZE should i use for using such long characteristics?

Thanks for your help

best regards

RE: CCCD change not written to flash after BLE Write (Server)

Vidar Berg — Tue, 27 Dec 2022 13:14:05 GMT

Hello,

It sounds like the bonding data is being erased on disconnect for some reason. It could be because the FDS storage is full as you indicated earlier and that pm_handler_flash_clean()/pm_handler_flash_clean_on_return() is called. Or do you see the same if you do a full chip erase before you program your FW?

FDS usage can be monitored with the fds_stat() function.

RE: CCCD change not written to flash after BLE Write (Server)

KonstantinK — Thu, 22 Dec 2022 15:23:37 GMT

Edit: After more debugging I discovered following:

1. First connect (everything works and central and peripheral are bonded)

2. Writing to a characteristic (BLE_GATTS_EVT_WRITE occurred and value is written to characteristic)

3. Disconnecting

4. Reconnecting (Device is not recognized as peer and is doing rebonding)

Note: If I am doing the steps 1., 3. and 4. Device is recognized as already bonded peer

Any ideas where the issue might be?

RE: CCCD change not written to flash after BLE Write (Server)

KonstantinK — Thu, 22 Dec 2022 14:15:48 GMT

My connection parameters are:

MIN_CONN_INTERVAL                   MSEC_TO_UNITS(100, UNIT_1_25_MS)
MAX_CONN_INTERVAL                   MSEC_TO_UNITS(200, UNIT_1_25_MS)        
SLAVE_LATENCY                       0                                       
CONN_SUP_TIMEOUT                    MSEC_TO_UNITS(4000, UNIT_10_MS)

Are these values good to go or should I use other?

Yes, the updating of CCCD values is not correct. The new value gets written to the CCCD but the new value is not stored to flash. (when doing a write on a characteristic before). Have you ever experienced something like this before?

RE: CCCD change not written to flash after BLE Write (Server)

Edvin — Thu, 22 Dec 2022 12:24:13 GMT

Oh, sorry. I thought you were using NCS, not the nRF5 SDK. Never mind what I said in the previous reply then.

[quote user="KonstantinK"]But after that, nothing is written to flash and this only after I did a write to characteristic 1 before[/quote]

What connection parameters are you using? Does it work with one of the examples that use bonding by default in the SDK if you test?

And what exactly is it that is not working? Updating the CCCD value that is stored in flash?

Best regards,

Edvin

RE: CCCD change not written to flash after BLE Write (Server)

KonstantinK — Thu, 22 Dec 2022 11:50:00 GMT

Thanks for the reply. After I want to disable notification I am disconnecting from the device. So there is no poweroff or something like that.

I did some debugging and discovered that when I first write something to characteristic 1, and I want to enable/disable characteristic 2. I get the event that something is written to UUID 0x2902 (as BLE_GATTS_EVT_WRITE indicates) but afterwards there is nothing written to flash. When I am not writting to characteristic 1 in the first place, everything works fine with enabling/disabling notification on characteristic 2. Might there be a problem with memory size somehow? Since characteristic 1 has a size of 510 bytes..? I did some debugging in the peer manager as well and I reach this function in the gatt_cache_manager.c with correct parameters:

case BLE_GATTS_EVT_WRITE:
            if (cccd_written(&p_ble_evt->evt.gatts_evt.params.write))
            {
                local_db_update(conn_handle, true);
                update_pending_flags_check();
            }
            break;

But after that, nothing is written to flash and this only after I did a write to characteristic 1 before. Might there be a chance that I am blocking the fds module somehow when I receive the write event in the first place form characteristic 1?

Thanks for your help

best regards

RE: CCCD change not written to flash after BLE Write (Server)

Edvin — Thu, 22 Dec 2022 11:23:13 GMT

I am guessing that you are connecting, bonding, enabling notifications, and turning off the server/peripheral.

By default, the CCCD values are stored after the disconnect event, but if you disconnect by turning off the power, then obviously, that will not happen.

You can add this to your prj.conf file:

CONFIG_BT_SETTINGS_CCC_STORE_ON_WRITE=y

Which will cause it to store it at once instead. Please see the description of the config BT_SETTINGS_CCC_STORE_ON_WRITE from NCS\zephyr\subsys\bluetooth\host\Kconfig:

config BT_SETTINGS_CCC_STORE_ON_WRITE
	bool "Store CCC value immediately after it has been written"
	depends on BT_CONN
	default y
	help
	  Store Client Configuration Characteristic value right after it has
	  been updated. If the option is disabled, the CCC is only stored on
	  disconnection.

Try that, and see if it helps.

Best regards,

Edvin