very rare lost of bonding infos

RE: very rare lost of bonding infos

Amanda Hsieh — Tue, 16 Mar 2021 09:54:43 GMT

Hi Stelly,

[quote user="astella"]flash memory that is storing FDS_PAGE_TAG_MAGIC after fds init was corrupted [/quote]

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

[quote user="astella"]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[/quote]

Do you get the FDS_PAGE_UNDEFINED error?

[quote user="astella"]May you please theoretically explain what does it mean "missing the swap page". How to use swap page appropriately?[/quote]

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.

RE: very rare lost of bonding infos

astella — Fri, 12 Mar 2021 10:15:39 GMT

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?

RE: very rare lost of bonding infos

Amanda Hsieh — Thu, 11 Mar 2021 07:08:54 GMT

Hi Stelly,

[quote user="astella"]As we found debugging the FDS_PAGE_TAG_MAGIC was missing[/quote]

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?

[quote user="astella"]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). [/quote]

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 post. If 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.

RE: very rare lost of bonding infos

astella — Wed, 03 Mar 2021 18:16:59 GMT

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

RE: very rare lost of bonding infos

Amanda Hsieh — Tue, 02 Mar 2021 13:40:56 GMT

Hi Stella,

[quote user=""]

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?

[/quote]

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.