• State Verified Answer
  • Replies 4 replies
  • Subscribers 73 subscribers
  • Views 721 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.

  • +1

    Hi

    I have asked the R&D team internally in order to get a satisfactory answer to this question for you. It might take a few days before I hear back from them, as they have a lot to do. Thank you for your patience.

    Best regards,

    Simon

  • 0 in reply to Simonr

    I've acknowledged.
    I want to get this answer quickly.
    Would you please contact the R & D team so we can get back to you as soon as possible?
    Thanking you in advance.

  • 0 in reply to Simonr

    Please tell me one more thing.

    After enabling the notification, turn the power off and then on again.
    After launching, is notification enabled?
    We know that this will be the case if FLASH contains information about whether notifications are allowed or prohibited.

  • +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

Related
Terms of service