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

[KonstantinK]

Hello,

I am currently developing a firmware where I am acting as a server with nRF52840.

The protocol of my use case is:

1. Client is connecting to my device (server with bonding)
2. Client sets notification enabled (is written to flash by the server as PM_EVT_PEER_DATA_UPDATE_SUCCEEDED event indicates)
3. Client is writing to a custom characteristic
4. Client wants to set notification disabled (I receive the event that it is written to CCCD but I don't get the PM_EVT_PEER_DATA_UPDATE_SUCCEEDED event and nothing is written to the flash, since I want to store the information for reconnecting with the bonded device)

Do I have to handle the write to the CCCD on my own or could there be a problem with writing to my characteristic?

Note: When no write is executed, just notification enabling and disabling, everything works fine and is stored to flash.

best regards 

[Edvin]

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

[KonstantinK]

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

[KonstantinK]

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

[Vidar Berg]

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. 

KonstantinK said:

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

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. 

[KonstantinK]

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?

[Vidar Berg]

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

[KonstantinK]

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

[KonstantinK]

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 :)