• State Verified Answer
  • Replies 4 replies
  • Subscribers 73 subscribers
  • Views 722 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 247659
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

About Notify permission or prohibition information and FLASH

takashina hiroki

SDK: 15.3.0
Device: EYSHJNZWZ (nRF52832)

I am operating in a "peripheral" configuration, with bonding enabled.
"BLE_GATTS_EVT_WRITE" occurs when notification is permitted or prohibited from "Central".
After that, "NRF_EVT_FLASH_OPERATION_SUCCESS" occurs.
We understand that this means that Notify permission or ban information is stored in FLASH.
We knew we would store the paired key in FLASH.
Is information on permission or prohibition of Notify stored in FLASH?
"NRF_EVT_FLASH_OPERATION_SUCCESS" will not occur if you set not to perform bonding.
We recognize that this means that Notify permission or ban information is not stored in FLASH.
Is my perception correct?

This question is important.
Is there any way not to save Notify permission or prohibition information in FLASH?
Please let me know other methods than setting to not perform bonding.

Parents
  • +1

    Hi

    I'm sorry about the delay, but we've had time to look at your issue now. According to the Bluetooth Core Spec. 5.2 3.3.3.3 the CCCD characteristic descriptor value should be persistent across connections for bonded devices and shall be set to the default value at each connection with the non-bonded peer.

    That means that when devices are bonded, the CCCD data is also stored in flash. In the case of a reset, its previous state is loaded from flash, and when devices are not bonded, the CCCD value is not stored in flash. In the nRF5 SDK, the peer manager library handles this.

    CCCD defines how characteristics may be configured by a specific client. Writing to it turns on/off notifications/indications for the characteristic.

    We suggest that you do not interfere with the CCCD value storage, as its behavior is defined in the BLE spec.

    Best regards,

    Simon

Reply
  • +1

    Hi

    I'm sorry about the delay, but we've had time to look at your issue now. According to the Bluetooth Core Spec. 5.2 3.3.3.3 the CCCD characteristic descriptor value should be persistent across connections for bonded devices and shall be set to the default value at each connection with the non-bonded peer.

    That means that when devices are bonded, the CCCD data is also stored in flash. In the case of a reset, its previous state is loaded from flash, and when devices are not bonded, the CCCD value is not stored in flash. In the nRF5 SDK, the peer manager library handles this.

    CCCD defines how characteristics may be configured by a specific client. Writing to it turns on/off notifications/indications for the characteristic.

    We suggest that you do not interfere with the CCCD value storage, as its behavior is defined in the BLE spec.

    Best regards,

    Simon

Children
No Data
Related
Terms of service