This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

very rare lost of bonding infos

To the kind attention of Nordic support team,

we are experiencing a very random and rare loosing of existing ble bonding infos (device side). So that to reconnect to the host we have to redo

a bonding. I'm suspecting that fds get full, a bonding update is failing and this is causing this very rare issue. And that is what I'm going to monitor.

I only I'd like to know if it is plausible? I mean, it can happen that bonding infos of an existing bonding sometime needs to be updated in flash and this

is prone to fail if fds hasn't got room anymore? I'd only like to get a theoretical reply about that, if it is not too much trouble.

We are using sdk16 and fds_gc is only called in peer_manager_handler, at this stage, like in standard Nordic code.

Having said that, I think could be useful to be calling fds_gc after every ble disconnection as suggested in one of your threads. Can you please confirm

about that? Thank you very much for your help,

Best regards

  • Hi Stella, 

    I'm suspecting that fds get full, a bonding update is failing and this is causing this very rare issue. And that is what I'm going to monitor. I only I'd like to know if it is plausible? I mean, it can happen that bonding infos of an existing bonding sometime needs to be updated in flash and this is prone to fail if fds hasn't got room anymore?

    Peer Manager uses FDS to store bonding data to flash. If there is no more space to store bonding data in the pages allocated to FDS, the peer manager will try to delete the oldest bonded peer(s).

    It's hard to say what is the issue without the log. Are you able to provide the completed debug log? Does it indicate that "Flash storage is full"?

    -Amanda H.

  • Thank you very much Amanda for your kind reply. I'll update this thread in case we find something interesting/useful about the topic. Right now we did some experiments using fds and stressing its routines, and I can confirm that flash corruption may very well obviously occur in case of power failures. As we found debugging the FDS_PAGE_TAG_MAGIC was missing (exactly like in https://devzone.nordicsemi.com/f/nordic-q-a/29770/peer-manager-initialisation-error). In this case we want to redo this kind of experiments after activating pof comparator to see if we can experience an improvement (https://infocenter.nordicsemi.com/pdf/nRF52833_PS_v1.3.pdf 4.3.7 is talking about NVMC power failure protection in combination with Vpof threshold)

    Anyway, hope to come back in days if we find anything useful about the ble related problem. And if it could be related to fds usage. Maybe, if it is not much trouble, I'd like to ask if after the initial bonding, flash ble infos ever require some sort of update. And, should it be the case, what kind of updates? What are the ble circumstances that may lead to update ble bond infos (if any). I'd like to understand this point in the first place. Thank you very much, best regards

  • Hi Stelly, 

    astella said:
    As we found debugging the FDS_PAGE_TAG_MAGIC was missing

    Is FDS_PAGE_TAG_MAGIC missing? Not the FDS_PAGE_SWAP (missing swap page)? Did you use FDS before adding the peer manager? What SDK are you using? And is FDS working apart from the peer manager? My guess is just that the flash is full, or you have run into a bug where you are missing the swap page in the FDS. What function that return FDS_PAGE_TAG_MAGIC?

    astella said:
    I'd like to ask if after the initial bonding, flash ble infos ever require some sort of update. And, should it be the case, what kind of updates? What are the ble circumstances that may lead to update ble bond infos (if any).

    When reconnecting to the bonded peer, you might get PM event like PM_EVT_CONN_SEC_SUCCEEDED and PM_EVT_PEER_DATA_UPDATE_SUCCEEDED. See my colleague's answer in this postIf you call pm_handler_pm_evt_log() in the peer_manager_handler.c and enable PM_LOG_ENABLED in the sdk_config.h, you might see what is updated from the log. 

    -Amanda H.

  • Hi Amanda thank you very much for your suggestions.

    -- Is FDS_PAGE_TAG_MAGIC missing?

    Yes flash memory that is storing FDS_PAGE_TAG_MAGIC after fds init was corrupted 

    -- Not the FDS_PAGE_SWAP (missing swap page)?

    I'm not sure about this, or what kind of extra care or init it needs so to use appropriately the swap page . I focused on FDS_PAGE_TAG_MAGIC only; debugging page_identify routine in fds.c I saw that p_page_addr[FDS_PAGE_TAG_WORD_0] was not FDS_PAGE_TAG_MAGIC anymore for each of the three pages we assigned to fds

    - Did you use FDS before adding the peer manager?

    I'm aware that if I'm initializing fds before calling a complete init using the peer manager (peer_manager_init ), this action can then modify or delete pre-existing flash data, so to accommodate a new set of meta data.

    -What SDK are you using? 16

    And is FDS working apart from the peer manager? We are basically using peer_manager_init as our application is using ble. And calling test write routines after that init

    My guess is just that the flash is full, or you have run into a bug where you are missing the swap page in the FDS.

    - it seems interesting. May you please theoretically explain what does it mean "missing the swap page". How to use swap page appropriately?

    But as I said I think could be normal from my point of view: we were just calling writing routines and just stressing the device switching it on and off randomly. You are claiming that with the right usage of fds, this kind of corruption shouldn't be possible?

  • Hi Stelly,

    astella said:
    flash memory that is storing FDS_PAGE_TAG_MAGIC after fds init was corrupted 

    Do you also see the Page tag with FDS_PAGE_DATA and FDS_PAGE_SWAP?

     

    astella said:
    I focused on FDS_PAGE_TAG_MAGIC only; debugging page_identify routine in fds.c I saw that p_page_addr[FDS_PAGE_TAG_WORD_0] was not FDS_PAGE_TAG_MAGIC anymore for each of the three pages we assigned to fds

    Do you get the FDS_PAGE_UNDEFINED error?

     

    astella said:
    May you please theoretically explain what does it mean "missing the swap page". How to use swap page appropriately?

    Each virtual page that is used by FDS is marked with a Page tag that is used by the system to store information about the page. If fds_init return the NO_SWAP error to indicate that like this case. Do you get any error code from fds_init or peer_manager_init?

    Are you able to add DEBUG into processor definitions (build with Debug), enable PM_LOG_LEVEL and modify PM_LOG_LEVEL 4 (debug) and provid the log?

    Have you tried to use SDK17.0.2? There have been some FDS patches in the later SDKs. Try that, and see if it can fix the issue or not. 

    -Amanda H.

Related